mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-05-04 18:09:12 +03:00
[Issue]: Failure post-upgrade to 10.8.1, constraint failure #3977
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 @tadgh on GitHub (Jun 29, 2022).
Please describe your bug
Just upgraded my container, encountering the following failure, logs are in this dpaste: https://dpaste.org/oiN4Q
Effectively it appears the root is
Causes the server not to come up at all.
I've attached the jellyfin db zipped here. If there is something I can do to fix my install (manual migrations or whatever) I would be happy to run them. Alternatively, I suppose there's always the fresh start route.
jellyfindb.zip
Any ideas?
Jellyfin Version
10.8.0
if other:
No response
Environment
Jellyfin logs
https://dpaste.org/oiN4Q
FFmpeg logs
No response
Please attach any browser or client logs here
No response
Please attach any screenshots here
No response
Code of Conduct
@spooksbit commented on GitHub (Jun 29, 2022):
Did you happen to delete a user or two at any point? I'm seeing that there are permissions/preferences that are tied to users that don't exist. It sounds like JF didn't delete those when the users were deleted originally, and now those permissions/preferences are left dangling which prevents the migration scripts from succeeding for you.
I was able to delete a few of these dangling records by running the following SQL commands on your database. After deleting them, I was able to get a 10.8.1 build to run on my local machine. I'm not sure if it's appropriate to send you the "fixed" database file, but if you have a tool like DB Browser for SQLite, you should be able to fix it on your machine.
I hope that can get you back up and running awhile.
For developers, the
AddIndexesAndCollationsmigration is failing to complete because of non-existent user ids on the permissions/preferences tables. I don't understand how this could have happened, because these tables have RESTRICT on the FKs, which should have prevented the users from being deleted in the first place. I'm wondering if the above deletion script should be included in the migration to catch the cases where somehow there are dangling permissions/preferences.@tadgh commented on GitHub (Jun 30, 2022):
Thanks much, I'll go ahead and try to execute those commands myself and report back
@tadgh commented on GitHub (Jun 30, 2022):
Yup, all set, thankfully sqlite3 is installed in the docker container :)