Add VideoSort to nzbget and nzbget-testing?

[cxhamilton]

Would there be an appetite to add the VideoSort script added to the nzbget and nzbget-testing packages? I think that it would be a good addition for those of us who let VideoSort handle renaming and relocating of downloaded media (as opposed to SickBeard, Sonarr, CouchPotato, etc.). Not to mention that VideoSort is written by hugbug.

https://github.com/nzbget/VideoSort

I would be happy to do the work and submit the pull request, but I would like to get buy in from the repo owners before doing so. Thanks!

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Dr-Bean]

Personally, I don't mind if you add it. I have no idea how popular or necessary it is, I've never used any of them.

We might want to rethink the way we include the pp-scripts though. Instead of cloning multiple repos for every build, maybe its possible to move the three of them (nzbToMedia, GetScripts and VideoSort) into a separate cross package, and add that to the DEPENDS of both the NZBget and -testing packages?

[cytec]

+1 for rethinking the whole scripts stuff...

mainly because i've added a bunch of extra scripts i personally use a lot, which i have to backup (copy&paste) every time i update nzbget... maybe we should move scripts to the var folder ... as this is something every user should take care of by himself...

[Diaoul]

We have a lot of users for those scripts and a user friendly way to install them is needed.

[Dr-Bean]

Using var instead of share has its own issues. We have no control over the contents of var once the package is installed. That means that upgrading the scripts would become impossible, so that's no good.

An important realization is that (prob depending on your point of view) we provide the current set of ppscripts for convenience/quick start.
Users who want to expand their collection of ppscripts/develop scripts/what have you can simply change the default ppscripts dir in the NZBget config to a more accessible location. E.g. set up a shared folder /volume1/ppscripts and replace the current location in the config. No need to be bothered by package upgrades ever again ;)

[Diaoul]

+1 with @Dr-Bean. If we want it to stay that way probably we can document this in a wiki?

[cxhamilton]

I do not disagree with the discussion, but I was thinking about the addition in terms of @Dr-Bean 's comment:

we provide the current set of ppscripts for convenience/quick start

From a SynoCommunity perspective, I think there is value with providing a reasonable set of stock scripts that have been selected for "the broader audience". Beyond that, users should choose a folder for their ppscripts that lives outside of the installed app folders.

Thoughts?

[Dr-Bean]

@cxhamilton +1 on that. We can certainly include a (small-ish) curated set of scripts in the packages. I imagine we can come up with criteria for what is 'acceptable' in terms of inclusion: stable, proven, maintained, useful for a majority of users, practical to use, etc.
Whether or not a particular script adheres to those criteria can be decided upon request (with @cytec, @Diaoul and yourself as gatekeepers).

Anything outside of the default included scripts then falls into user-territory, where we (SC) may have a role in documenting the process, specific to Synology (limit the amount of work on CLI where possible, for instance)
Any takers on writing a wiki article?

As for VideoSort, assuming that it falls into the 'acceptable' category, by all means, go ahead and open a PR.

[cytec]

the downside of changing the dir is that a user has to update those scripts manually once the folder is changed... in my opinion the optimal way would be if nzbget supports more than one ScriptDir so we could use the one provided by the SPK as default and the user can add his own dir to expand those scritps but that would be a nzbget issue :)

for now im good with the option mentioned by @Dr-Bean i'm gonna throw in my NZBPass.py Scan Script which extracts SAB style passwords from the filename: https://github.com/cytec/nzbget-scripts/blob/master/Scan/NZBPass.py

[Dr-Bean]

update those scripts manually

Or consider creating a script which loops through the subdirs of the current dir, and runs a git pull in each. Add instructions in the wiki article to save the script in /volume1/ppscripts (or whatever), and how to set up a recurring task in Task Scheduler for it.

[Diaoul]

Or we can provide a nzbget-scripts package separatly that contains a bunch of scripts that we can update separately.

[Dr-Bean]

Yeah, but wouldn't you run into exactly the same issue as with using the share dir in the nzbget package? If it's user-accessible, then once created, we don't control the location anymore. Either people control the contents (e.g. add scripts, adjust scripts, and even update scripts), or we do. If the latter, that means that e.g. @cytec still has the same issue with restoring additional scripts. If the former, then we might break stuff when updating.

edit: clarify wording.

