SABnzbd 5 : NNTP Pipelining, Direct Write et le réglage qu'il faut activer

SABnzbd 5 est disponible depuis un moment, et la série s’est stabilisée sur 5.0.4 — une version de maintenance posée sur une version majeure réellement importante. Si tu as mis à jour sans rien changer d’autre, tu laisses la fonction phare désactivée. Voici ce que 5.x change vraiment et ce qu’il vaut la peine de faire après la mise à jour.

NNTP Pipelining — la fonction qu’il faut activer soi-même

La plus grosse nouveauté de 5.0.0 est le NNTP Pipelining. Normalement, SABnzbd demande un article, attend la réponse complète, puis demande le suivant. Sur un lien à forte latence — un serveur sur un autre continent, un saut VPN, tout ce qui a un temps d’aller-retour non négligeable — cette attente à vide entre les requêtes plafonne le débit bien en dessous de la vitesse de ta ligne. Le pipelining envoie la requête suivante avant que la réponse précédente soit entièrement arrivée, supprimant ce trou.

Le hic : c’est piloté par Articles per request, et sur les serveurs existants cette valeur reste à 1 après la mise à jour. Seuls les serveurs nouvellement ajoutés démarrent à 2. La chose la plus utile après la mise à jour est donc d’ouvrir chaque serveur dans Config → Servers et de passer Articles per request à 2 (ou plus). Sur un backbone lointain, la différence est immédiatement visible ; sur un fournisseur local à faible latence, le gain est plus modeste, mais il n’y a aucun inconvénient à l’activer.

L’équipe SABnzbd documente les compromis sur sabnzbd.org/wiki/advanced/nntp-pipelining.

Direct Write et un cache repensé

5.0.0 a aussi introduit Direct Write, qui optimise la façon dont les articles téléchargés sont assemblés en fichiers finaux au lieu de tout faire transiter d’abord par le cache. Couplé à une refonte complète du cache d’articles, le résultat est moins de pression mémoire et moins de sollicitation disque sur les gros jobs — surtout visible sur les connexions rapides, où l’ancien chemin d’assemblage était le goulot d’étranglement. Une explication est disponible sur sabnzbd.org/wiki/advanced/direct-write.

S’y ajoute un lot de travail sur la fiabilité : meilleur comportement quand un disque se remplit, la vérification d’espace disque tient désormais compte des dossiers spécifiques par catégorie, des transitions plus rapides entre jobs pendant le post-traitement, et la suppression du réglage spécial empty_postproc, devenu inutile.

Les scripts de post-traitement s’exécutent maintenant toujours

Un changement mérite une attention particulière si tu t’appuies sur des scripts maison : les scripts de post-traitement s’exécutent désormais pour chaque job, y compris ceux qui échouent. Avant, un téléchargement raté pouvait sauter le script entièrement. C’est plus correct, mais cela implique que tes scripts doivent maintenant vérifier eux-mêmes l’état du job avant d’agir — un script qui présume la réussite et se met à déplacer des fichiers se comportera mal sur un job en échec. Si tu alimentes SABnzbd depuis Sonarr ou Radarr, cela importe rarement (l’app *arr gère les échecs via l’API), mais quiconque utilise des scripts de notification ou de ménage devrait les revoir.

Ménage de plateforme et de versions

5.x a abandonné le support de Python 3.8, et les builds Windows/macOS fournis tournent désormais sur Python 3.14 avec Unrar, 7zip et par2cmdline-turbo à jour. Windows a gagné un build natif ARM (portable), et Windows comme macOS incluent maintenant une version HTML des notes de version. Les nouvelles installations passent aussi par défaut à 500M d’espace libre minimum pour le dossier temporaire et activent verify_xff_header.

Les versions correctives 5.0.1–5.0.4 étaient presque exclusivement des corrections : les valeurs nzo_id utilisent maintenant des GUID pour éviter les blocages par IDs en double, les entrées de file d’anciennes versions se chargent correctement après mise à jour, le binding IPv6 de l’interface web refonctionne, la gestion des priorités RSS a été corrigée, et 5.0.4 a mis à jour le Python fourni vers 3.14.5 et Unrar vers 7.22. Si tu es sur un 5.0.x précoce, passer directement à 5.0.4 est l’évidence.

Mettre à jour en sécurité

Tu peux mettre à jour directement depuis 3.0.0 ou plus récent sans étape particulière. Depuis quelque chose de plus ancien, SABnzbd demandera un Queue repair à cause des changements de format interne des données — vide ta file d’abord si possible. La réciproque vaut aussi : rétrograder de 4.2.0+ vers 3.7.2 ou antérieur nécessite également un queue repair.

Si tu fais tourner SABnzbd dans Docker, l’image linuxserver.io suit les versions de près, donc un docker compose pull puis recréation suffit — rappelle-toi simplement que le redémarrage du conteneur ne touche pas ton Articles per request par serveur : l’étape pipelining reste à ta charge.

La mise à jour en vaut la peine

Rien dans 5.x ne change la place de SABnzbd dans le stack — il reste le téléchargeur derrière Sonarr, Radarr ou NZBHydra2. Mais le travail sur le pipelining et Direct Write le rend mesurablement plus rapide sur les connexions où la vitesse était la plus difficile à obtenir, et les corrections de fiabilité sont de celles qu’on ne remarque que par leur absence. Mets à jour, passe Articles per request à 2 et laisse tourner.

Site du projet : sabnzbd.org