Adding Sonarr v3 compatibility

[maxrogers]

Motivation: This PR adds compatibility to upgrade successfully to Sonarr v3 (when released.) Sonarr v3 changes the executable name (NzbDrone.exe --> Sonarr.exe) and data folder/filenames (NzbDrone --> Sonarr.) This package allows proper package upgrades when installing to a v2 or v3 install (or vice versa.)

Checklist

• Build rule all-supported completed successfully
• Package upgrade completed successfully
• New installation of package completed successfully

[ymartin59]

Looks interesting. May you please update version in spk/mediainfo to match with cross/mediainfo

[maxrogers]

@ymartin59 good catch! I added spk/mediainfo. Thanks!

[ymartin59]

@maxrogers Thanks for improvement. Please rebase. I am interested in test reports about running v3 with current Mono version and future one from #3561

[M0UL]

maybe add the mono debug switch to the sonarr startup script. this recommended by sonarr

[maxrogers]

maybe add the mono debug switch to the sonarr startup script. this recommended by sonarr

@M0UL The debug switch used to be in the sonarr package: 7db4ec0#diff-d94600ee9255b9e01269842f7d537893 However, it was removed by someone (not sure when.) I believe it was removed after complaints regarding high CPU usage when using the debug flag. example: #3202

I think it is probably wise to not add the debug flag again unless this potential issue has been resolved (considering many are using nas devices with limited resources.) According to the link I referenced above, if you restart sonarr using the sonarr web interface (not using package manager) it will use the debug flag (I have not confirmed.) Alternatively, perhaps a manual start from command line could be used for debug purposes...

[maxrogers]

@maxrogers Thanks for improvement. Please rebase. I am interested in test reports about running v3 with current Mono version and future one from #3561

@ymartin59 Rebased and squashed. However, if you want to run v3 now you will want to use this for your testing: https://github.com/maxrogers/spksrc/tree/sonarr_v3

You cannot successfully upgrade to the correct/up-to-date phantom (v3) branch using the sonarr upgrade interface in the current v2 package (or using my v3 upgrade compatible PR.) My PR is still loading a v2 binary (2.0.0.5252.) If try to upgrade using the sonarr upgrade interface in current v2 binaries you will get a really old and strangely numbered version of phantom (v3.) The following changes to my PR will get you the correct v3 which will also allow you proper upgrades to the latest v3/phantom betas: maxrogers/spksrc@sonarr...maxrogers:sonarr_v3

Obviously we would not want to add the phantom branch binary to our package. We should wait until it becomes one of the major sonarr branches (develop.) When that happens, my current PR should allow everyone to successfully upgrade at that time (via the sonarr interface on the develop branch.)

[M0UL]

the sonarr v3 branch changed from phantom to phantom-develop
http://download.sonarr.tv/v3/phantom-develop/

[maxrogers]

@

the sonarr v3 branch changed from phantom to phantom-develop
http://download.sonarr.tv/v3/phantom-develop/

@M0UL, thanks for the heads up! I just switched my branch to phantom-develop. However, this PR just gives v3 upgrade compatibility (it actually still installs with a v2 binary.) I should switch the binary in this v3 test package though: https://github.com/maxrogers/spksrc/tree/sonarr_v3

Thanks again!

[m4tt075]

@maxrogers Argh I've overlooked this when sending my PR yesterday. Have you tested your sonarr builds with the updated mono I've been working on? Does it (still) work?

[maxrogers]

@m4tt075 Awesome work! I just tested on a 6.1 system with the updated mono build you posted here: https://github.com/m4tt075/spksrc/releases/tag/mono-5.18-11

It worked great! Thanks

[maxrogers]

@kc6108, if you are comfortable compiling packages in spksrc you can create a v3 Sonarr package (to test out) by modifying three files (as shown below) then compiling your test package:

cross/sonarr/Makefile

PKG_NAME = Sonarr
PKG_VERS = 3.0.1.497
PKG_EXT = tar.gz
PKG_DIST_NAME = $(PKG_NAME).phantom-develop.$(PKG_VERS).linux.$(PKG_EXT)
PKG_DIST_SITE = http://download.sonarr.tv/v3/phantom-develop/$(PKG_VERS)
PKG_DIR = Sonarr

