Finally giving up on this program...

Get help, report and discuss bugs.
Post Reply
FCrane
Posts: 21
Joined: 19 Oct 2013, 08:04

Finally giving up on this program...

Post by FCrane » 28 Oct 2021, 08:05

Hi!

I'm a long term user of Sabnzbd+ and from time to time I'm checking out alternatives to see if there's anything better out there. NZBGet seems promising, but unfortunately, it doesn't even come close to Sabnzbd+ regarding usability, intuitive usage and functions. Here's why:

1) When downloading an older posting, NZBGet checks for completion and quickly decides it's too incomplete to download. Sabnzbd+ on the other hand, also quickly recognizes it's incomplete, but also finds out there are enough par blocks for repair, so it starts downloading, repairs it and succeeds. Whereas NZBGet fails...

2) NZBGet does not support the "industry standard" file naming scheme "posting{{password}}.nzb" natively, but I have to install Python and a (more or less working) script - which was not easy by the way, because the shell override was necessary to fix cryptic error messages (although Python was installed fine). This is cumbersome and annoying! Also, in Sabnzbd+ I can simply paste a "name{{password}}" when editing the name of a queue item, which makes things a lot easier.

3) Remote controlling NZBGet (e.g. for setting the speed rate, enabling / disabling servers, etc.) can not be done with simple HTTP requests. I'd need to find a way to POST an RPC request, which is annoying, cumbersome and not possible at all in some situations (e.g. the WebParser module of Rainmeter)! In Sabnzbd+, you can control everything with simple and plain HTTP requests, as it should be!

4) When using direct unpacking, NZBGet places the currently unpacking file in the final destination folder (DestDir) without tagging it somehow. This means I can not distinguish between completed and still unpacking downloads in DestDir! I'd need to inspect each folder if it contains an "_unpack" subfolder, which is not only annoying, but also leads to paths that are too long for the file system (under Windows)! Sabnzbd+ simply prefixes "_UNPACK_" to the downloading posting, which makes it possible to immediately see which downloads are still in progress and which are already finished.

5) The History in the WebUI is cumbersome to use. There's no way to quickly purge all succeeded downloads, you always have to confirm which way of "deleting" you want (hiding, removing, etc.), etc. Simply annoying and not intuitive.

6) The Messages in the WebUI are annoying! Always a 1000 "new" messages, even when I clear them I immediately have 1 new message "Messages deleted" - really??? The red number of "new" messages always seems to alert the user that something is wrong... Bad UI design.

7) The WebUI lacks a histogram of the download speed! This is practical to see the stability of the connection, the trend of the download speed, etc. Sabnzbd+ shows this perfectly.

So summing up after a few hours spent with trying to get the most out of the program, NZBGet simply does not cut it. It's ok and probably has its advantages (like speed), but Sabnzdb+ is much better, much more intuitive and user friendly, easier to install and configure (without having to search, install and test extensions, etc.) and it simply works "out of the box" and downloads everything that can be downloaded (and repaired) reliably.

Regards!

Post Reply

Who is online

Users browsing this forum: No registered users and 9 guests