Emby Using Date Modified for Sorting

[sonofamort 2]

That has been suggested multiple times in the above thread and I’ve tried it. Emby is inconsistent whether I add/move the files manually or if I let sonarr/radarr manage them. 

[Happy2Play 9780]

Is this something with the Platform?

On 12/23/2022 at 3:51 PM, sonofamort said:

Confirmed, adding a file manually, even with a modified date from several days ago, results in Emby updating the "added" date to when the file was scanned in. So, looks like it is something on the Radarr side?

What were you setting here?

[sonofamort 2]

When I was troubleshooting at that time I thought that Emby was always using the file’s modified date to set the library “added date”. As a result, I thought there might be something on the Radarr side of things hence my post that you quoted above. Since then, after having added files, both automatically through Radarr and manually myself, I’ve found that Emby is NOT consistently using the file’s modified date. I’m currently testing with Jellyfin to see if the issue persists. Since it’s a fork of Emby I feel that it would be a better comparison vs switching to Plex.

 

Just a quick edit: I really appreciate how responsive the two of you have been. While this has been a little frustrating to figure out, it’s nice to have a team that is so quick to reply and attempt to provide guidance. Thank you.

Edited January 21, 2023 by sonofamort
Thank you

[Happy2Play 9780]

5 hours ago, sonofamort said:

Emby I feel that it would be a better comparison

Not really as that fork was over 5 years ago before Emby went private.

[sonofamort 2]

Installed jellyfin and file sorting is working as expected. I prefer Emby and will continue using it, but I’m giving up of figuring out this issue. 

[Glavata 0]

Emby is using the file Modified date for me as well. The server is running on a Synology DS7, version 4.7.11. I have since switched the advanced Library setting to date scanned into library.

• These files have had nothing to do with Radarr, and no nfo stored and I have manually copied them to their destination.
• At the time of the scan Library > Advanced > Use file creation date was set

 

Edited March 29, 2023 by Glavata

[Luke 42077]

This is the reason: https://github.com/dotnet/runtime/issues/80023

When the .NET runtime can't determine the file creation date on linux, it silently falls back to the last modified time, and there's no way for us to stop that. It would be better if it threw an error so that we could decide how to proceed, but it's just a silent switch that we can't control.

So we will need them to resolve that, although it doesn't look like they want to change the behavior right now.

[Carlo 4560]

That's a terrible decision they made with the results of FileInfo.CreationTime on Linux. Either return proper results/values or an error if a proper result can't be returned. Returning a "substitute value" from another attribute than the one requested is a BAD decision.

From a quick test I did, a Windows machine accessing the same files over a network share can determine the correct CreationTime.

I haven't tried it (yet), but would be curious the results of FileInfo.CreationTime via Net when running the Linux subsystem on Windows.