Upgrade sonarr build to latest

[Seanstoppable]

Motivation:
The recent 7.1 DSM upgrade kicked Sonarr into a bad state and required repair.
However, there are datastore changes between the current version and the latest such that the data is incompatible with the current SPK version, meaning that Sonarr would not properly load and as a result also can't run the upgrade from the internal upgrader
This left me with the choice of either restarting from scratch (no good backups), or compiling a package from source.
Given I did the latter, it seemed sensible to push a PR for everyone else.

Fixes #5450

Checklist:

• Built Sonarr package successfully (since changes are limited to it)
• Package upgrade completed successfully
• New installation of package completed successfully
• Package functionality was tested
• Any needed documentation is updated/created

Type of change

• Bug fix
• New Package
• Package update
• Includes small framework changes
• This change requires a documentation update (e.g. Wiki)

[Safihre]

You need to increase the SPK_REV, then we can push this.

[Safihre]

@hgy59 this one seems good to me?

[mreid-tt]

hey @Seanstoppable, this seems to be a very similar motivation to #5456. have you read through the discussion there?

Specifically, I was wondering if the problem you encountered was related to the root issues of #5450 and/or Sonarr not auto-updating on package re-install?

[Seanstoppable]

Thanks! I had not seen that. I will add some appropriate context there

[bakerboy448]

#5450 would be why issues are experienced more with sonarr when reinstalls are done - since the data is not purged

but given v3.0.5 is not supported, very out of date, and the current base package being shipped by SynoComm. This should still land.

[mreid-tt]

Thanks! I had not seen that. I will add some appropriate context there

@Seanstoppable actually, I'm hoping you can add some context here since that PR is already closed.

but given v3.0.5 is not supported, very out of date, and the current base package being shipped by SynoComm. This should still land.

@bakerboy448 I don't disagree that v3.0.9 should be pushed; however, I am cognisant that #5456 (which has the identical changes as this PR) was closed without being merged. I was hoping we could better spend our energies in documenting and resolving the root causes of the issues related to upgrades and/or re-installs since these issues will come up again in v3.0.10 and beyond.

[Seanstoppable]

Sure. So, I had previously upgraded to 3.0.9 via Sonarr's own mechanism.
In the recent DSM 7.1.1-42962 Update 2, once complete it said that Sonarr required repair (but no idea why).
Repair seems to be reinstall, as I ended up with 3.0
5.
3.0.9 is, unfortunately, not backwards compatible and so would not start, nor did there seem to be a way to upgrade.
So, I ended up building using spksrc in order to 'fix' the problem and produce a backup.
The 'broken' install sat for a few days, so Sonarr did not upgrade itself.
Happy to try to expand anything here, as well as try to reproduce as much as possible.
I am considering also looking at Sonarr to see if, for example, the upgrade function could conceivably be exposed in this scenario (but given the very specific error, seems unlikely).
Ultimately the problem is the backwards incompatible change from Sonarr that rendered the entire app inoperable after a downgrade.

[mreid-tt]

Thanks so much for sharing these details. I'm still on DSM 7.1.1-42962 Update 1 (I guess Update 2 is not available in my region yet) so I'll definitely be on the lookout for this. Given what you described, I believe your assessment is correct on the actions of the repair function. According to Synology's website:

By clicking Repair you will install the latest version of this package, rather than repair the old one. Please contact the publisher or developer of this package if you still have trouble installing the package.

Given the above and the fact that the latest package contains version is 3.0.5 of Sonarr this would have resulted in database files being unreadable as the schema would have been at the newer version 3.0.9 already. This is similar to what would happen with a manual uninstall and re-install outlined in #5450 which would result in a launch error similar to The DataMapper was unable to load the following field: 'Languages'.

While the package should indeed be updated to the latest supported version, at the core of the issue is the package not auto-updating to the latest Sonarr version via the internal updater as part of its install. I believe there needs to be some work on this and I've asked @bakerboy448 to document the particulars in #5456 (comment).

BTW, have you worked around the issue already? If not, I would recommend the following steps:

1. Stop the Sonarr package
2. Manually move the AppData folder for Sonarr to another location
3. Start Sonarr and perform an internal update to 3.0.9
4. Stop the Sonarr package
5. Manually move the AppData folder (in step 2) back to the original location

Once this is done, your Sonarr should be functioning once again without losing your previous configuration.

[hgy59]

The issue with #5450 is solved (outdated installer code in sonarr package)

My question:
Does this update work with any former installation (with or without prior internal updates)?

[hgy59]

Please keep the former changelog, as this change is not published yet.

Suggested change

	CHANGELOG = "Upgrade to Sonarr 3.0.9.1549"
	CHANGELOG = "1. Upgrade to Sonarr 3.0.9.1549<br/>2. Enlarge the service start/stop timeout to 90 seconds."

[hgy59]

Some suggestions:

• remove the v2 to v3 migration code in src/service-setup.sh
• avoid the use of set_unix_permissions for DSM >= 7
• install config.xml with autoupdate enabled
• create update_required file to trigger the automatic update at service start (see #5456)
• consider to use existing code (see Lidarr) to prevent downgrading at package installation. The idea is to never update the sonarr binaries at package update, but only use the internal updater. And to use the version in the package for new installations only.

[bakerboy448]

remove the v2 to v3 migration code in src/service-setup.sh

I'd suggest keeping this as there are still users out there on v2 for whatever reason.

[mreid-tt]

hey @Seanstoppable, regarding the suggestions above, I've submitted a PR to your repository which should address the improvements requested above. I'm not that skilled with Shell scripts so it was a fair amount of copy and paste from a similar PR regarding Lidarr. Hopefully this should get you most of the way there to have this PR merged.

EDIT: I've done some corrections and submitted a new PR #5511 to the main repository to get this merged.

[hgy59]

@Seanstoppable do you mind to close this PR as we now have #5515 that should fix all current issues and prepares for future package with Sonarr v4 (#5520)?

[Seanstoppable]

Absolutely.