SABnzbd 5: NNTP Pipelining, Direct Write — und die eine Einstellung, die du umlegen solltest

SABnzbd 5 ist inzwischen eine Weile draußen, und die Reihe steht stabil bei 5.0.4 — einem Wartungs-Release auf einer wirklich gewichtigen Major-Version. Wer aktualisiert und sonst nichts geändert hat, lässt das Kern-Feature ausgeschaltet. Hier ist, was 5.x tatsächlich ändert und was sich nach dem Update zu tun lohnt.

NNTP Pipelining — das Feature, das man selbst einschalten muss

Die größte Neuerung in 5.0.0 ist NNTP Pipelining. Normalerweise fordert SABnzbd einen Artikel an, wartet auf die vollständige Antwort und fordert dann den nächsten an. Auf einer High-Latency-Verbindung — ein Server auf einem anderen Kontinent, ein VPN-Hop, alles mit nennenswerter Round-Trip-Zeit — deckelt dieses Leerlaufwarten zwischen den Anfragen den Durchsatz deutlich unter der Leitungsgeschwindigkeit. Pipelining schickt die nächste Anfrage los, bevor die vorherige Antwort vollständig angekommen ist, und schließt damit die Lücke.

Der Haken: Gesteuert wird das über Articles per request, und auf bestehenden Servern bleibt dieser Wert nach dem Upgrade bei 1. Nur neu hinzugefügte Server starten mit 2. Das Nützlichste nach dem Update ist also, jeden Server unter Config → Servers zu öffnen und Articles per request auf 2 (oder höher) zu setzen. Bei einem weit entfernten Backbone ist der Unterschied sofort sichtbar; bei einem lokalen Low-Latency-Provider fällt der Gewinn kleiner aus, aber es gibt keinen Nachteil, es zu aktivieren.

Das SABnzbd-Team dokumentiert die Trade-offs unter sabnzbd.org/wiki/advanced/nntp-pipelining.

Direct Write und ein überarbeiteter Cache

5.0.0 brachte außerdem Direct Write, das optimiert, wie heruntergeladene Artikel zu den finalen Dateien zusammengesetzt werden, statt alles zuerst über den Cache zu schleusen. Zusammen mit einem kompletten Redesign des Artikel-Caches ergibt das weniger Speicherdruck und weniger Disk-Churn bei großen Jobs — am deutlichsten auf schnellen Verbindungen, wo der alte Assembly-Pfad der Flaschenhals war. Eine Erläuterung gibt es unter sabnzbd.org/wiki/advanced/direct-write.

Dazu kam ein Paket an Reliability-Arbeit: besseres Verhalten, wenn eine Disk volläuft, der Speicherplatz-Check berücksichtigt jetzt kategoriespezifische Ordner, schnellere Übergänge zwischen Jobs während des Post-Processings und der Wegfall des nicht mehr benötigten Specials empty_postproc.

Post-Processing-Skripte laufen jetzt immer

Eine Änderung verdient besondere Aufmerksamkeit, wenn man auf eigene Skripte setzt: Post-Processing-Skripte werden jetzt für jeden Job ausgeführt, auch für fehlgeschlagene. Früher konnte ein gescheiterter Download das Skript komplett überspringen. Das ist korrekter, bedeutet aber, dass die Skripte nun selbst den Job-Status prüfen müssen, bevor sie handeln — ein Skript, das von Erfolg ausgeht und anfängt, Dateien zu verschieben, verhält sich bei einem fehlgeschlagenen Job falsch. Wer SABnzbd aus Sonarr oder Radarr füttert, ist davon selten betroffen (die *arr-App regelt Fehler über die API), aber jeder mit Notification- oder Housekeeping-Skripten sollte sie prüfen.

Plattform- und Versions-Aufräumarbeiten

5.x hat die Unterstützung für Python 3.8 fallengelassen, und die mitgelieferten Windows-/macOS-Builds laufen jetzt auf Python 3.14 mit aktuellem Unrar, 7zip und par2cmdline-turbo. Windows hat einen nativen ARM-Build (portable) bekommen, und Windows wie macOS enthalten nun eine HTML-Version der Release Notes. Neuinstallationen setzen außerdem standardmäßig 500M Mindest-Freispeicher für den Temp-Ordner und aktivieren verify_xff_header.

Die Point-Releases 5.0.1–5.0.4 waren fast ausschließlich Fixes: nzo_id-Werte nutzen jetzt GUIDs, um Stalls durch doppelte IDs zu verhindern, Queue-Einträge aus älteren Versionen laden nach dem Upgrade korrekt, das IPv6-Binding fürs Webinterface funktioniert wieder, die RSS-Prioritäten wurden korrigiert, und 5.0.4 hat das gebündelte Python auf 3.14.5 und Unrar auf 7.22 aktualisiert. Wer auf einem frühen 5.0.x ist, springt am besten direkt auf 5.0.4.

Sicher aktualisieren

Von 3.0.0 oder neuer kannst du ohne Sonderschritte direkt aktualisieren. Von allem Älteren verlangt SABnzbd ein Queue repair wegen Änderungen am internen Datenformat — leere die Queue vorher, wenn möglich. Umgekehrt gilt dasselbe: ein Downgrade von 4.2.0+ zurück auf 3.7.2 oder älter braucht ebenfalls ein Queue repair.

Wer SABnzbd in Docker betreibt: das linuxserver.io-Image folgt den Releases eng, ein docker compose pull plus Neu-Erstellen reicht also — nur denk daran, dass der Container-Neustart deine Articles per request pro Server nicht anfasst, der Pipelining-Schritt bleibt also an dir.

Das Update lohnt sich

Nichts in 5.x ändert, wie SABnzbd in den Stack passt — es bleibt der Downloader hinter Sonarr, Radarr oder NZBHydra2. Aber die Pipelining- und Direct-Write-Arbeit macht es messbar schneller auf genau den Verbindungen, wo Speed am schwersten zu holen war, und die Reliability-Fixes sind die Sorte, die man nur durch ihr Fehlen bemerkt. Aktualisieren, Articles per request auf 2 stellen und laufen lassen.

Projektwebsite: sabnzbd.org