SABnzbd support

[Safihre]

Hi, I'm from the SABnzbd team and I was wondering if you were interested in making a version of your (very extensive!) plugin for SABnzbd? Our soon to be released version 1.1.0 will add support for Notification-scripts, besides the usual post-processing scripts. I can tell you more about it, if you're interested. I am currently also updating our Wiki and going to add a section on 3rd-party scripts and programs, and would of course list your script!

Although NZBGet is technically superior, SABnzbd's user base is much larger, averaging 2100 installer downloads a day vs. 380 a day for NZBGet (stats from GitHub downloads-API for both). As an extra bit of convincing :innocent:

[gibxxi]

I'm not the developer, but I'd just like to add a comment to the effect that while SABnzbd+ may not have as many features as NZBGet, it's beauty is in it's simplicity. I tried NZBGet on my NAS, and it was very tempremental, so I came back to SABnzbd+. SABnzbd+ just works, that's why I use it.

Both are under constant development, and I get that. But SABnzbd+ is easier to navigate, simpler to use, and works without any serious bugs or issues. Just one request, Don't get rid of the Plush (Gold) Skin. Not a fan of the new UI.

Cheers!

Dan/Gib.

[caronc]

I've got no problem with your proposal at all. My scripts are based on a small framework tool I wrote. If we could make it compatible with SABnzbd, we could easily have full compatibly between all my NZBGet scripts and your app. I realize there are only 3 of them... but hey, maybe others will jump on board after for cross compatibility! Or would you just prefer an entirely separate fork specifically targeting SABnzbd (what you're already proposing)? I can do that too. Just pass along to me some loose guidance as to what arguments I have to work with and how they hook with SABnzbd.

[Safihre]

I think a separate SABnzbd-fork would be best, since SAB's system is much simpler. Maybe there is some simple way to link things like the lib-folder on GitHub between projects?

Currently we found a small bug in 1.1.0RC1 causing the notification text not to be send, but on release of 1.1.0 Final the Notification script will get these 3 arguments supplied on each notification:

notification type-code
notification title
notification text

These are the types of notifications available for users: https://sabnzbd.org/wiki/configuration/1.0/notifications#toc3 A user can choose which type he wants to get for the Notification script. The actual notification type-code that's send to the script will be one of these keys on the left:

NOTIFICATION = {
    'startup': TT('Startup/Shutdown'),        #: Notification
    'download': TT('Added NZB'),               #: Notification
    'pp': TT('Post-processing started'),  # : Notification
    'complete': TT('Job finished'),            #: Notification
    'failed': TT('Job failed'),              #: Notification
    'warning': TT('Warning'),                 #: Notification
    'error': TT('Error'),                   #: Notification
    'disk_full': TT('Disk full'),               #: Notification
    'queue_done': TT('Queue finished'),          #: Notification
    'new_login': TT('User logged in'),          #: Notification
    'other': TT('Other Messages')           #: Notification
}

I tried to use your script in NZBGet but was a little confused where to set which service it should use? But at least in SABnzbd itself there wouldn't be a place to set this within SABnzbd, so would have to be some config file where they set which service to use?

[caronc]

Yeah, you're missing a 4th option containing the string/url identifying the services you want to notify. The 3 arguments you're already passing in are great though! Even if the 4th option was as you say... the location of a conf file where the rest of the content can be parsed from.

Alternatively, if there were just a variable or something you could pass to the script telling it where the SABnzbd config file is (that you guys already provide and manage through your own internal gui). Support for notifications is as simple as adding one more line in it for comma separated URLs.

Make sense?

How NZBGet does it isn't the most amazing tactic, but it works. Essentially they pass everything into their post-processing scripts through environment variables (which means there are A TON defined in memory while NZBGet is running). But as ugly as this system is, it effectively creates shared memory of NZBGet settings variables and processing information at any given time. This method works in both Windows and Linux too which is about it's only perk (but a good one). Not suggesting you do the same, but it's an option. What are your thoughts?

[Safihre]

I am going to discuss this extra parameter with the others, I can see it's use. A second option: how about it having it's own config file in the folder? sabnzbd-notify.ini for example, where you set those URL's?

