Very buggy, unfortunately...

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

Very buggy, unfortunately...

Post by FCrane » 28 Jun 2019, 15:11

Hi!

I'm tresting NZBGet and although it looks very promising, it's full of little (and big) bugs.

1) It crashes randomly - without any error message. It's simply gone from one moment to the next. Seems to happen while downloading (probably with direct unpacking - hard to tell...)

2) When double-clicking the NZBGet icon on the desktop with the program already running, it displays the dialog asking me what to do. When I select "Show Web interface", nothing happens. Works fine if I open Chrome and enter "127.0.0.1:6789" manually.

3) When opening the web interface via the tray icon, Chrome opens and displays "Oops, something went wrong...". Works fine if I open Chrome and enter "127.0.0.1:6789" manually.

4) Downloaded items that seem to have been postprocessed and unpacked correctly, sometimes still stay in the "Downloads" list with the status of "Postprocessing", although nothing is done with them.

5) The "intermediate" directory collects orphaned jobs - some have completed successfully long time ago, but there is still a folder with some files in it.

Also, it lacks some very important features:

1) Importing nzbs named "filename{{password}}.nzb" should be supported natively! This format is used so widely that it's a shame to have to install python, install strange half-working scripts, etc. This is so easy to implement - and impossible to understand why it is not supported directly by NZBGet...

2) The free space remaining on the download drive should be displayed directly on the web interface, not only hidden in a sub dialog. SHould be visible immediately if the queue can be completed or not.

3) The "Est Time" should not display the time needed for just this one download, but the total time needed until this item will be completed (including all those before it). Would make much more sense, because what's the point of knowing that a download will take 2 minutes, if there are 200 queue items before it and another 100 after it? Should I manually add all download time to know when I can expect a single one to be finished? Not very logical...

I don't see any of these issues with Sabnzbd on the same system (Windows 10 x64, 6 GB RAM, 500 GB SSD). Only thing that seems to work better in NZBGet is sending a download from another computer with NZBDonkey - this sometimes fails with Sabnzbd and that's why I was looking for an alternative. Unfortunately, although NZBGet looks very promising, it's not quite there yet...

Regards!

hugbug
Developer & Admin
Posts: 7435
Joined: 09 Sep 2008, 11:58
Location: Germany

Re: Very buggy, unfortunately...

Post by hugbug » 28 Jun 2019, 19:09

Good that we have this forum to report and discuss issues. Maybe I can even fix some of them.

1. An error message box is usually shown on crash. Moreover at least a one line error message should be written into log. Have you checked the log-file? Much more useful info can be collected with debug build - please see https://nzbget.net/crash-dump. If the process just terminates - could it be that some other program is doing this? That'd be strange though but who knows. Anyway with debug build and crash dump this can be catched.

2. Looks like the second program instance (launched via desktop icon) isn't communicating properly with the first instance. To figure out what is happening I need to build a special version with more logging in related code. I would send you such version to try if you are willing to help with debugging this.

3. Does this happen every time? Please check JavaScript error console in browser for any error message that might help.

4. When that happens, please refresh the browser page or close the page and open. Does this change anything? What I'm trying to find out with this: is webui not updating or the queue items are stuck. If queue is stuck then creating a memory dump of the running process can be extremely helpful to me. Please see the link for crash dumps above.

5. If the program crashes often, some files indeed can be left because the program state may not be saved properly.

About "missing" features. Whether some feature is desperately needed or a ballast depends on ones point of view and personal needs.

1. There is a solution as you know already. If you don't want to install Python that's not a good excuse. There are many useful scripts. I can't embed them all and that would be against the idea of users extending the program. You should install Python, you might find other scripts useful too. One day you might write your own script to automate something that no one but you needs.

2. Free space is not such important information to be put on front page. Again, this is a personal opinion. Moreover this also a design thing and in no way a lacking feature. BTW, if you constantly have disk space issues you probably need a larger disk.

3. Predicting completion time is not possible because post-processing time can not be estimated: repair, unpack, executing scripts - that can take any amount of time.

MrVideo
Posts: 41
Joined: 20 Mar 2019, 05:44

Re: Very buggy, unfortunately...

Post by MrVideo » 29 Jun 2019, 02:56

My 2 cents:

If you don't like how often nzbget crashes, run nzbget under Linux. I've never had nzbget crash under Linux. Don't get me wrong, I also run three Windoze boxes: one XP-32 and two Win7-64. The XP because of required programs that will never be updated for Win7.

Python is pretty much installed by every Linux user out there. As mentioned, not installing it is an excuse. It isn't a program that runs in the background and eats up CPU. It only runs when needed.

Having tons of features installed that will never get used by many a user, only results in a bloated program that can easily get slowed down. I have only added two scripts: unzip and pfftn_2x. The first one will take and unrar a downloaded rar file (or unzip it) to extract the nzb file. The second one handles the {{password}} extraction. Those are the only ones I need. By having an extendable program keeps it from getting bloated, as you only have installed what you need.

Like I said, my 2 cents.

Chudz
Posts: 2
Joined: 08 Mar 2019, 09:41

Re: Very buggy, unfortunately...

Post by Chudz » 27 Jul 2019, 13:07

I run 3 Linux servers with NZBGet on and they all have issues/crashes.

It seems some nzbs will crash it during unpack and get loads of random characters in the logs. I removed the file that was causing the issue and Radarr grabbed it again and it crashed the same. Happens on all 3 servers so its not hardware faults. This isn't just 1 file it happens at least once a week for me. Installed SABNZBd and it downloads the problems files no problem.

hugbug
Developer & Admin
Posts: 7435
Joined: 09 Sep 2008, 11:58
Location: Germany

Re: Very buggy, unfortunately...

Post by hugbug » 27 Jul 2019, 15:24

A reproducible crash is a fortunate issue. Can you please provide me with the nzb-file in question (nzbget@gmail.com)?

Was nzbget installed using official installer from nzbget home page? If that's the case please install the debug version of nzbget and create crash dump file as explained in https://nzbget.net/crash-dump. Even better (if you have time for this) do this multiple times (with the same nzb which crashes) and create multiple crash dumps. That helps a lot to find and fix the issue.

Thank you.

Post Reply

Who is online

Users browsing this forum: No registered users and 9 guests