All my movies is added today

[JBL 8]

48 minutes ago, Happy2Play said:

1) There are topics where it appears library setting are getting disabled so I would double check all your library settings.

2) do images exist with media or is Emby saving to /metadata/library folders?  As that is current issue of uses losing their info that is not saved with media do to the update removing all content and readding, so all images and metadata are lost when not saved with media causing this new date added issue. (but not truly known why library is removed and readded)

3) As for placing folder and backdrop images we would need to see the server log for that specific example as I can only guess a permissions issue.

Thanks for the quick reply, appreciate it. I might just delete the Library from Emby, bounce my server and onboard the LIbrary again. Or I'll uninstall Emby, deleting all of the leftover folders, re-installing Emby from scratch. I hate Plex and want to stick with Emby as long as possible. 

I'm not sure what Library settings to double check to ensure Emby creates a Primary image for a video in my library. Apologies in advance for not understanding. Here are my Library's settings regarding metadata: 

[Happy2Play 9780]

5 minutes ago, JBL said:

Thanks for the quick reply, appreciate it. I might just delete the Library from Emby, bounce my server and onboard the LIbrary again. Or I'll uninstall Emby, deleting all of the leftover folders, re-installing Emby from scratch. I hate Plex and want to stick with Emby as long as possible. 

I'm not sure what Library settings to double check to ensure Emby creates a Primary image for a video in my library. Apologies in advance for not understanding. Here are my Library's settings regarding metadata: 

This is a Home Video and Pictures library correct since there is only "Image Capture" option?

May suggest ffmpeg unable to extract image? Server log needed

[Kramerika 18]

7 hours ago, sa2000 said:

Just for me to understand the impact of this issue - is it that anyone with Server Settings for Library in Advanced with "Use Date scanned into the library" will have the issue when upgrading to 4.9.1.80 

And we are now re-scanning on first launch of 4.9.1.80

and anyone using the "Use file creation date" is not affected 

 

 

 

I had the latter enabled, and it overwrote (or deleted and readded, not sure which really happened) all of my metadata with the update in my movies library.  I do not have Nfo files in each movie folder, but I thought I had imlocked any file that i made custom changes to.  I am making sure I do that this time around.

[Happy2Play 9780]

1 minute ago, Kramerika said:

I had the latter enabled, and it overwrote (or deleted and readded, not sure which really happened) all of my metadata with the update in my movies library.  I do not have Nfo files in each movie folder, but I thought I had imlocked any file that i made custom changes to.  I am making sure I do that this time around.

Issue is when you have database only metadata anytime the server sees a change it removes and readds your content nuking the existing database only entries.

[BlazedMonkey 111]

Bang up job there team, way to iron out the bugs after it was reported in the beta 

Guess I get to start from scratch....again......in 24 hours when this finally rebuilds 

[BlazedMonkey 111]

On 10/1/2025 at 12:35 PM, Luke said:

Hi, yes a couple users reported this on the beta. Apologies for the disruption:

A "disruption" would be something that can easily be reverted. This isn't as bad as when you guys accidentally deleted peoples entire movie folders, but this certainly isn't a "Whoopsie guys, my bad, tee-hee" moment either. 

[Happy2Play 9780]

5 minutes ago, BlazedMonkey said:

A "disruption" would be something that can easily be reverted. This isn't as bad as when you guys accidentally deleted peoples entire movie folders, but this certainly isn't a "Whoopsie guys, my bad, tee-hee" moment either. 

In the end it will come back to switches for Collapsefolder/single files that are different across systems do to different values depending on how old your system is and with the values going away it will affect everyone differently.  And when they go way completely, I will guess some will still be affected again.

[BlazedMonkey 111]

4 minutes ago, Happy2Play said:

In the end it will come back to switches for Collapsefolder/single files that are different across systems do to different values depending on how old your system is and with the values going away it will affect everyone differently.  And when they go way completely, I will guess some will still be affected again.

So this is somehow my fault, even though this was reported in beta testing? Cool.

And instead of taking that feedback, and maybe running a file structure check (or whatever gibberish makes sense in response to your jargon) that would alert the user that their database was about to be trashed and they might want to back up some things before making this seemingly routine but actually catastrophic update, you just decided that a few casualties were acceptable for progress? Cool.

 

 

 

[C.S. 93]

On 10/1/2025 at 10:35 AM, Luke said:

Hi, yes a couple users reported this on the beta. Apologies for the disruption:

Were they not using NFOs? Clarity on who is affected by this would be awesome.

[C.S. 93]

.

Edited October 7, 2025 by C.S.

[Happy2Play 9780]

25 minutes ago, C.S. said:

Were they not using NFOs? Clarity on who is affected by this would be awesome.

Correct from my understanding so when db only metadata got purged and content got reimported new dateadded value now exists.  Or at least that is my understanding.

