6 Core apps in the stack

10 Deep-dive guide sections

14 SAB connections tuned

45s Downloader timeout baseline

Make the downloader calmer, cleaner, and slightly faster

This page turns the SAB guidance from the rest of the guide into one practical playbook: what to enable, what to avoid, what improved stability in real testing, and how to squeeze a little more speed out without waking the goblins.

Stability first Speed second Queue sanity Post-processing discipline

Checklist Sonarr Radarr German strategy Quality & Sizes Home

Best use

Use this page when SAB is stalling, unpacking badly, pausing in weird states, or simply not downloading as smoothly as the rest of the ARR stack deserves.

Main outcome

A more reliable SAB setup with fewer post-processing jams, cleaner queue behavior, and a small but real speed improvement.

Core lesson

Bad releases will always exist. The real win is configuring SAB so one cursed archive does not turn the whole warehouse into a hostage situation.

Safe speed rule

Use modest server tuning first. Slightly faster and still stable beats theoretically faster and dramatically broken.

Practical mindset

Treat downloader stability as part of the media pipeline, not as a separate little side quest that only matters when things catch fire.

Introduction

This page is the downloader guide. It starts with the simple setup you need to get SAB online, then shows the safe baseline settings, and only after that moves into the speed and reliability tuning that improved this project in real testing.

If queues have ever looked stuck, ghosted, or emotionally unavailable, this is the page that explains what SAB is supposed to do and how to keep it from becoming the weakest link in the stack.

What SABnzbd Is and Why You Need It

SABnzbd is the downloader in this stack.

Its job is to:

• receive download jobs from Sonarr, Radarr, or Lidarr
• download the NZB data
• repair or verify if needed
• unpack the result
• hand the finished job back so the ARR app can import it

When SAB behaves well, the rest of the stack feels smooth. When SAB behaves badly, everything starts looking haunted even though the real problem is one stubborn archive in a back room.

Download SABnzbd

• Official site: sabnzbd.org
• Direct download page: sabnzbd.org/downloads

For Windows, the normal installer is the easiest starting point.

Install SABnzbd Step by Step

1. Download the installer from the official site.
2. Run the installer and complete the first-launch wizard.
3. Open SABnzbd in your browser, usually on http://localhost:8085.
4. Add your Usenet server details.
5. Set a temporary download folder and a completed download folder.
6. Create clear categories for the ARR apps before the first big search wave.

Recommended categories:

• movies
• tv
• music

That alone prevents a lot of quiet nonsense later.

Basic Configuration First

Before you tune speed, get these things right:

• Usenet server connection
• completed and incomplete download folders
• categories for ARR apps
• cleanup and safety basics

Recommended folder idea:

• incomplete downloads in a temporary folder
• completed downloads in a separate temporary folder
• final libraries managed later by Sonarr, Radarr, Lidarr, and Plex

SAB should be a downloader and handoff point, not the final resting place of your media.

Base Settings I Recommend

For a clean starting point:

• Ignore samples = enabled
• Safe post-processing = enabled
• Fast fail = enabled
• Fail hopeless jobs = enabled
• cleanup list includes:
  • nfo
  • sfv
  • srr
  • txt
  • jpg
  • jpeg
  • png
  • url

Recommended executable blacklist at minimum:

• exe
• com
• cmd
• bat
• scr
• pif

These settings are not glamorous, but they remove a lot of avoidable junk.

Known Good Baseline

The live setup behind this guide behaved better once SAB was tuned like this:

• Direct Unpack = off
• Connections = 14
• Receive Threads = 4
• Server Timeout = 45

This was not theoretical tuning. It came from watching real ARR downgrade waves behave better after the changes.

What Improved Reliability

Turn Direct Unpack Off

This was the single clearest stability improvement.

With Direct Unpack on:

• SAB tries to unpack while the download is still running
• more things overlap
• weird or broken releases create more post-processing drama

With Direct Unpack off:

• SAB finishes the download first
• then does the normal repair/unpack/post-processing path
• slightly slower on paper
• noticeably calmer in real use

Important:

