Update SABnzbd to 4.2.1

[Safihre]

Description

Update SABnzbd to 4.2.1.

@mreid-tt @hgy59 Do I need to change anything about the shared folder handling? It's a bit unclear to me.
I look at Transmission, but it seems that is more complicated than SABnzbd needs?

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)

[mreid-tt]

@mreid-tt @hgy59 Do I need to change anything about the shared folder handling? It's a bit unclear to me. I look at Transmission, but it seems that is more complicated than SABnzbd needs?

If you are up for it, the approach would be similar to Transmission as follows:

1. Move away from SERVICE_WIZARD_SHARE in your Makefile and use SERVICE_WIZARD_SHARENAME
2. Simplify your install wizard to just use the share name since the volume selector doesn't really do anything. You should only have one key like wizard_shared_folder_name for the shared folder in your wizard
3. In your service setup, you can just use ${SHARE_PATH} to assign to your shared_folder variable since the concatenation of volume and folder won't be required anymore

That's pretty much it to use the new shared folder handling.

[hgy59]

@mreid-tt since this packages did not use shared resources for DSM 6 before this update (USE_DATA_SHARE_WORKER not defined), it needs some extra testing (of the installer-variables) for updates under DSM 6.

[mreid-tt]

@mreid-tt since this packages did not use shared resources for DSM 6 before this update (USE_DATA_SHARE_WORKER not defined), it needs some extra testing (of the installer-variables) for updates under DSM 6.

Hmm, okay. To refresh my memory, is this like what we did for COPS and read the config file on upgrade to have the user confirm the name of the shared folder?

[mreid-tt]

@Safihre, I've mocked up an upgrade_uifile.sh to replace your upgrade wizard file and added a commit (48b315a) that should address the concern raised by @hgy59 for DSM6.

[ivd-git]

Since this has not been merged yet. Would it be possible to bump to 4.2.1 directly?

https://github.com/sabnzbd/sabnzbd/releases/tag/4.2.1

[Safihre]

Since this has not been merged yet. Would it be possible to bump to 4.2.1 directly?

https://github.com/sabnzbd/sabnzbd/releases/tag/4.2.1

Will do!

[Safihre]

@Safihre, I've mocked up an upgrade_uifile.sh to replace your upgrade wizard file and added a commit (48b315a) that should address the concern raised by @hgy59 for DSM6.

I saw.. But seeing this makes me wonder if we should even do this at all? What's wrong with keeping the "old" way?
Didn't have any complaints before.

[mreid-tt]

I saw.. But seeing this makes me wonder if we should even do this at all? What's wrong with keeping the "old" way?

The motivations for this I believe were documented under #5649. Were there specific concerns you had?

[hgy59]

I saw.. But seeing this makes me wonder if we should even do this at all? What's wrong with keeping the "old" way?

The motivations for this I believe were documented under #5649. Were there specific concerns you had?

The main issue was, that the volume selected in the wizard is not used by DSM 7+. DSM 7 only supports data share resources to use shared folders and those allow the name of the share only.

The redesign of shared folders makes DSM 6 shared folder handling compatible with DSM 7.
As a side effect, it is now possible to use a different volume for shared folders, when the shared folder is created before the installation of a package.

[Safihre]

But do we need the extra steps during upgrade? Since it's already working, why do we need any changes there?
Just don't touch the user's config and it just keeps working?

[mreid-tt]

But do we need the extra steps during upgrade? Since it's already working, why do we need any changes there? Just don't touch the user's config and it just keeps working?

The upgrade wizard file, while appearing substantial, is designed with user impact minimization in mind. The underlying logic can be summarized as follows:

1. Verify the existence of a share name (accessible through either the [DSM6] variable or [DSM7] folder). If present, proceed without displaying this screen.
2. Confirm the existence of a share path (via variable or folder as mentioned above).
3. Extract the share path and name based on information from the package config file (config.ini).
4. Present a screen to the user for confirmation of the correctness of the share name for the upgrade.
5. If discrepancies arise between the package config and the share path, issue an additional warning.

It's important to note that users encounter these steps only once, as the process establishes a share name. Subsequent updates will not prompt the confirmation screen once a share name exists.

[Safihre]

But why is it needed to show anything at all to users that are upgrading? They already have a working share and path.

[mreid-tt]

But why is it needed to show anything at all to users that are upgrading? They already have a working share and path.