Still seems pretty simple for everyone to have system backup plans though.  I know I have full backups before every version.

 

[C.S. 93]

2 hours ago, Happy2Play said:

Still seems pretty simple for everyone to have system backup plans though.  I know I have full backups before every version.

I have backups out the wazoo, but I'd rather have everything set to avoid ever needing them.

[queenbuzzo 11]

I have backups as well but I also had downgrade because I assume the same stuff will happen again, once I upgrade again. So what now? Am I just stuck with an old version? 

[C.S. 93]

3 hours ago, queenbuzzo said:

I have backups as well but I also had downgrade because I assume the same stuff will happen again, once I upgrade again. So what now? Am I just stuck with an old version? 

I imagine the solution involves refreshing all your metadata with NFOs enabled before upgrading. But that's just my imagination.

Actual instructions from people in the know would be much better.

[BlazedMonkey 111]

I was, in fact, using .NFO's, thankfully. 24 hours later now that the dust has settled, it appears that only 40 of my movies had their "Date Added" screwed up. Unfortunately, it appears this reset all my cover art and media for the entire movie library though, which is what took so long. Still not happy about this, but it is much less disastrous than it first appeared.

 

 

21 hours ago, Happy2Play said:

Correct from my understanding so when db only metadata got purged and content got reimported new dateadded value now exists.  Or at least that is my understanding.

Still seems pretty simple for everyone to have system backup plans though.  I know I have full backups before every version.

 

Again, whether or not we have backups is irrelevant when you were given the feedback in beta. You are effectively blaming the user here and chastising them for not having backups, instead of owning up to the fact that you knew about a bug and didn't bother to address it because you didn't think it would affect that many people. Beta is where you make your mistakes, not on full releases. I would imagine the vast majority of your user admins running servers are pretty hands off when it comes to day to day operations. That is the entire point of these automated systems that find and download and slap pretty covers on all our movies and shows before sorting them all nice. That's great that you want to dive into all of that, but the rest of us don't want to spend all day mucking about with setups, or fixing things that should have been caught in beta releases (which we intentionally don't sign up for, because we want the WORKING product, not the bug filled one). To be frank, this is some amateur bullshit. I'm just thankful that this most recent F-up wasn't more costly.

[ebr 16169]

14 hours ago, BlazedMonkey said:

and didn't bother to address it because you didn't think it would affect that many people

Hi.  I can understand how it looks like that but that wasn't the case.  The issue is we could never track down the exact conditions under which it occurred and it was extremely rare which exacerbated that.

At some point, we have to release even if not perfect because, well, it will never be perfect.

Apologies for the issue.

[adminExitium 355]

I would hope that this also leads to changes in what is documented and how it is documented in the release notes.

There really needs to be better structure and more details in the release notes (both for beta & stable releases). Some categories like Major Changes/Minor Changes/Bug Fixes/Known Issues would go a long way to helping users make better decisions. The current format of just having a big list of bulleted points helps no one.

I know developers rarely like to document stuff but this is one of the areas where LLMs shine in. Just feed them a list of the commits in the release and ask them to make a release document. It should do wonders and require very little effort.

[Happy2Play 9780]

In the end over time there are too many systems with different Collapse switch values as it was not really forced overtime with all the changes as a new install would have a different value then a updated install and with the switches somewhat going away it will affect everyone differently and when they completely go away I can see issues like this happening again.

[JBL 8]

On 10/6/2025 at 12:00 PM, Happy2Play said:

1) There are topics where it appears library setting are getting disabled so I would double check all your library settings.

2) do images exist with media or is Emby saving to /metadata/library folders?  As that is current issue of uses losing their info that is not saved with media do to the update removing all content and readding, so all images and metadata are lost when not saved with media causing this new date added issue. (but not truly known why library is removed and readded)

3) As for placing folder and backdrop images we would need to see the server log for that specific example as I can only guess a permissions issue.

My issue seems to be resolved. I reset Inherited Permissions on a couple of the subfolders containing my media and bounced Emby.

Emby then created for the vids contained problem subfolders. 

I went ahead and replaced all child object permissions with inheritable permissions from my Libraries' top folders on down thru the subfolders and vids themselves. 

Also, yes, Emby is saving the images to /metadata/library folders, not the folders in the Libraries themselves. 

 

[Painkiller88 248]

On 10/7/2025 at 4:17 AM, Happy2Play said:

Correct from my understanding so when db only metadata got purged and content got reimported new dateadded value now exists.  Or at least that is my understanding.

Still seems pretty simple for everyone to have system backup plans though.  I know I have full backups before every version.

 

i was also affected but i have nfo for all my movies in the movie directory.

But in my case it only happens to 7 movies, where the date got overwritten, all my tags where gone (even if i locked the field) and the movies got removed from collections.

But i was using nfo.