[Safihre]

Just discussed and we are adding a field in SABnzbd's interface to supply parameters to the script :blush:

Making it:

notification type-code
notification title
notification text
notification parameters

[caronc]

As i started playing with a (forked) solution and then I underestimated all the parsing that takes place in Notify.py itself. There are several different options for supporting all of the unique (and proprietary) notification services. Ideally the code should be refactored so that the bulk of this parsing occurs in all the pnotify libraries I wrote and NOT in Notify.py itself. But that will take some time; I'm not up for that challenge just yet anyway.

In the meantime, I merely wrote a small wrapper for it that should just work out of the box based on all of our above conversation. Just point SABnzbd to sabnzbd-notify.py and you should be good to go. The next phase would be to properly line up the images with each different notification type SABnzbd supports.

# Syntax is just as we talked about:
python sabnzbd-notify.py complete "Hello" "World" url://myurl,url2://mysecondurl,etc

I've already updated the README on the main page to help illustrate this a wee bit better

Would this be a viable solution for you?

Edit: added example and filled in hyperlinks

[Safihre]

Great solution! However, it didn't work for me initially because when opening the sub-process for Notify.py it's missing the python command in front of the path to the script. Probably that isn't necessary on Linux/OSX, but on Windows it is. https://github.com/caronc/nzbget-notify/blob/master/sabnzbd-notify.py#L113

Haven't completely tested it, but the notification-title will be translated by SABnzbd in the user's locale. So for example when SABnzbd is set to Dutch the command would become: python C:\Users\scripts\nzbget-notify-master\sabnzbd-notify.py download "SABnzbd: Download Toegevoegd" "Download blabblalalla.nzb is toegevoegd aan de Queue" json://safihre.com So there's no need to map the type to a title, SABnzbd will provide that!

EDIT: Will create myself an account on one of the services to test it for real now. We will release 1.1.0RC2 later this week that will send the parameters correctly, then I can more fully test it.

[caronc]

Great find! I don't have a Windows machine to test with so I'd have never caught that. This last commit should stick python up front in the subprocess call and hopefully make it work for you (for Windows detected systems)

You should be able to pass in anything you want without any problems at all. Notify.py is built on the Markup language used by Reddit/GitHub too, so if you want to send more details in the body and style them this way; they are easy on the eyes for clear text, and they'll convert to HTML if the service supports it before delivery.

Good luck!

[Safihre]

Thanks! One last question: I see references to images to be displayed with the notification, how should we supply those? Is there a specific size? We have a couple sizes of our logo hosted on sabnzbd.org!

[caronc]

Unfortunately that is not done yet (the image mappings). I can focus on that next though.

The current images have an NZBGet type logo I put in them. I can redo these and take the logo out of the center so they're more general (src) if you'd like. Then there is nothing further required of you other then letting me know the image mapping you'd like.. maybe something like (see comments):

NOTIFICATION = {
    'startup': TT('Startup/Shutdown'),        #: Blue
    'download': TT('Added NZB'),               #: Blue
    'pp': TT('Post-processing started'),  # :  Blue
    'complete': TT('Job finished'),            #: Green
    'failed': TT('Job failed'),              #: Red
    'warning': TT('Warning'),                 #: Yellow
    'error': TT('Error'),                   #: Red
    'disk_full': TT('Disk full'),               #: Red
    'queue_done': TT('Queue finished'),          #: Green
    'new_login': TT('User logged in'),          #: Yellow
    'other': TT('Other Messages')           #: Blue
}

I generated 3 sizes 72x72, 128x128 and 256x256 of each image, but if i recall, the only size i'm using at the moment is the 72x72. The others are just there for different services as or if they offer support for higher resolutions.

If you want to provide your own images, there is nothing wrong with that option either. I either need one 'per' notification type, or we can group them like I'm doing already.

[Safihre]

Another small SAB-specific thing I found: when everything goes well, the script should exit with sys.exit(0), sabnzbd-notify.py reports Anything above 0 means no succes in SAB-scripts. :blush:

[Safihre]

