[Issue]: Cannot play media if the "©day" field is incorrect

[adyanth]

Please describe your bug

I had a song that has the M4A/AAC metadata for "©day" set to 20180101 instead of how jellyfin expected it (2018?). This caused the song to not be played because it crashed.

It should be able to play the file regardless of being able to parse the metadata correctly. Additionally, pick up additional date formats stored in "©day".

jellyfin/MediaBrowser.Providers/MediaInfo/AudioFileProber.cs

Lines 272 to 281 in ce3e287

	if (tags.Year != 0)
	{
	var year = Convert.ToInt32(tags.Year);
	audio.ProductionYear = year;
	if (!audio.PremiereDate.HasValue)
	{
	audio.PremiereDate = new DateTime(year, 01, 01);
	}
	}

Reproduction Steps

1. Set the m4a tag "©day" to something with >4 digits (e.g. 20240512)
2. Let jellyfin scan it
3. Try to play
4. Fails

Jellyfin Version

10.9.0

if other:

No response

Environment

- OS: Ubuntu 22.04
- Linux Kernel: 5.15.0-101-generic
- Virtualization: Proxmox
- Clients: N/A
- Browser: N/A
- FFmpeg Version: 5.1.4-Jellyfin
- Playback Method: Direct Play
- Hardware Acceleration: NVENC
- GPU Model: NVIDIA T400
- Plugins: /
- Reverse Proxy: Traefik
- Base URL: none
- Networking: host
- Storage: NFS

Jellyfin logs

[2024-05-12 14:33:03.019 +00:00] [INF] Starting "/usr/lib/jellyfin-ffmpeg/ffprobe" with args "-analyzeduration 200M -probesize 1G -i file:\"/media/Music/.../....m4a\" -threads 0 -v warning -print_format json -show_streams -show_format"
[2024-05-12 14:33:03.143 +00:00] [ERR] Error in "Probe Provider"
System.ArgumentOutOfRangeException: Year, Month, and Day parameters describe an un-representable DateTime.
   at System.DateTime..ctor(Int32 year, Int32 month, Int32 day)
   at MediaBrowser.Providers.MediaInfo.AudioFileProber.FetchDataFromTags(Audio audio, MediaInfo mediaInfo, MetadataRefreshOptions options, Boolean tryExtractEmbeddedLyrics)
   at MediaBrowser.Providers.MediaInfo.AudioFileProber.FetchAsync(Audio audio, MediaInfo mediaInfo, MetadataRefreshOptions options, CancellationToken cancellationToken)
   at MediaBrowser.Providers.MediaInfo.AudioFileProber.Probe[T](T item, MetadataRefreshOptions options, CancellationToken cancellationToken)
   at MediaBrowser.Providers.Manager.MetadataService`2.RunCustomProvider(ICustomMetadataProvider`1 provider, TItemType item, String logName, MetadataRefreshOptions options, RefreshResult refreshResult, CancellationToken cancellationToken)

FFmpeg logs

No response

Please attach any browser or client logs here

No response

Please attach any screenshots here

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[nfmccrina]

@adyanth I opened a PR which would allow the file to play despite the unexpected data. I wasn't sure about the second part of your suggestion, handling this new possible date format. It seems to me that trying to handle anything instead of just YYYY is potentially very messy. It would be easy to add a workaround for your case, "20180101", but what if there is a file that has "201811" or some other such value? I'm fairly new here so I figured I'd wait and see if someone else had more feedback on potential ways to handle that.

[crobibero]

Closing as this will be fixed in 10.9.2.

[sel10ut]

digging more into it, i think you can view this as a bug from TagLib. It is stated, that the higher precision dates will be truncated to 4 digits, however, looking at the code section from mpeg4 parser:

public override uint Year {
	get {
		foreach (AppleDataBox box in DataBoxes (BoxType.Day))
			if (box.Text != null && (uint.TryParse (
				box.Text, out var value) ||
				uint.TryParse (
					box.Text.Length > 4 ?
					box.Text.Substring (0, 4)
					: box.Text, out value)))
				return value;

		return 0;
	}

it will not reach the third condition, if you have formats like YYYYMMDD (is it non-standard though?), and it will for YYYY-MM-DD. The second condition looks unnecessary. When looking at the XiphComment parser:

public override uint Year {
	get {
		string text = GetFirstField ("DATE");
		return (text != null && uint.TryParse (
			text.Length > 4 ? text.Substring (0, 4)
			: text, out var value)) ? value : 0;
	}
	set { SetField ("DATE", value); }
}

It only has 2 conditions and works properly. So, removing the second condition should suffice? Something like this:

foreach (AppleDataBox box in DataBoxes (BoxType.Day))
	if (box.Text != null && uint.TryParse (
		box.Text.Length > 4 ? box.Text.Substring (0, 4)
		: box.Text, out var value))
		return value;

But it seems like TagLib has been unmaintained for a long time. Should jellyfin perhaps consider a fork?

Additionally, pick up additional date formats stored in "©day".

@adyanth higher precision dates are already parsed by ffprobe. Currently PremierDate is set to whatever ffprobe could parse. But ffprobe could also fail or fallback to a different date, that is not necessarily a release/recorded date. Which is not ideal. Sticking to the standard format should be working fine I believe. (But to me it is quite unclear, which value format ©day follows)

TagLib supports getting tags through custom fields per specific format, which we could possibly use to parse standardized fields, that store higher precision dates, but we will need to redo verifying/parsing logic, again - not ideal.