While scanning i saw all movies appearing as recently added but when the scan was done, only about 7 movies was left with this problem

[C.S. 93]

Could it be the update is looking for info contained in the new* NFO format?

*I don't know when it changed, but NFOs started being written differently somewhere after (I think) version 3.5. I noticed this and refreshed all my metadata when 4.8 came out. So maybe I'm safe?

I guess I'll just go ahead and update this weekend and be ready to roll back.

[AnotherMatt 15]

The new update required a library re-scan for me, and this then killed my 'recently added' view as everything was stamped with the date of the scan.  I made a comment on another thread that I'd found a basic solution to my problem, and @seanbuffsuggested it may be helpful to people in this thread.

When I started looking into the issue (via both directly in the SQL database, and basic API queries), I found that the original "DateModified" field was not changed after the re-scan.  Whilst this field is not a perfect replacement for the date added, it was a far better solution than having everything set for today's date. 

Note this fix is not for the faint of heart -- proceed with caution.  FIRSTLY BACKUP YOUR INSTALLATION.  It works for me, but I can't be responsible for any disasters that may befall you for using it.

You're going to need the following:

• An API key (Settings -> API Keys)
• An admin User ID (Settings -> Users -> Admin user -> The number after "userId=" in the URL field)

Quote

 

If you want to see what the script is going to change, you can have a look via curl:

• Grab the item ID of a movie you know was recently added (click on the movie, and grab the itemID number from the URL field)

curl -H "X-Emby-Token: <API Key>" "https://<embyURL>:1234/emby/Users/<UserID>/Items/<ItemID>" | json

You're going to see a huge JSON response, but the two relevant fields are at the top and are "DateModified" and "DateCreated".  With any luck, you should see that the modified field is close to when it was originally added to Emby.  The attached script is going to copy the Modified field and place it in the Added.

 

Update the variables at the top of the script, leave "DRY_RUN" as true for your first attempt, and verify it looks about right.  If all goes well, change the DRY_RUN field to False and run again.

I hope this helps anyone with a similar issue.

 

emby_date_sync.py

[briantretter44 0]

On 10/1/2025 at 4:48 PM, JoLarsson said:

So, I upgraded to 4.9.1.80, I'm running the portable version so I just swapped the SYSTEM-folder as I usually do, backing up the old one.

When starting emby server a scan was initiated that took a couple of hours. After the scan all my movies had been added right now. All metadata shows all movies were added 2025-10-01 10:16:34
Not a big thing but the "latest movies" and the sorting is all off.

The TV-shows are same as before, so no change there.

Yeah, this happens when Emby thinks your movie library is brand-new and rebuilds the DB. Swapping the portable SYSTEM folder can change the server ID/library.db, so every movie gets a fresh “Date added” stamp - hence everything showing 2025-10-01 10:16:34. TV shows probably kept their old entries, so they look normal. I’d first check the “Date added behavior” in Dashboard → Library → Advanced and set it to use the file system date instead of “when added.” Then run a manual scan. If the dates don’t fix themselves, stop the server, clear the library cache for that library (not your media), and let it rebuild with that setting. For the next upgrade, don’t just replace SYSTEM - keep or restore the data folder (library.db, config, metadata, etc.) so your dates survive. If you have a backup of the old install, you can also drop the old data/library.db back in and start the new binaries, and your original dates should return.

[JoLas 26]

On 10/9/2025 at 2:19 PM, briantretter44 said:

Yeah, this happens when Emby thinks your movie library is brand-new and rebuilds the DB. Swapping the portable SYSTEM folder can change the server ID/library.db, so every movie gets a fresh “Date added” stamp - hence everything showing 2025-10-01 10:16:34. TV shows probably kept their old entries, so they look normal. I’d first check the “Date added behavior” in Dashboard → Library → Advanced and set it to use the file system date instead of “when added.” Then run a manual scan. If the dates don’t fix themselves, stop the server, clear the library cache for that library (not your media), and let it rebuild with that setting. For the next upgrade, don’t just replace SYSTEM - keep or restore the data folder (library.db, config, metadata, etc.) so your dates survive. If you have a backup of the old install, you can also drop the old data/library.db back in and start the new binaries, and your original dates should return.

Well just swapping out the system folder (that only contains the binaries) is something I've been doing without any hickups for about 15 years. I also have monthly and weekly full file backups and perform a snapshot of the vm just before upgrading.
When this problem occurred I immediately reverted to my snapshot and re-did my system folder swap and db's but as soon as the new version kicked off a scan... dates were off... restored my db's again....new scan....dates off again.
So I simply let the scan do it's thing and then created a powershell script that pulled the creation date from the movie files and put them in an nfo-file containing the <dateadded></dateadded>
I already had nfo files created outside of emby only containing tags pulled from the filenames so it was only a matter of injecting the dates.

Edited October 13, 2025 by JoLarsson