SABnzbd 5: NNTP Pipelining, Direct Write, and Why You Should Flip One Setting

SABnzbd 5 has been out for a while now, and the line has settled at 5.0.4 — a maintenance release on top of a genuinely significant major version. If you upgraded and changed nothing, you’re leaving the headline feature switched off. Here’s what 5.x actually changes and what’s worth doing after the update.

NNTP Pipelining — the feature you have to turn on yourself

The biggest addition in 5.0.0 is NNTP Pipelining. Normally SABnzbd requests one article, waits for the full response, then requests the next. On a high-latency link — a server on another continent, a VPN hop, anything where round-trip time is non-trivial — that idle waiting between requests caps your throughput well below your line speed. Pipelining sends the next request before the previous response has fully arrived, eliminating the gap.

The catch: it’s controlled by Articles per request, and on existing servers that value stays at 1 after the upgrade. Only newly added servers default to 2. So the single most useful thing to do after updating is open each server in Config → Servers and bump Articles per request to 2 (or higher). On a far-away backbone the difference is immediately visible; on a local, low-latency provider the gain is smaller, but there’s no downside to enabling it.

The SABnzbd team documents the trade-offs at sabnzbd.org/wiki/advanced/nntp-pipelining.

Direct Write and a reworked cache

5.0.0 also introduced Direct Write, which optimizes how downloaded articles are assembled into the final files instead of staging everything through the cache first. Paired with a complete redesign of the article cache, the result is lower memory pressure and less disk churn on large jobs — most noticeable on fast connections where the old assembly path was the bottleneck. There’s a write-up at sabnzbd.org/wiki/advanced/direct-write.

Alongside that came a batch of reliability work: better behavior when a disk fills up, the diskspace check now accounting for category-specific folders, faster transitions between jobs during post-processing, and the removal of the empty_postproc special setting that’s no longer needed.

Post-processing scripts now always run

One change deserves special attention if you lean on custom scripts: post-processing scripts are now executed for every job, including failed ones. Previously a failed download could skip your script entirely. That’s more correct, but it means your scripts must now check the job status themselves before acting — a script that assumes success and starts moving files will misbehave on a failed job. If you feed SABnzbd from Sonarr or Radarr this rarely matters (the *arr handles failures over the API), but anyone running notification or housekeeping scripts should audit them.

Platform and version housekeeping

5.x dropped Python 3.8 support, and the bundled Windows/macOS builds now ship on Python 3.14 with current Unrar, 7zip and par2cmdline-turbo. Windows gained a native ARM (portable) build, and both Windows and macOS now include an HTML version of the release notes. New installs also default to a 500M minimum free space for the temp folder and enable verify_xff_header.

The 5.0.1–5.0.4 point releases were almost entirely fixes: nzo_id values now use GUIDs to stop duplicate-ID stalls, queue entries from older versions load correctly after upgrading, IPv6 binding for the web interface works again, RSS priority handling was corrected, and 5.0.4 refreshed the bundled Python to 3.14.5 and Unrar to 7.22. If you’re on an early 5.0.x, going straight to 5.0.4 is the obvious move.

Upgrading safely

You can upgrade directly from 3.0.0 or newer with no special steps. From anything older, SABnzbd will ask you to run a Queue repair because of internal data-format changes — finish your queue first if you can. The same caveat applies in reverse: downgrading from 4.2.0+ back to 3.7.2 or older needs a queue repair too.

If you run SABnzbd in Docker, the linuxserver.io image tracks releases closely, so a docker compose pull and recreate is all it takes — just remember the container restart won’t touch your per-server Articles per request, so the pipelining step is still on you.

Worth the update

Nothing in 5.x changes how SABnzbd fits into the stack — it’s still the downloader sitting behind Sonarr, Radarr or NZBHydra2. But the pipelining and Direct Write work make it measurably faster on the connections where speed was hardest to come by, and the reliability fixes are the kind you only notice by their absence. Update, flip Articles per request to 2, and let it run.

Project website: sabnzbd.org