SABnzbd 5: NNTP Pipelining, Direct Write y el ajuste que deberías activar

SABnzbd 5 lleva ya un tiempo disponible, y la serie se ha asentado en 5.0.4 — una versión de mantenimiento sobre una versión mayor verdaderamente importante. Si actualizaste y no cambiaste nada más, estás dejando la función estrella apagada. Esto es lo que 5.x cambia de verdad y lo que conviene hacer tras la actualización.

NNTP Pipelining — la función que tienes que activar tú mismo

La mayor novedad de 5.0.0 es NNTP Pipelining. Normalmente SABnzbd pide un artículo, espera la respuesta completa y luego pide el siguiente. En un enlace de alta latencia — un servidor en otro continente, un salto por VPN, cualquier cosa con un round-trip apreciable — esa espera ociosa entre peticiones limita el rendimiento muy por debajo de la velocidad de tu línea. El pipelining envía la siguiente petición antes de que la respuesta anterior haya llegado del todo, eliminando ese hueco.

El detalle: se controla con Articles per request, y en los servidores ya existentes ese valor se queda en 1 tras la actualización. Solo los servidores recién añadidos arrancan en 2. Así que lo más útil tras actualizar es abrir cada servidor en Config → Servers y subir Articles per request a 2 (o más). En un backbone lejano la diferencia se ve al instante; en un proveedor local de baja latencia la ganancia es menor, pero no hay ninguna desventaja en activarlo.

El equipo de SABnzbd documenta los compromisos en sabnzbd.org/wiki/advanced/nntp-pipelining.

Direct Write y una caché rediseñada

5.0.0 también introdujo Direct Write, que optimiza cómo se ensamblan los artículos descargados en los archivos finales en lugar de pasarlo todo primero por la caché. Junto con un rediseño completo de la caché de artículos, el resultado es menos presión de memoria y menos trasiego de disco en trabajos grandes — más notable en conexiones rápidas, donde el antiguo camino de ensamblado era el cuello de botella. Hay una explicación en sabnzbd.org/wiki/advanced/direct-write.

A eso se suma un lote de trabajo de fiabilidad: mejor comportamiento cuando un disco se llena, la comprobación de espacio ahora tiene en cuenta las carpetas específicas por categoría, transiciones más rápidas entre trabajos durante el post-procesado, y la eliminación del ajuste especial empty_postproc, ya innecesario.

Los scripts de post-procesado ahora siempre se ejecutan

Un cambio merece atención especial si te apoyas en scripts propios: los scripts de post-procesado ahora se ejecutan en todos los trabajos, incluidos los fallidos. Antes una descarga fallida podía saltarse el script por completo. Es más correcto, pero implica que tus scripts deben comprobar ellos mismos el estado del trabajo antes de actuar — un script que da por hecho el éxito y empieza a mover archivos se comportará mal en un trabajo fallido. Si alimentas SABnzbd desde Sonarr o Radarr esto rara vez importa (la app *arr gestiona los fallos por la API), pero quien tenga scripts de notificación o limpieza debería revisarlos.

Mantenimiento de plataforma y versiones

5.x retiró el soporte de Python 3.8, y los builds incluidos de Windows/macOS corren ahora sobre Python 3.14 con Unrar, 7zip y par2cmdline-turbo actuales. Windows estrenó un build nativo ARM (portable), y tanto Windows como macOS incluyen ahora una versión HTML de las notas de versión. Las instalaciones nuevas también ponen por defecto 500M de espacio libre mínimo para la carpeta temporal y activan verify_xff_header.

Las versiones puntuales 5.0.1–5.0.4 fueron casi solo correcciones: los valores nzo_id ahora usan GUIDs para evitar bloqueos por IDs duplicados, las entradas de cola de versiones antiguas cargan bien tras actualizar, el binding IPv6 de la interfaz web vuelve a funcionar, se corrigió el manejo de prioridad de RSS, y 5.0.4 actualizó el Python incluido a 3.14.5 y Unrar a 7.22. Si estás en un 5.0.x temprano, saltar directo a 5.0.4 es lo evidente.

Actualizar con seguridad

Puedes actualizar directamente desde 3.0.0 o posterior sin pasos especiales. Desde algo más antiguo, SABnzbd pedirá un Queue repair por los cambios en el formato interno de datos — vacía la cola antes si puedes. Lo mismo aplica a la inversa: bajar de 4.2.0+ a 3.7.2 o anterior también requiere un queue repair.

Si ejecutas SABnzbd en Docker, la imagen de linuxserver.io sigue las versiones de cerca, así que un docker compose pull y recrear basta — solo recuerda que reiniciar el contenedor no toca tu Articles per request por servidor, así que el paso del pipelining sigue siendo cosa tuya.

Vale la pena actualizar

Nada en 5.x cambia el lugar de SABnzbd en el stack — sigue siendo el descargador detrás de Sonarr, Radarr o NZBHydra2. Pero el trabajo de pipelining y Direct Write lo hace medibles veces más rápido en las conexiones donde más costaba ganar velocidad, y las correcciones de fiabilidad son de esas que solo notas por su ausencia. Actualiza, pon Articles per request en 2 y déjalo correr.

Web del proyecto: sabnzbd.org