mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-07-16 05:43:54 +03:00
Migration failure on upgrading to 10.11.0 (MigrateLibraryDb) #7461
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @brianjmurrell on GitHub (Oct 21, 2025).
Description of the bug
After upgrading to Jellyfin 10.11.0 from 10.10.7 the first startup after the upgrade failed with a database migration.
Reproduction steps
Not sure beyond the obvious of trying to update from 10.10.7 to 10.11.0.
What is the current bug behavior?
Database migration failed on start.
What is the expected correct behavior?
Database migration is successful.
Jellyfin Server version
10.10.0+
Specify commit id
No response
Specify unstable release number
No response
Specify version number
No response
Specify the build version
I cannot as the server failed to start
Environment
Jellyfin logs
FFmpeg logs
Client / Browser logs
No response
Relevant screenshots or videos
No response
Additional information
No response
@Dyredhead commented on GitHub (Oct 21, 2025):
I have the exact same issue.
All plugins were disabled and deleted before migration, so it is most likely not them.
logger.txt
@isamudaison commented on GitHub (Oct 21, 2025):
+1 , same exact issue (not sure what state everything is currently in, either)
@jmjsdev commented on GitHub (Oct 21, 2025):
I lost everything while I was migratiing, same error
@brianjmurrell commented on GitHub (Oct 21, 2025):
I'd agree that you have the same issue as me.
@JPVenson commented on GitHub (Oct 21, 2025):
can everyone with the "cannot deserialize unknown type" issue please run this query on the library.db
The result should look like this:
@brianjmurrell commented on GitHub (Oct 21, 2025):
@isamudaison commented on GitHub (Oct 21, 2025):
@Regular-Snowman commented on GitHub (Oct 21, 2025):
That's good info, much appreciated. I'll action that now.
@JPVenson commented on GitHub (Oct 21, 2025):
Ok strange.
this script should clean those items up. First select those that are not currently officially supported:
if you are satisfied delete them or depending on your own capabilities you can try to rename them according to the list:
@isamudaison commented on GitHub (Oct 21, 2025):
After I stopped the docker container my library DB was corrupted (shocker) so I just replaced library.db with a known good copy, but that caused a startup failure for to missing table, so removed library.db all together and now I'm getting this error:
@brianjmurrell commented on GitHub (Oct 21, 2025):
And then do what? Try to start the Jellyfin server again? It's expected to be able to resume the migrations and finally start cleanly after the above removals?
@JPVenson commented on GitHub (Oct 21, 2025):
@brianjmurrell you should restore from the backup you made pre-migration, apply the query while the 10.11 server is not yet started and then attempt the migration
@Dyredhead commented on GitHub (Oct 22, 2025):
This worked for me! Thank you!!!
@brianjmurrell commented on GitHub (Oct 22, 2025):
That's great to know!
I guess the question that remains is will this be fixed in the JF migrations or is having to do this manual, external table fix-up always going to remain a manual, external operation that nobody will know they need to do until their upgrade fails and they go hunting for the reason?
@JPVenson commented on GitHub (Oct 22, 2025):
this is soly the result of us enforcing stricter limits and as the blog post said should be a on-off thing. We are trying to clean up a lot of emby legacy stuff here that was littering the database (which all of that is esp the
Emby.Server.Implementations.Devices.CameraUploadsFolderone which never even existed in jellyfin and was removed before we even forked). Nobody reported issues with this during the 6 months of RCs and no team member has that old stuff in their DBs so its impossible for us to predict. Thats why we are cleaning up what we can and enforcing a better schema, to improve stability for the long run.@brianjmurrell commented on GitHub (Oct 22, 2025):
@JPVenson Fair enough. But clearly some number of users do have some of this legacy stuff in their databases. Maybe not a trivial number of users given how many were hit in the first few days of the release being available. Do you think that the upgrade/migration/etc. should be what is doing this kind of cleanup and not users, only once they have broken their systems with the upgrade that does not handle their data?
I understand it was impossible to predict, but now that it's known should a 10.11.1 release be made to handle this?
@Dyredhead commented on GitHub (Oct 22, 2025):
@JPVenson I would leave this as a manual fix, but I would add a note in the migration logs that if this specific migration fails, to check this GitHub issue for a possible solution.
@brianjmurrell commented on GitHub (Oct 22, 2025):
Why? What advantage do you see to leaving it as manual so that the migration breaks people's systems, leaving them having to hunt for a solution. Hopefully they actually did a database backup since it seems that the only way to resolve this issue is to restore from backup and try again.
This all just makes JF look fragile and unstable IMO. It's going to scare people away from doing upgrades.
@Dyredhead commented on GitHub (Oct 22, 2025):
Unless I'm misunderstanding what the solution is doing, its deleting data which does not fit into the new schema, not simply moving it around like what the migration was supposed to do. Because of this, I don't think jellyfin should be automatically applying a migration that deletes data. The user should absolutely manually opt in to such a thing.
You will not have to hunt for anything, if the solution is simply linked in the logs if the specific issue comes up.
If I am mistaken, and this solution does do what was initially intended by the migration, then it absolutely should be built into the migration.
@brianjmurrell commented on GitHub (Oct 22, 2025):
I would argue if that some kind of extraneous data is unused, useless, unsupported and actually causes breakage (as seems to be the case here) when it exists then the migration should take care of removing it.
@brianjmurrell commented on GitHub (Oct 25, 2025):
I do backups daily. But which files am I restoring from backup? I notice that both
library.dbandjellyfin.dbboth have the same modification time stamp which was the time of the migration failure:Does that mean that both of those files should be restored from backup?
Interestingly I am also noticing:
But no
library.dbbackup in that dir. ☹️ Pity.I have also discovered through trial-and-error and referring to the three tickets from this search result that one also has to restore
/etc/jellyfin/migrations.xmlbefore retrying the upgrade.@frzifus commented on GitHub (Oct 28, 2025):
Same here. Could you resolve this @isamudaison?
@xBelladonna commented on GitHub (Nov 7, 2025):
The migration seems to have FUBAR'd my library with the following error:
I tried the same trick with replacing the library.db with a known good copy but met with the same fate as did
@frzifus even after removing it, cannot re-add my libraries.
Just going to set up Jellyfin again from scratch like I'm reinstalling Windows because it's normal.
@arminfuerst commented on GitHub (Nov 22, 2025):
The upgrade from 10.10.7 to 10.11.2 was not working properly and today I tried to upgrade to 10.11.3 which also failed. Here is the relevant part of the log:
I then renamed jellyfin/config/migrations.xml to jellyfin/config/migrations.xml.disable because I assumed, the migrations.xml doesn't contain any relevant migrations. At the next startup, I only got an error about a missing column (u.MaxParentalRatingScore). Jellyfin continued to run, but I didn't try to use it. I stopped it and edited the sqlite database jellyfin.db directly (
sqlite3 jellyfin.db). I executed following commands:The next startup of jellyfin resulted in no error in the log and I am able to use it. I found the "Catalog" for "Plugins" is missing, so I downgraded to 10.10.7.