Closed mreid-tt closed 2 years ago
Please note that this only seems to be a problem updating from Version 20210708-15 or 20220510-16 with the configurations and movie library present. If I do a clean install there is no error; for example:
radarr_backup_v4.1.0.6175_*.zip
)I believe it has something to do with the fact that the internal version in the package of radarr is version 3.2.2.5080 and not the current 4.1.0.6175. As such, if there is not a downgrade of the internal version as part of the package update, this may resolve the issue. This error however is recoverable since the backup that was done prior to the package upgrade should be still present and can be copied manually and applied after a clean install as shown above.
@ta264 is this a bug in Radarr or do we need to avoid downgrades by spk package updates (similar to syncthing with #5181)?
This is user error - the user is trying to use a database that has been used with a new version of radarr with an old version. I guess from having reinstalled the package?
So to answer your question, yes downgrades must be prevented
PS radarr should handle this to an extent when the empty update_required
file is created, though it may be that the version of radarr in the spk is so old that that functionality isn't present
After a downgrade you see something like this in the System>Updates view:
@mreid-tt you only have to manually update Radarr with "Install Latests" here and radarr will work with the database again.
I thought the internal updater of Radarr would do this with the update_required
file, but this does not work as expected, at least not with version 3.2.2.5080.
Anyway, we need a redesign to prevent downgrades on spk update at all.
Hmm it should have worked in 3.2.2.5080 if the update_required file was created
https://github.com/Radarr/Radarr/commit/ec8d1c4ae6395e6e3ffb8f2df1ee438a60d5de79
It would be good to get some trace logs of radarr trying to start after the package related roll back to try to figure it out
Good morning folks, thanks for looking into this for me. As for the manually update Radarr that @hgy59 mentioned above, this is exactly what I did in step 7 of my reproduction steps described above. Whether I upgrade from version 20210708-15 or 20220510-16 of the package, once the old internal version 3.2.2.5080 sees the newer database, something goes wrong.
Once this happens, even after I upgrade the internal version of Radarr to 4.1.0.6175, I get all the errors I see above and the package fails to start and asks to be repaired in the Package Center. This repair then fails. I can try to give you trace logs, just let me know exactly where in the above steps you would like me to turn tracing on.
Does it ever manage to upgrade to 4.1? It may be that your DSM supplies libraries that are too old to work with radarr without some workarounds
Oh right, a clean install and upgrade works it looks like. I'm guessing either radarr isn't handling the upgrade_required file properly or the package isn't creating it in the right place
In that case please can you grab trace logs of the first start of radarr after the package is upgraded?
(what should be happening is that after the package is updated radarr is told to update itself, so you should never see 3.2)
Okay, will try to turn on tracing as described. A couple of further observations before I do some more troubleshooting:
The JSON value could not be converted to System.String. Path: $.audioLanguages
. This suggests to me that the error is related to one or more movies in my library. As such, this may or may not occur for everyoneHmm, well this is frustrating. I am now unable to replicate the issue. I downloaded the old version 20210708-15 but the new version 20220513-17 is no longer in the online repository so I downloaded instead from the build repository here.
I was able to successfully install and upgrade with a full backup (the version with one video also was successful). So I don't know if this version from the build repository is somehow different than the one which was on the SynoCommunity page or not. Maybe you can share a private link so I can try again? I do have some trace logs but I don't know how useful they will be given the upgrade was successful...
Hmm, well this is frustrating. I am now unable to replicate the issue. I downloaded the old version 20210708-15 but the new version 20220513-17 is no longer in the online repository so I downloaded instead from the build repository here.
@mreid-tt sorry, but I deleted the 20220513-17 while creating a new version to prevent downgrades with #5273 BTW I could not reproduce the error "Unable to start Radarr after upgrade...", I only had the issue, that Radarr did not self update.
The analysis why update_required does not work is for the Radarr developpers. The next package will not require this feature anymore (just waiting for help to translate the new text in upgrade wizard to French).
Okay, I've located the version 20220513-17 from my Time Machine backups. I'll begin re-resting shortly and update you on my findings...
EDIT: So I really can't explain things now. I did the exact same steps as in the original bug report with the exact same configuration backup and the process completed successfully with the package able to launch after manually running the internal updater. I even got the same error message following the package upgrade: Error parsing column 8 (Language=34 - Int64)
. The files used for the manual install and upgrade are the exact same ones from the SynoCommunity online repository so it should have resulted in the original issue:
For version 20210708-15:
radarr.v15.f40000[apollolake-avoton-braswell-broadwell-broadwellnk-bromolow-cedarview-denverton-dockerx64-geminilake-grantley-purley-kvmx64-v1000-x86-x86_64].spk
For version 20220510-17:
radarr.v17.f41890[apollolake-avoton-braswell-broadwell-broadwellnk-bromolow-cedarview-denverton-dockerx64-geminilake-grantley-purley-kvmx64-v1000-x86-x86_64].spk
As I can't replicate the error now even with the same source files I guess I should withdraw this bug report?
As a further update, I installed a clean version of the 20210708-15 package and did an internal update to 4.1.0.6175 of Radarr. I then restored a configuration backup and used the new build repository for package version 20220514-18. This upgraded successfully from the DSM Package Manager and I can confirm that the internal version of Radarr did not downgrade and all configurations seem to be present without error.
(what should be happening is that after the package is updated radarr is told to update itself, so you should never see 3.2)
@ta264 just found that Lidarr autoupdate on installation works as expected (on DSM 7) Installing post-install update from 0.*.*.2042 to 1.0.1.2578
:
22-5-15 17:39:35.9|Info|Bootstrap|Starting Lidarr - /volume1/@appstore/lidarr/share/Lidarr/bin/Lidarr.dll - Version 0.8.0.2042
22-5-15 17:39:37.3|Info|Router|Application mode: Interactive
22-5-15 17:39:37.5|Info|MigrationController|*** Migrating data source=/volume1/@appdata/lidarr/.config/Lidarr/lidarr.db;cache size=-10000;datetimekind=Utc;journal mode=Wal;pooling=True;version=3 ***
22-5-15 17:39:38.1|Info|MigrationController|*** Migrating data source=/volume1/@appdata/lidarr/.config/Lidarr/logs.db;cache size=-10000;datetimekind=Utc;journal mode=Wal;pooling=True;version=3 ***
22-5-15 17:39:41.2|Info|InstallUpdateService|Installing post-install update from 0.*.*.2042 to 1.0.1.2578
22-5-15 17:39:41.2|Info|InstallUpdateService|Downloading update 1.0.1.2578
22-5-15 17:39:46.5|Info|InstallUpdateService|Verifying update package
22-5-15 17:39:46.7|Info|InstallUpdateService|Update package verified successfully
22-5-15 17:39:46.7|Info|InstallUpdateService|Extracting Update package
22-5-15 17:39:53.5|Info|InstallUpdateService|Update package extracted successfully
22-5-15 17:39:53.5|Info|BackupService|Starting Backup
22-5-15 17:39:53.9|Info|InstallUpdateService|Preparing client
22-5-15 17:39:55.5|Info|InstallUpdateService|Starting update client /tmp/lidarr_update/Lidarr.Update
22-5-15 17:39:55.5|Info|InstallUpdateService|Lidarr will restart shortly.
22-5-15 17:39:55.5|Info|InstallUpdateService|Updater Arguments: 30979 /tmp/lidarr_update /volume1/@appstore/lidarr/share/Lidarr/bin/Lidarr.dll
2022-05-15 17:40:14.0|Info|Bootstrap|Starting Lidarr - /volume1/@appstore/lidarr/share/Lidarr/bin/Lidarr.dll - Version 1.0.1.2578
2022-05-15 17:40:15.7|Info|MigrationController|*** Migrating data source=/volume1/@appdata/lidarr/.config/Lidarr/lidarr.db;cache size=-10000;datetimekind=Utc;journal mode=Wal;pooling=True;version=3 ***
2022-05-15 17:40:16.1|Info|MigrationController|*** Migrating data source=/volume1/@appdata/lidarr/.config/Lidarr/logs.db;cache size=-10000;datetimekind=Utc;journal mode=Wal;pooling=True;version=3 ***
2022-05-15 17:40:16.6|Info|Microsoft.Hosting.Lifetime|Now listening on: http://[::]:8686
2022-05-15 17:40:18.8|Info|RootFolderWatchingService|Watching directory /volume1/music/lidarr/greek/
2022-05-15 17:40:19.3|Info|Microsoft.Hosting.Lifetime|Application started. Press Ctrl+C to shut down.
2022-05-15 17:40:19.3|Info|Microsoft.Hosting.Lifetime|Hosting environment: Production
2022-05-15 17:40:19.3|Info|Microsoft.Hosting.Lifetime|Content root path: /
2022-05-15 17:40:49.1|Info|RssSyncService|Starting RSS Sync
2022-05-15 17:40:50.4|Info|DownloadDecisionMaker|No results found
2022-05-15 17:40:50.4|Info|RssSyncService|RSS Sync Completed. Reports found: 0, Reports grabbed: 0
That looks like it's still using the old pkgvar so maybe the pkgvar change broke the update_required mechanism too?
That looks like it's still using the old pkgvar so maybe the pkgvar change broke the update_required mechanism too?
No, only Radarr rev -15 had a wrong var folder, Lidarr always used the correct SYNOPKG_PKGVAR variable (on DSM 7: Migrating data source=/volume1/@appdata/lidarr/.config/Lidarr/lidarr.db
)
Hi, I wanted to do a clean installation of Radarr, however, when I try to download the package, it just gives me an error saying failed to download with no other information. Any idea on how I can get this to work? .
This is work in progress for Rev -18. Version 20220513-17 is deleted in the repo (but it takes up to 48h until it disappears in the package center of DSM due to the CDN). If you want to install Radarr you have to wait, until Version 20210311-15 is shown, or you can download the spk (https://synocommunity.com/package/radarr) and install manually.
Just to confirm a clean install of 20220515-18 does not auto-update as per this log: radarr.txt. Manual update is the only way to go: radarr-upgrade.txt
I can however confirm that I was able to install on my production NAS and upgraded from 20220510-16 without any issue whatsoever.
Is this a new Bug?
Package Name
radarr
Package Version
20220513-17
Device Model
DS916+
Device Architecture
x86_64
Firmware Version
7.0.1-42218 Update 3
What happened?
Performed a package update from 20210708-15 to 20220513-17 and this was performed successfully and retained the previous configuration. There was however an error on the main screen - "Error parsing column 8 (Language=34 - Int64)". Then an in-app update was performed to the latest release (i.e. 4.1.0.6175) and after restarting, the package failed to start (as reported by the Package Center.
Reproduction steps
Install Log
Service Log
Other Logs