• turning it off does not mean SAB stops unpacking
• it just unpacks after the download completes instead of trying to be clever mid-flight

Safe Speed Tuning

Connections

For the live setup behind this guide, the safest useful bump was:

• from 10 connections
• to 12
• then to 14

That gave a small but real throughput improvement without making SAB unstable again.

Recommended approach:

1. start around 10-12
2. verify stability
3. move to 14 if the server and machine stay happy
4. only go higher after a clean real-world test

Receive Threads

The live setup now uses:

• receive_threads = 4

That is a reasonable tuning value for a normal strong Usenet server and a modern machine.

There was no need to get theatrical with it.

Timeout

The old setup used:

• timeout = 60

That turned out to be a bit generous.

The live setup now uses:

• timeout = 45

Why:

• it is a little less patient with hanging article fetches
• it does not become as twitchy as dropping straight to 30

This is a cleanup tweak, not a magic anti-corruption spell.

Recommended Refinements and Enhancements

Once the basic downloader is stable, these are the refinements that mattered most:

• turning Direct Unpack off
• raising connections carefully instead of aggressively
• using receive_threads = 4
• lowering timeout from 60 to 45
• keeping batch sizes smaller so post-processing does not become a traffic accident

Those changes made SAB both more reliable and slightly faster in real use, which is a nice rare moment when optimization does not immediately bite back.

Why Some Jobs Still Fail

A lot of SAB pain is not actually a SAB configuration problem.

Common real causes:

• Corrupt RAR file
• Repair failed, not enough repair blocks
• Not on your server(s)
• passworded or sketchy reposts
• old incomplete Usenet posts

In other words:

• sometimes the downloader is fine
• the release itself is just cursed

What the Typical Failure Messages Mean

Aborted, cannot be completed

Usually means:

• too many articles were missing on the server path
• the release could not be fully assembled

Repair failed, not enough repair blocks

Usually means:

• the post is damaged beyond what the PAR files can fix

Corrupt RAR file

Usually means:

• the release itself is broken
• not just mildly incomplete

Ghost downloading rows in ARR

Usually means:

• SAB finished or mostly finished the download
• but post-processing or history state did not cleanly hand the job back
• Radarr or Sonarr keeps showing 00:00:00 fake-download rows

That got much better after Direct Unpack was turned off and the queue pressure was reduced.

Batch Size Matters More Than People Want

Large downgrade waves amplify every weakness:

• bad releases
• post-processing jams
• queue confusion
• indexer quota pain

Recommended batch sizes:

• movies: 10-20
• episodes: 5-10

This is not timid. It is the size that worked best in real testing.

What To Do When SAB Looks Stalled

Check these in order:

1. Is SAB actually paused?
2. Is there an active Extracting, Repairing, or Verifying job?
3. Is a single corrupt archive blocking post-processing?
4. Is the queue empty but ARR still shows ghost downloads?

If the problem is a clearly broken job:

• remove the obviously dead history item
• then refresh monitored downloads in ARR

Do not immediately nuke the whole queue unless you truly enjoy rebuilding context from smoke.

Recommended Operating Pattern

For this kind of ARR stack:

• use broad indexers for daily traffic
• preserve specialist or quota-limited sources for the cases where they genuinely matter
• keep downgrade batches controlled
• let SAB stay a downloader, not an experimental performance-art engine

That combination ended up:

• faster enough
• more reliable
• and much easier to trust

Which is about the nicest thing one can say about home-media automation.

Recommended Step-by-Step

1. Download and install SABnzbd.
2. Add your Usenet server and confirm the connection works.
3. Set incomplete and complete temporary download folders.
4. Create the movies, tv, and music categories.
5. Turn on the basic safety and cleanup settings.
6. Test one movie and one episode from ARR before touching advanced tuning.
7. Once the base flow works, apply the known-good tuning:
   • Direct Unpack = off
   • Connections = 14
   • Receive Threads = 4
   • Timeout = 45
8. Keep batch sizes controlled and monitor post-processing behavior.

That gives you a sane downloader foundation before you start asking it to survive your more ambitious ideas.