Support Forum

madburg wrote: ↑February 17th, 2026, 6:04 am SABnzbd performs the actual extraction (decompression) process within the incomplete folder (temporary folder).

No, it doesn't. It unpacks to an _UNPACK_<nzbname> directory in /complete, which it renames to <nzbname> when the unpacking is done.

The optimisation of decompressing files has nothing to do with what is being requested in this thread request, I would ask that you read and try to understand what is being requested. If you understood what I wrote and how SABnzbd works then you wouldn't have replied so arrogantly so please take yo...

Just so I'm on the same page, are you saying because when the RAR files are decompressing, SABnzbd needs to do both; read the compressed RAR file and write the decompressed file thus causing the slow down? Depends on what you mean by "the slow down" but yes, it will read the RAR files and...

Some of you do not seem to be aware that most usenet content is RAR compressed. SABnzbd will download the RAR files to the incomplete dir and unpack them to the complete dir. Because of this, if you put the incomplete and complete dir on the same disk then that will usually be much slower than havin...

Using the root of a drive that you have filled with other stuff as temp isn't the best idea, but someone who does that will probably click delete on auto pilot as well. You could add a verification step to make it very clear what's going on. "Are you sure you want to DELETE all these directorie...

What does the sabnzbd script you are starting contain?

With that kind of setup you might see a difference if you tweak receive_threads and switchinterval slightly up or down in Config/Special. receive_threads is the number of Python threads used for handling download connections and switchinterval is https://www.geeksforgeeks.org/python/python-sys-setsw...

Is Config / Folders / Minimum Free Space for Temporary Download Folder set to a high enough limit for it to stop before the disk is actually full? Otherwise it won't be able to pause and recover gracefully. Also it only checks the default download disk so it won't work if it's a category writing to ...

The version available in Debian is ancient. You'd be better of running it from source. Unpack it or check out with git and then run "python3 -m pip install -r requirements.txt" to install the requirements. I'm not sure if that will fix your problem though. Are you trying to contact it from...

How many connections are you using for each server? Seems like you've tested almost everything. If you are using all the available connections then my last suspects are the router or the ISP. Speed test sites can give a false impression because ISPs almost always optimize those connections.

It's an old DS... i know. But with NZBget i get better download speed while unpacking. I don't know why that would be. It's possible that your nice or ionice values give unrar priority over SAB and that's why it takes so long to save the new data. Another alternative is that SAB uses more RAM and t...

Does the download disk have a lot to do? The downloading is technically not paused, it's just SAB letting you know that it is unable to write the data as fast as it is downloading it. For some reason it has to wait up to 30 seconds to clear the buffer of downloaded data. That's very unusual. It woul...

There isn't much documentation other than what's in the code. The known issues are mostly what's on Github: https://github.com/sabnzbd/sabnzbd/issues I fixed a bug related to stalled downloads a while ago, maybe it can point you in the right direction: https://github.com/sabnzbd/sabnzbd/commit/fd3ec...

The NZB has a file with no segments (no actual data to download). It's the indexer that has to fix it.

Curious. I have added your description to this bug: https://github.com/sabnzbd/sabnzbd/issues/2517