[New Package] Readarr

[EckPhi]

Description

motivation: New e-book collection manager in *arr flavour, Readarr.

Closes: #4801

Checklist

• Build rule all-supported completed successfully
• New installation of package completed successfully
• Package upgrade completed successfully (Manually install the package again)
• 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)

[publicarray]

Welcome and Nice work 👍 but please change the version number (SPK_VERS).

[EckPhi]

Thank you! You are right I got the SPK_VERS from another package.

Poses the fact that their release server only provides the latest release (at least I didn't find a way to request a specific version) a problem?

[publicarray]

@bakerboy448 @ta264 do you think the project is stable enough for production use on Synology devices? With the warning in the wiki in mind:

Readarr is currently in beta testing and thus using the nightly branch. It is generally still in a work in progress. Features may be broken, incomplete, or cause spontaneous combustion.

I personally lean towards to wait until a release (more stable than nightly) is ready.

[bakerboy448]

Recommending waiting until a develop release drops and using that rather than nightly

Develop Dropped late Feb 2022

[hgy59]

@publicarray as this is another "*arr" package that uses the internal updater I prefer to use date as SPK_VER.

Maintain SPK_VER given similar codebase to other *arr packages

[mreid-tt]

@hgy59, @publicarray... I've gone through the code and updated it with the latest enhancements from the other *arr packages over the past few months and should be ready to merge. If the team can give it a last once over that would be great.

EDIT: I've already begun harmonising the changes for the other *arr packages but we can use this as a standard baseline for them and I'll go back and ensure they are all in sync.

[mreid-tt]

@hgy59, @publicarray... while we await the full review of this package, there was a user who tested it and got an error with the internal auto-updater following installation. Their platform details are as follows:

DSM: DSM 7.1.1-42962 Update 1
Model name: DS216play
CPU: STM Monaco STiH412

Per their note (#5574 (comment)), they received the following error in the Readarr log file:

2023-02-05 13:49:27.5|Info|InstallUpdateService|Starting update client /tmp/readarr_update/Readarr.Update
2023-02-05 13:49:27.5|Info|InstallUpdateService|Readarr will restart shortly.
2023-02-05 13:49:27.9|Info|InstallUpdateService|Updater Arguments: 29540 /tmp/readarr_update /volume1/@appstore/Readarr/Readarr
2023-02-05 13:49:29.3|Error|CommandExecutor|Error occurred while executing task ApplicationUpdate

[v0.1.2.1532] System.ComponentModel.Win32Exception (13): An error occurred trying to start process '/tmp/readarr_update/Readarr.Update' with working directory '/usr/syno/synoman/webapi'. Permission denied

Now I tried to replicate the error but could not. My platform details are a bit different:

DSM: DSM 7.1.1-42962 Update 2
Model name: VirtualDSM (DS916+)
CPU: INTEL Pentium N3710

My Readarr log file looks like this:

2023-02-11 09:57:56.6|Info|InstallUpdateService|Starting update client /volume1/@apptemp/readarr/readarr_update/Readarr.Update
2023-02-11 09:57:56.6|Info|InstallUpdateService|Readarr will restart shortly.
2023-02-11 09:57:56.6|Info|InstallUpdateService|Updater Arguments: 14991 /volume1/@apptemp/readarr/readarr_update /volume1/@appstore/readarr/share/Readarr/bin/Readarr /data=/volume1/@appdata/readarr/.config/Readarr /nobrowser
2023-02-11 09:58:17.7|Info|Bootstrap|Starting Readarr - /volume1/@appstore/readarr/share/Readarr/bin/Readarr.dll - Version 0.1.2.1558

What I notice is that the user's updater is starting in /tmp/readarr_update whereas my updater is starting in /volume1/@apptemp/readarr/readarr_update. Would this be contributing to the failed updater? If so, given there should be no significant changes in the build between his armv7-7.1 package and my x64-7.1 package, can you think of any reason for this?

[bakerboy448]

/tmp is not executable on DSM7

None of the updated packages would point to /tmp; sounds like they weren't running the package/version they think they are?

[mreid-tt]

So I was testing this and while it installed find on DSM 6 and DSM 7 and did perform an auto-update, I feel that the way the package launches is different than the other *arr apps. On first install I see this line in the install logs:

2023/04/08 13:30:59	install readarr 20230408-1 Begin start-stop-status start
/var/packages/readarr/scripts/start-stop-status: line 151: 11599 Killed                  ${service} >> ${OUT} 2>&1
2023/04/08 13:32:19	install readarr 20230408-1 End start-stop-status start ret=[0]

Around the same time, the service log shows this:

[Debug] Readarr.Update: Starting /volume1/@apptemp/readarr/readarr_update/Readarr.Update 11599 /volume1/@apptemp/readarr/readarr_update /volume1/@appstore/readarr/share/Readarr/bin/Readarr /data=/volume1/@appdata/readarr/.config/Readarr /nobrowser 
[Debug] InstallUpdateService: Install in progress, giving installer 30 seconds. 

In the app once installed, it seems to be updated correctly. Don't know if this is a concern before merging. Don't see similar logs with Sonarr v4 on fresh install even though it's also a beta that auto-updates.

[mreid-tt]

I've pushed an update to 0.1.4.1596 because I saw in 0.1.2.1558 there was a note on "Don't block task queue for queued update task when long running tasks queued". Re-running the clean install on DSM 6 and DSM 7 now has a clean install log.

@hgy59, @publicarray I believe this should be good to merge. Any objections to this?

[hgy59]

@mreid-tt just updated the wiki page documenting the ports used by SynoCommunity packages (https://github.com/SynoCommunity/spksrc/wiki/SynoCommunity-Used-Ports)