I appreciate you bringing this to my attention. One crucial aspect that I failed to clarify earlier involves two primary considerations:

1. The wizard_shared_folder_name resource must be populated by the wizard to ensure accurate provisioning of the data share under DSM 6. Failure to do so could result in an improper setup.
2. While highly improbable, there exists a slim chance of misinterpretation of the configuration, making it imperative for the user to verify the extracted value.

However, there are potential counter arguments for each:

1. One could explore setting the wizard_shared_folder_name in the DSM Permissions screen as a hidden variable, mitigating the need for explicit user intervention during the wizard process.
2. The second point, albeit unlikely, becomes less concerning if the package configuration and share path maintain consistency.

My intention was to exercise caution by providing users with visibility into the value set during the upgrade process. However, if you differ in your risk assessment, I am open to adjusting the wizard to display a confirmation screen only when discrepancies arise between the package config and the share path.

[mreid-tt]

@Safihre I've pushed a commit to take a less conservative approach to the wizard as proposed above.

Oops, I realise I have a spelling error in this line. Please fix when you push your commit to bump to 4.2.1.

spksrc/spk/sabnzbd/src/wizard/upgrade_uifile.sh

Line 37 in a51538d

# If consistent data share path, arrume share name is correct

[Safihre]

Interesting! Will test myself tonight.
Although I only have 1 volume in my own NAS.

[Safihre]

Thank you @mreid-tt, it seems to work for me! I didn't have to confirm my share, and it worked fine after the upgrade.
Should this then also work for DSM 6 or needs more testing?

[mreid-tt]

Should this then also work for DSM 6 or needs more testing?

I've done some tests on my DSM 6 virtual environment as an upgrade from the previous version as well as an in-place upgrade replacement and it seems to work well. @hgy59, should we be good to go here?

[Safihre]

How do we trigger the upgrade step to be shown? I should modify the sabnzbd Config?

[mreid-tt]

How do we trigger the upgrade step to be shown? I should modify the sabnzbd Config?

Yes, I did this experiment under my DSM 7 virtual environment.

1. Downgrade to the published version of SABnzbd v4.1.0-66
2. Manually add read/write permissions to a new folder (e.g. /volume1/git/)
3. In SABnzbd change the Temporary Download Folder (e.g. to /volume1/git/incomplete)
4. Perform manual install of new package to show wizard step

Now running this experiment a second time over the upgraded package will not work because the /var/packages/sabnzbd/etc/installer-variables file was updated with a SHARE_NAME variable. With this present the first condition is met even though the second condition of a mismatched share path is true.

[Safihre]

So, seems good to go then? :)

[Safihre]

Thank you!

[mreid-tt]

I've downloaded the package and manually deployed to my DS916+ and everything seems to be working well.

[gohakn]

Hello just updated to 4.2.1 at my Synology DS1817+ and it`s working well except that my script for forcing Downloads smaller 50MB is no longer working.

Here`s the code which was working since Version 4.0

`#!/usr/bin/python3
import sys

try:
# Parse the 18 input variables for SABnzbd version >= 4.0.0
(scriptname, nzbname, postprocflags, category, script, prio, downloadsize, grouplist, showname, season, episodenumber, episodename, is_proper, resolution, decade, year, month, day, job_type) = sys.argv
except ValueError:
# ...or 11 variables for earlier versions
(scriptname, nzbname, postprocflags, category, script, prio, downloadsize, grouplist, showname, season, episodenumber, episodename) = sys.argv
except Exception:
sys.exit(1) # a non-zero exit status causes SABnzbd to ignore the output of this script

prio = -100 # Default
if int(downloadsize) < 50111222:
prio = 2

print("1") # Accept the job
print()
print()
print()
print()
print(prio)
print()

sys.exit(0)`

Also tried the new code from the WIKI

`import sys

try:
# Parse the input variables for SABnzbd version >= 4.2.0
(scriptname, nzbname, postprocflags, category, script, prio, downloadsize, grouplist) = sys.argv
except Exception:
sys.exit(1) # a non-zero exit status causes SABnzbd to ignore the output of this script

prio = -100 # Default
if int(downloadsize) < 50*1024**2:
prio = 2

print("1") # Accept the job
print()
print()
print()
print()
print(prio)
print()

0 means OK

sys.exit(0)`

Is there any change in 4.2.1??

[Safihre]

Yes. Read the Release Notes / Changelog on https://sabnzbd.org/downloads