its possible v2 didnt shut down cleanly. i had issues when i was doing it way back (its like the container never shuts down cleanly) and ended up going with backing up the database (or you can use an existing one if you havent made any changes recently) and then shutting down the container.
then delete all the files in the config directory (not the subfolders) - back them up (just move them) if you want to keep them, just in case
pull the new v3 docker image and upgrade the container to it
once its up, restore the database from the last backup (which you made just before the upgrade. it’ll be in the backups\manual subdirectory)
Close! Well… Following your suggestions, I made an in app backup of the db and then shutdown the container. Removed all the existing files (not folders) of the /config dir and started a new instance of the preview container.
It came up just fine.
However attempting to restore the old backed up database results in the same error.
Logs show continual “epic fail” due to missing table: LanguageProfiles
M.
Edit: Unpacking and taking a look at the backed up DB, there definitely isn’t a “LanguageProfiles” table in the old DB. So it would appear that there is something amiss in the DB upgrade procedure?
Last build was 3 days 20 hours ago - so maybe something relatively new?
as a workaround there are version very specific container tags for each release so you could try an earlier version of v3, eg linuxserver/sonarr:3.0.1.406-ls34, and see if that one works and if not keep going backwards until it does?
Well I tried the suggestion regardless, and even all the way back to “amd64-3.0.1.363-ls2” I run into the exact same error - that being that the LanguageProfiles table doesn’t exist.
So… Why isn’t the table being created when the container is started and it is recognised as a database upgrade situation? Or when I manually restore an older version of DB within Sonarr 3?
I don’t know, this is the first instance that I’ve seen where it hasn’t.
The only reason a migration won’t run is if it a migration with the same ID has run before.
If you open the DB in a SQLite Editor, what do you get if you run: SELECT * FROM [VersionInfo]? (That’ll be the list of the migrations that have run before).
That’s the same migration ID as the one that should be creating the language profile, but 111 with that description is in Radarr’s repo, so it looks like Radarr (or an unreleased version of Sonarr) touched that DB at some point, migrated it and now you’re having issues.
About the only thing you can do is remove that line from the table and let Sonarr run the migration again.