I noticed when I get notifications it will say NZBGet-Notify. I know it's not really in my place to suggest things like this, but would you be open to naming your script NZB-Notify for example? This makes it nice and general :) If you rename a repository, GitHub will automatically re-direct any URL's from the old address to the new.

But otherwise we can still promote NZBGet-Notify of course, the name is just a detail :)

We have these images already online: https://sabnzbd.org/images/icons/apple-touch-icon-76x76-precomposed.png https://sabnzbd.org/images/icons/apple-touch-icon-120x120-precomposed.png https://sabnzbd.org/images/icons/apple-touch-icon-152x152-precomposed.png https://sabnzbd.org/images/icons/apple-touch-icon-180x180-precomposed.png https://sabnzbd.org/images/icons/android-192x192.png

[caronc]

Tonight when i'm home, I'll focus on setting up images... I think what I'm going to do (for round 1, and just to have something working for you sooner), I'm going to leave the current structure as is:

• nzbget-notify-failure-XxY.png (red)
• nzbget-notify-info-XxY.png (blue)
• nzbget-notify-success-XxY.png (green)
• nzbget-notify-warning-XxY.png (yellow)

Tonight I'll rename them to nzb-notify-type-XxY.png and I'll eliminate the reference to NZBGet in the icons themselves. I'll have them just read NZB and tie them back to your existing (predefined SABnzbd) types.

There are not a lot of services use the images anyways. I think PushOver and Growl are 2 that stand out; but that's about it.

Sorry about the return-value not being zero (that's what I had in mind) but broke it in an earlier commit (34a141d). You should be good to go now though! :)

[Safihre]

Ohh no don't worry about the images :) Especially because we have PushOver and Growl build-in to SABnzbd and I think there we indeed send the logo. Was just wondering because I read it in your code!

This is great! Ahead of the 1.1.0RC2 release I already put a link to here on the Wiki pages: https://sabnzbd.org/wiki/advanced/user-notification-scripts https://sabnzbd.org/wiki/configuration/1.0/notifications#toc11

Later will also mention it on the page with example extensions/scripts/etc!

[caronc]

Great! the only caution I have is that I've only checked all of my code into the master branch at this point (not a release). Hopefully no one will pull down a release and vent their frustration as to how it doesn't work for them.

I will finish with the images tonight though and hopefully get around to making a release out of it though.

With respect to your first comments you posted when creating this ticket (followed up by a comment by @gibxxi): Although I swear by NZBGet, I've used SABnzbd for years prior and have total respect for you guys. I've got no problem helping your cause out in any way I can. Just let me know! Your product has always been easy to use; there is no denying that.

On a side note, I started designing my own usenet crawler (a long way to go) as a proof of concept and to learn more about it. It focuses a lot on the test suite aspect and all of the actual NNTP protocol response codes. I'd be lying if i said I didn't peak at how you guys did certain things (along with NZBGet's implementation, etc) before coming up with my own. Will eventually get around to having it handle NZB files, posting (with obfuscation ready settings), as well as enhancing it's indexing functionality (blacklists, whitelists, scoring etc)... Anyway... you may or may not be interested in it; but just thought I'd throw it at you anyway! ;)

[Safihre]

The core of SABnzbd is old, really really old. Besides the server priorities system, things have probably not changed much in 5-10 years. I saw your code and see you use gevent, maybe this will be a good way to go to improve performance! Currently SAB is just not able to keep up on 500MBit+ connections. The downloader-loop that opens sockets and monitors their progress is just very slow an CPU consuming, especially since nowadays people get 50 connections from each provider that all need to be managed. But also the yEnc is a bottleneck, yes, this is already done in a C-module, but the whole decoder and overhead is killing. I wish we could start from scratch with the main downloading part, with some python experts that know all these tiny little performance tricks. I know there's more in python than we are getting from it now.. Just no idea where to start, it's just too much code!

[Safihre]

@caronc SABnzbd 1.1.0 is out now and for any notification desires we're redirecting them to you, also on our Wiki 😃

[caronc]

No problem! ☺ Would you be okay if I closed this ticket? I guess we're done here (for now).