SABnzbd Forums

I run sabnzbd "as a service" on a Windows Server 2012 box for ages, right now I'm on 2.3.7. Basically all is fine, download speed is ok, but I have a strange phenomenon I just don't understand:

Postprocessing basically works normal and at reasonable speed, but once a file is completely post-processed, it takes up to several minutes until the next postprocessing starts. In the meantime downloads continue, but the jobs stay in the "Queue" area althogh they are obviously completely downloaded: job detail shows e.g. "800 MB of 800 MB" and when looking at the job progress, there are no more files/posts left, but the job status does not change from "downloading". After a while, another postprocessing will start normally, and sooner or later all files will complete successfully.

This behaviour doesn't change once all downloads are done and processor usage comes down close to idle. All fully downloaded, but unprocessed jobs stay in the "Queue" section and only one of them at a time is transferred to "History" where postprocessing starts immediately. After it's complete, it takes a long while before the next job is picked up and post processing starts. It looks like there's no activity in the meantime.

If I remember correctly, in the past a file jumped from the "Queue" to the "History" section immediately after downloading and was waiting for postprocessing there. Once a file was processed, the next followed immediately with no gaps worth mentioning between them. My Internet line has "always" been downloading slightly faster than the usual postprocessing, mainly when repairs were required for some jobs, too,, but were somewhere on eye level. Now downloads are completed a long time before postprocessing finishes.

Maybe I shouldn't worry too much, because all jobs will complete - it just looks very odd and takes much longer than it used to because of the gaps between postprocessing the jobs.

After postprocessing, the individual job infos look very normal, for example "Downloaded in 4 mins 2 seconds at an average of 8.4 MB/s", even if the job was in the Queue for another hour after its download seemed complete.

I think I'm quite experienced and tried practically all switches and "Special" switches that could have an influence here - but returned to my "standards" again because there's no return to the original behaviour. Of course caches etc. were cleared several times meanwhile and there were some updates since then, although I will skip 2.3.8 for other reasons. I can't tell when this started as I don't tend to watch the web interface all the time - but it's like this for a while now.

The only thing I can imagine is that the x64 version behaves differently than the x86 - I changed from 32bit to 64bit sabnzbd some time last year, but didn't notice a difference first.

Did anyone else see the same change or have a clue what could be wrong here? Is there anything wrong at all?

Maybe I should add: no Sonarr, no Sickbeard, no categories, no schedules - just a plain sabnzbd setup that downloads everything into one folder.

I think it will be good to do this: https://sabnzbd.org/wiki/faq#freshstart
In your case, this would mean removing your sabnzbd.ini (back it up first) and just setup the most basic settings using only 1 server and setup directories. So don't tweak any special settings/switches.

The things you describe about the Queue usually indicate that a server is lagging and giving timeouts or that your CPU can't keep up.

The Post-processing seems to indicate that potentially there are file-locks that cause SABnzbd to copy the file instead of doing a fast-copy. This can be the case because of virusscanners or other software (even Windows itself) that keeps the file busy.

Thanks for your response. I already tried several completely clean installs of the past three versions, including manual wipes of remaining files in the folders, with the minimum settings as you suggested. I also changed between two very reliable usenet providers just to try. My server processor is not the fastest, but does the job well unless I enables "direct unpack" - so I leave it off. Everything else does not really make a difference.

What I can see from the logfile is a lot of these entries:

2019-04-12 13:12:36,793::INFO::[nzbqueue:876] Found idle job [jobname1]
2019-04-12 13:12:36,825::INFO::[nzbqueue:890] Resetting bad trylist for job [jobname1]

for each job that was downloaded completely (those that don't change their status and remain in the Queue), and these entries are repeated several times for each job until postprocessing finally starts and runs through with no issues. What is a "bad trylist"?

This happens when you loose connection with the server, sometimes in special situations it might not be detected properly. So we have a safeguard.
This does seem to indicate its an interplay of some connections being lost and direct unpack being too heavy for the system. Have you tried increasing article cache maybe?