2024-12-05, 09:10 PM
(2024-10-29, 12:25 AM)prahal Wrote: 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:
+ /// <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?
THe issue is that was not my question. I did not ask how to restore jellyfin to a usable state. My question was "is the fact taht MigrateUserDatabase in the jellyfin code cannot work (in no way can it run without crashing on the missing constructor) a bug" ? That is is having even old migration code that do not work a bug in jellyfin ?
Shouldn't the non supported because too old migration code be removed if it is not expected to be able to run without crashing ? Or should I report the issue to github so as to have the MigrateUserDatabase be fixed ?
I am not asking how to get my DB into a usable state. I am asking if I should open a bug report for code that cannot work but is shipped by the current jellyfin release.
Also if old migration should never be attempted again, people telling to delete config/migrations.xml should stop telling so because this triggers the old migration code that is broken currently and that you seem to tell me should not be brought into a working state again because it is deprecated code that no one should run.