cross/sonarr/PLIST

rsc:share/Sonarr

delete (or create proper digest:) --> cross/sonarr/digests

Also, I am closing this PR since it was merged here: #3657

[Taloth]

@maxrogers What should I put here for instructions? https://sonarr.tv/#downloads-v3-nas-synology
Also, there's also the option now to list the package version+author in System->About for v3, we should probably talk about that separately.

[maxrogers]

@Taloth, thanks for stopping by! The current synology sonarr package Is compatible with v3 but installs with v2.

Upgrading to v3 via the built-in sonarr interface in v2 is not currently allowed, correct? For example: Adding phantom-develop to the branch in a v2 install. If that was allowed, that would be the easiest method for synology users to upgrade to v3 (if it worked.) I assume it is not currently allowed for compatibility reasons with other systems?

The next best option for synology users who want to test the v3 beta would probably be for me to compile a list of beta v3 synology packages and post them here on github until a built-in v2 -> v3 upgrade option is offered.

[Taloth]

We don't plan to offer a v2->v3 update from the UI. There are some breaking changes so we don't want to auto update and also want to avoid ppl doing a blind 'hey update available, click install'.
But also because v3 install is a bit more tightly managed, for debian we moved to our own systemd startup script, for example. That doesn't apply here of course. But we don't want too much magic.

---

Directory Structure and package_info

The new v3 directory structure is slightly different than v2 was:
Binaries were moved to /usr/lib/sonarr/bin.
An optional /usr/lib/sonarr/package_info file was added (NOT in sonarr/bin/)
The package owns that file, the bin dir is owned by sonarr. The builtin updater only updates the bin folder. Although at one point i'd want to use sonarr/bin_tmp and similar for safer and quicker updates.

For the docker image by linuxserver.io the package_info file contains:

UpdateMethod=docker
Branch=phantom-develop
PackageVersion=3.0.1.364-ls5
PackageAuthor=linuxserver.io

The PackageVersion + PackageAuthor shows up in System->About, and best contains a combo of sonarr's version and the package version.
The UpdateMethod can be the default 'builtin'. Or alternatively apt, docker or external, which forcibly disables the built-in updater and enforces the specified branch. The only diff is a specific update message in System->Updates.
The user is always able to switch to Script but setting that option in package_info is pointless since there is no method to provide the script path at this time.

I'd like you to add a similar package_info to the syno package (but then with UpdateMethod=BuiltIn) and of course the appropriate Version and Author.
Adjust the binary directory as well or it won't work, Sonarr only looks for ../package_info if it's Sonarr itself resides in bin (so ${SYNOPKG_PKGDEST}/share/Sonarr/bin).
You can safely add package_info to v2, it's be ignored atm.

---

v3 Beta

I can think of a few options:

1. If you create a beta package and have instructions for beta users to install, then we'd be able to point to that until a real v3 package goes live. The package wouldn't need to be updated constantly since the built-in updater should function.

2. Include a script that experienced users can run from the cmdline, which downloads and install v3.
   You already know the services url https://services.sonarr.tv/v1/download/phantom-develop/latest?version=3&os=linux which redirects to the appropriate download url.

3. The presence of the package_info could be used by Sonarr to detect whether the package is v3 compatible, but you aren't truly compatible since you're moving from share/NzbDrone to share/Sonarr.
   If you were to install v2 in share/Sonarr/bin instead, include share/Sonarr/package_info then we might consider detecting that.
   I'm still not sure if we'd want to offer a UI option for it, but it at least becomes a possibility.

Each option has pros and cons. I think Option 2 is the least work.

We do not provide a v3 release date (and we never have so it was never 'pushed back' either). However we did transition from alpha to beta a couple of months ago.
It's still slightly below v2 develop in terms of stability. Especially since we still do breaking changes.

[Safihre]

@maxrogers I think it's time we provide a package voor V3. Even if we only provide it here, for users to install manually. I also did that when we were in the DSM6 transition and it worked well.
Could you maybe create a V3 package and open a PR? Then we can build all the releases. I have a TravisCI pipeline for that, so they can be hosted by GitHub (for example like this).

[rp4k]

is it possible or am i missing it somewhere but why is the synocommunity repo still showing sonnar v2