Bug Report: Incorrect "Recently Added" Sorting Due to File Modification Date

I found a bug and here is a detailed description of it:

Bug Report: Incorrect “Recently Added” Sorting Due to File Modification Date

Summary

Plex uses the file’s LastWriteTime (Windows modification date) as the added_at timestamp in the database instead of generating its own timestamp when media is added. This causes media with incorrect file dates (e.g., future dates) to remain permanently at the top of “Recently Added” regardless of actual addition order.


Steps to Reproduce

  1. Create a media file and set its modification date to a future date (e.g., 01/01/2098)

  2. Add the file to a Plex library and run a library scan

  3. Verify the file appears first in “Recently Added”

  4. Add a new media file with a normal date and run another library scan

  5. Observe the old file with the future date remains first in “Recently Added”

  6. Query the database: SELECT title, added_at FROM metadata_items – the old file’s added_at contains the future timestamp


AS IS (Current Behavior)

  • Plex directly copies the file’s LastWriteTime to the metadata_items.added_at field

  • The added_at timestamp is never updated, even if the file’s modification date changes

  • Media items sort based on file modification date, not actual library addition time

  • Media with future modification dates becomes permanently stuck at the top of “Recently Added”


TO BE (Expected Behavior)

  • Plex should generate a new added_at timestamp based on the current system time when media is first added to the library

  • The added_at field should be independent of the file’s LastWriteTime

  • Media items should sort based on when they were added to Plex, not their file modification dates

Server Version#:1.42.2.10156
Player Version#:4.147.1
<If providing server logs please do NOT turn on verbose logging, only debug logging should be enabled>

No, it doesn’t.

Plex uses the file date/time stamp only, when you create a new library and have added the folder containing the file during the course of that library creation.

I had this happen and only temporarily changing the location of the file so plex deletes that entry from the db and then move it back with a “LastWriteTime”-date that is not in the future and start the plex scanner to add it again with a correct time. But i assumed that plex always uses the “LastWriteTime” from the file. If this is not the case, then this topic can be closed. thank you.

That depends. If you want it thoroughly removed from the Plex database, perform the Plex Dance.

This workaround worked for me already, i just wanted to report the behavior.

I see that it works because the time for “Recently added…” is now going to “X minutes ago” and before it was always “a few seconds ago”. Which is still a bug in my opinion, i just got the “wrong” reason for it.

What exactly is the bug?

When a library is created with a file that has the “LastWriteTime” in the future, plex adds this date as the “added_at”-date and this file will always be on top in the category “recently added” and has the status “a few seconds ago” when you go to the “recently added”-category.

I agree. If the file’s date is in the future, it would be more sensible to fall back to the current date.

1 Like