2024-10-29, 12:25 AM
I followed a piece of advice on this forum to delete migrations.xml (thus redo all the migration).
I lost the ability to login.
I restore the jellyfin db from backup and I got back the ability to login.
Then I lost this ability again (probably ran the migration again).
So I checked my jellyfin.db and the backup and the Users table was empty. I don't know how I got the ability to login back after restoring as there was no Users table entries even then. I did not investigate (maybe the migration removed a flag that was making jellyfin read the old users.db database file, that would require more work.
So I believe that somehow the UserDb migration had not run succeessfullyon my jellyfin install and that running it partially broke the ability to authenticate.
Either way I found that it was enough to add back:
in Jellyfin.Data/Entities/AccessSchedule.cs b/Jellyfin.Data/Entities/AccessSchedule.cs
this code was removed with a lot of other parameterless constructors in commit 287dab465.
I believe that if the Jellyfin.Server/Migrations/Routines/MigrateUserDb.cs code is kept then it should be able to run which is not the case without this AccessSchedule parameterless constructor.
Do you mean I should not submit a PR and have this routine working again? (it cannot run currently) Because it is not supposed to run on installs that are up to date?
Shouldn't this MigrateUserDb.cs code be removed if it is not supposed to run and fixing its breakage is not seen as of use?
I lost the ability to login.
I restore the jellyfin db from backup and I got back the ability to login.
Then I lost this ability again (probably ran the migration again).
So I checked my jellyfin.db and the backup and the Users table was empty. I don't know how I got the ability to login back after restoring as there was no Users table entries even then. I did not investigate (maybe the migration removed a flag that was making jellyfin read the old users.db database file, that would require more work.
So I believe that somehow the UserDb migration had not run succeessfullyon my jellyfin install and that running it partially broke the ability to authenticate.
Either way I found that it was enough to add back:
+ /// <summary>
+ /// Initializes a new instance of the <see cref="AccessSchedule"/> class.
+ /// Default constructor. Protected due to required properties, but present because EF needs it.
+ /// </summary>
+ protected AccessSchedule()
+ {
+ }
in Jellyfin.Data/Entities/AccessSchedule.cs b/Jellyfin.Data/Entities/AccessSchedule.cs
this code was removed with a lot of other parameterless constructors in commit 287dab465.
I believe that if the Jellyfin.Server/Migrations/Routines/MigrateUserDb.cs code is kept then it should be able to run which is not the case without this AccessSchedule parameterless constructor.
Do you mean I should not submit a PR and have this routine working again? (it cannot run currently) Because it is not supposed to run on installs that are up to date?
Shouldn't this MigrateUserDb.cs code be removed if it is not supposed to run and fixing its breakage is not seen as of use?