[Diaoul]

We can make it so the user doesn't get to chose the install dir. Also with this, we can make a background task that creates symlinks from a user defined dir to our closed directory (/usr/local/nzbget-scripts/share/scripts/) and this allow both user to add scripts and our default scripts.
The idea is to decouple scripts from nzbget and support both default and user defined scripts.

What do you think?

[Dr-Bean]

At first glance, I see a lot of possible complications, but it's growing on me ;)
Maybe use an install wizard to set the user-defined dir, or an interface of sorts to manage it, something like that?

[Diaoul]

An interface is good, although developing interfaces takes some time and the current UIs would benefit from an update for DSM 6.0 look and feel. As there is no hurry I think we can see this as a long term goal.

[cxhamilton]

An interface as in a stand-alone app that is used within DSM?

[Dr-Bean]

Yes, e.g. similar to Debian-Chroot. In this case, it's a nice-to-have, and unless someone has a lot of time on their hands, we'll probably never get to it ;)

[baz1860]

Would it be better to make a request with @hugbug initially to have an
extra option added to nzbget to add a second pp scripts folder on top of
the provided one?

We could then have a curated set of scripts installed to a folder that we
update via SynoCommunity as well as the ones provided via nzbget. No GUI
would then be required.
On Fri, 13 Nov 2015 at 08:47 Dr-Bean notifications@github.com wrote:

Yes, e.g. similar to Debian-Chroot. In this case, it's a nice-to-have, and
unless someone has a lot of time on their hands, we'll probably never get
to it ;)

—
Reply to this email directly or view it on GitHub
#1921 (comment)
.

[hugbug]

Diaoul:

We can make it so the user doesn't get to chose the install dir. Also with this, we can make a background task that creates symlinks from a user defined dir to our closed directory (/usr/local/nzbget-scripts/share/scripts/) and this allow both user to add scripts and our default scripts.
The idea is to decouple scripts from nzbget and support both default and user defined scripts.

The most important thing:
When updating nzbget don't replace the content of ppscripts-dir but rather update files there. There are only two such files included with nzbget (Logger.py and EMail.py) and only they should be replaced (updated).

Depending on how the package system works (I don't know details) you could install the default scripts into a directory which isn't directly used by nzbget and then copy the scripts into ppscripts-dir in a post-install step.

For extra scripts you can:

1. consider the ppscripts-dir non-configurable by user.
2. create a separate package or multiple packages for extra scripts. These package can install scripts directly into ppscripts-dir (hardcoded path) or into other location and create symlinks in ppscripts-dir.
3. to update other scripts their packages must be updated (or one package if you decide to put everything in one big package).

I personally think that users should learn how to install scripts on their own. Everyone benefits from this:

• Synocommunity maintainers have less work to do;
• users can use all scripts; not only the provided ones;
• users can update scripts without waiting for package updates;
• if a problem with a script arises the script authors can provide users with fixed versions and users know how to install them.

[Dr-Bean]

Thanks @hugbug. Ftr, I think this whole discussion was aimed at making it easier for users to install scripts on their own, but we'd still like to provide a starting point :)

So the following seems to be where we're heading:

• We set up a separate package, say nzbget-scripts (Q: can the scripts also be used by SABNzbd by any chance? We could create generic postprocessing package if that's possible. but I have no idea)
• Provide a set of default scripts in /usr/local/nzbget-scripts/share/scripts/
• Logger.py and EMail.py should still be made available, so add a symlink from /usr/local/nzbget/share/scripts to /usr/local/nzbget-scripts/share/scripts/ as well.
• Add a wizard to allow users to set their own location, and symlink the whole dir to /usr/local/nzbget-scripts/share/scripts/ (seems subdirs are not an issue with a quick test. Otherwise, we need a background task as Diaoul already mentioned).
• maybe a background task to periodically do a git pull where a .git dir exists, but it's probably more sensible to just update the package regularly, at least to start off.
• We need some logic in the backup/restore functions to ensure that the previously created symlinks are not destroyed on package update.
• Set the new ppscripts dir in the nzbget packages during postinstall.
• Probably set the original dir on preuninstall to clean things up afterwards.

Any holes in that?

[Dr-Bean]

The wizard should probably ask which of the nzbget packages is installed, to adjust the correct config file. A checkbox for each package in the wizard?