Funciones

La versión corta arriba, el detalle completo abajo.

  • NNTP en pipeline a velocidad de línea: 8.31 Gbps medidos en 10 GbE.
  • Pipeline de una sola pasada: decodificación, verificación y extracción se solapan; los volúmenes RAR nunca tocan el disco; los archivos anidados se desempaquetan en la misma pasada.
  • Disponibilidad por unión de proveedores: completa desde la unión de tus servidores, o aborta a tiempo.
  • Presupuesto de memoria: RAM acotada, desbordamiento controlado a disco, nunca hace swap.
  • Reanudación a prueba de fallos: diario a nivel de artículo; mata el proceso con kill −9 a mitad de trabajo y retoma donde lo dejó.
  • APIs compatibles con SABnzbd + JSON-RPC de NZBGet: Sonarr/Radarr/nzb360/LunaSea funcionan sin cambios.
  • Indexador integrado: escanea grupos hacia un índice local, con búsqueda y servidor Newznab.
  • Muro de pósteres: carátulas, valoraciones, reparto, rejillas de episodios; sin claves API.
  • Captura automática por lista de seguimiento + mejoras de calidad: captura en cuanto aparece y mejora hasta la calidad objetivo.
  • Un solo ejecutable autocontenido: par2 + extracción RAR integrados.

Motor y velocidad

  • NNTP en pipeline. Mantener varias solicitudes en vuelo por conexión vence a la vez a la latencia de ida y vuelta y al decaimiento de la ventana de congestión de TCP. Medimos entre un +12% y un +270% frente a la descarga en serie, y con unas 8 conexiones por servidor basta para saturar la línea.
  • Decodificación yEnc con SIMD (rapidyenc, con kernels NEON y AVX) que rinde a 4.95 GB/s por núcleo, decodificando in situ a medida que los bytes llegan por la ruta de recepción.
  • Cola compartida entre servidores. Los proveedores se equilibran solos hasta un margen del ~2% sin ningún ajuste. Se mide la velocidad real de cada uno y el tramo final del trabajo se despacha por duplicado, de modo que un servidor lento no alargue el cierre.
  • Solapamiento entre trabajos. El final del trabajo N se solapa con el arranque del N+1, así que la línea sigue encendida de extremo a extremo a lo largo de toda la cola: un 2% de inactividad frente al 61% a oscuras de SABnzbd en el mismo benchmark.
  • Vigilante de trabajos lentos. Una descarga que se arrastra en un servidor lento mientras el resto está parado pasa al final de la cola -conservando el progreso- y se reanuda cuando la cola se despeja.
  • Precarga en servidores inactivos: un servidor que el trabajo activo no puede usar, porque sus artículos no están ahí, arranca el siguiente trabajo de la cola en vez de quedarse parado.
  • Escalera de ajuste de conexiones. En vez de adivinar, mide en qué punto deja de subir de verdad el rendimiento de cada proveedor -conexiones pedidas frente a concedidas- y se queda ahí.
  • Regulador automático de velocidad: un regulador RTT opcional al estilo LEDBAT que cede ante el resto del tráfico de tu casa y se queda con lo que sobra de la línea.
  • Límites de velocidad y programación semanal: topes ajustables en vivo, una programación en hora local (a prueba de cambios de horario) y un «pausar durante N minutos» que se reanuda solo.
  • Presupuesto de memoria. Un único presupuesto global de RAM (auto: una cuarta parte de la RAM, con tope y configurable). Cuando aprieta, primero encogen los búferes, luego los datos se vuelcan a disco y se releen cuando el trabajo se asienta. Nunca hace swap. Un trabajo de 190 GB termina dentro de un presupuesto de 1 GB con ~1.1 GB de RSS pico, y hay un perfil de 2 GB medido y documentado para equipos NAS.
  • Contrapresión. Un disco lento frena los sockets en lugar de dejar que se llene la RAM: se mantiene dentro de un ±1% de un tope de escritura y la RAM incluso baja bajo presión.
  • Recorte de memoria tras cada trabajo: en cuanto queda inactivo, el daemon devuelve al sistema la memoria liberada y baja a unos 8 MB entre trabajos en macOS.

El pipeline de una sola pasada

  • Escribe una sola vez. Los artículos decodificados se escriben con pwrite directamente en su posición final del archivo. Sin archivos temporales, sin una pasada de ensamblado aparte.
  • Verificación PAR2 en el flujo. Cada bloque se resume con MD5 desde los búferes de decodificación según llega, así que la verificación acaba en el mismo instante que la descarga. Supera al quick-check con el que se conforman los demás clientes, y no cuesta nada.
  • Extracción directa: las publicaciones RAR en modo almacenamiento (la mayoría de los lanzamientos de escena) se mapean y se extraen mientras se descargan, así que los volúmenes ni siquiera llegan a tocar el disco. Lo escrito en disco queda en contenido × 1.0 y el disco necesario en 1×, donde otros piden en torno a 2×.
  • Archivos anidados, y la profundidad casi no cuesta nada. Los archivos dentro de archivos - RAR en RAR, 7z dentro de un RAR, escaleras de muchos niveles - se desanidan según llegan los bytes, dentro de la pasada que ya estábamos haciendo. Ahí está toda la diferencia: un cliente que escribe cada capa en disco, la cierra, la vuelve a abrir y la relee paga una pasada completa por nivel, así que cada capa que baja le cuesta otro viaje de ida y vuelta al disco. Las nuestras viajan en la primera pasada, y la carga sale de una escalera de diez niveles igual que sale de una de un solo nivel. Una copia en disco donde escribir-y-releer guarda dos o tres.
  • Desofuscación. Las publicaciones ofuscadas se renombran a partir de sus metadatos PAR2, los nombres revueltos con ROT13 se rescatan y la basura con nombre de hash se clasifica y se descarta.
  • Reparación a medida. Los bloques dañados se conocen en el momento en que ocurren, así que solo se obtiene el conjunto de volúmenes de recuperación con el mínimo de bytes -resuelto como un problema de la mochila- y la reparación no toca más que los tramos dañados.
  • Registros de recuperación RAR. Cuando el PAR2 se agota, o nunca se publicó, los registros de recuperación incrustados en los RAR reparan los volúmenes dañados in situ.
  • Reparación a cualquier profundidad. Un conjunto PAR2 empaquetado dentro de una capa interna se encuentra y se ejecuta en su propio nivel, y una publicación de solo PAR (datos borrados, con un conjunto de recuperación al 100% dejado atrás) se reconstruye entera y luego se desempaqueta.
  • Respaldo para comprimidos y cifrados: las publicaciones que no van en modo almacenamiento se materializan y se desempaquetan con el motor RAR nativo, todo desde RAR4 hasta el nuevo RAR7, solapadas con el resto de la cola. Los conjuntos cifrados se aparcan con un mensaje claro en vez de fallar en silencio.
  • Va a buscar la contraseña por su cuenta. La mayoría de los posts cifrados no te necesitan. Prueba los metadatos del propio NZB y la convención de nombres {{pw}}, la API de los *arr, luego cualquier nota de texto corta publicada junto a los archivos y, a falta de eso, los nombres de la release y de los propios archivos. Repite esa búsqueda en cada nivel: una cadena que esconde la contraseña de cada capa dentro de la capa superior - una contraseña distinta en cada nivel - se abre hasta el fondo sin que escribas nada. Lo que de verdad queda pendiente pasa por el desbloqueo 🔑 del panel: desbloquea en segundo plano y luego archiva con normalidad.
  • Barandillas de seguridad. Los volúmenes fuente reparados quedan protegidos contra escritura mientras corre la reextracción, la propia suma de comprobación del archivo terminado se verifica de extremo a extremo (activado por defecto), y un código de salida informa de «éxito» solo cuando el estado final es de verdad usable.

Fiabilidad y disponibilidad

  • Comprobación previa de disponibilidad. Barridos STAT en pipeline construyen en segundos una matriz por artículo × por servidor y marcan el trabajo como COMPLETO, REPARABLE o IMPOSIBLE antes de descargar un solo byte de contenido. Una publicación imposible se aborta sin apenas haber bajado nada.
  • Enrutado por unión. Un artículo solo cuenta como ausente cuando todos los servidores activos lo han rechazado; hasta entonces se enruta al servidor que lo tenga. Los backbones difieren en retención y en retiradas, así que la unión completa sin ruido publicaciones que ningún servidor lograría por sí solo.
  • Diario a prueba de fallos. El diario trabaja con granularidad de artículo. Lanza un kill −9 a mitad de trabajo y vuelve, descargando de nuevo solo lo que no se había persistido; la cola y el historial sobreviven a los reinicios.
  • Aparcar y reintentar: los trabajos fallidos se aparcan en el historial, y un reintento baja solo las piezas que aún faltan.
  • Probado con caos. Un servidor NNTP simulado ejecuta diez escenarios de fallo de extremo a extremo -errores 430, corrupción, truncamiento, atascos, servidores caídos, kill −9- en cada una de las ejecuciones de tests.
  • Puntuación de fiabilidad por proveedor. Las tasas de compleción de cada servidor se guardan de por vida y se muestran en el panel, con un aviso por debajo del 98%.
  • Analizador de diversidad de servidores. Muestrea con STAT tus servidores y los agrupa por los huecos que comparten, para que veas cuáles de tus proveedores «distintos» son en realidad el mismo backbone antes de pagar por una redundancia que no tienes.
  • Cuotas, cuentas de bloque y guardián de disco: cuotas diarias y mensuales, presupuestos de bytes de por vida para las cuentas de bloque (se excluyen solas al agotarse), una pausa por poco disco e historial de uso diario por proveedor.
  • Detección de duplicados: dupekey y dupescore, con una alternativa retenida que se promociona automáticamente en cuanto una captura falla.
  • Enrutado consciente de la retención. Las publicaciones más antiguas que la retención de un servidor lo saltan por completo, y lo que ningún servidor puede servir falla al instante en lugar de dar vueltas.

Automatización e integraciones

  • API compatible con SABnzbd: toda la superficie que los *arr usan de verdad: addfile/addurl, categorías, prioridades, pausa/reanudación por trabajo, reintentos, paginación y claves API de dos niveles. Sonarr y Radarr le hablan como si fuera SABnzbd.
  • Fachada JSON-RPC de NZBGet. nzb360, LunaSea y otros mandos remotos de NZBGet se conectan sin cambios.
  • Servidor Newznab. Tu índice local responde a t=search/tvsearch/movie, así que los *arr pueden tratar tus propios escaneos como un indexador.
  • Captura automática por RSS: el feed de un indexador es lo mismo a lo que se suscribe un lector de noticias, solo que enumera lo que se acaba de publicar en Usenet. Todo lo que coincide con los filtros se descarga solo. Feeds filtrados con un lenguaje al estilo NZBGet, que se añaden y se editan en vivo desde el panel.
  • Lista de seguimiento. Nombra las series y películas que quieres, incluso las que aún no se han emitido. Cada episodio se captura en su primera aparición y se mejora hasta alcanzar tu calidad objetivo (por ejemplo, 720p → 1080p REMUX), y la copia sustituida se borra solo una vez verificada la mejora. Un calendario de emisiones muestra lo que está por llegar.
  • Carpeta vigilada. Suelta un .nzb y se descarga; el archivo desaparece en cuanto se ha recogido.
  • Carpetas inteligentes: reglas de regex, palabra clave y tamaño clasifican las descargas por categorías al encolarlas, con archivado de TV opcional a Show/Season NN/Show - S01E02.ext.
  • Reglas de limpieza: las extensiones basura se eliminan al completarse un trabajo.
  • Mover a un NAS: tras desempaquetar y renombrar, las descargas terminadas van a una carpeta de destino conservando la estructura de categorías, y los destinos por categoría pueden enviar series y películas a recursos distintos. Si el recurso no está accesible, los archivos se quedan donde están.
  • Scripts de posprocesado. Respetan el contrato de entorno SAB_* de SABnzbd, así que los scripts que ya tienes funcionan tal cual.
  • Migración en un clic. Importa servidores desde un ini de SABnzbd o un conf de NZBGet, y lee sabnzbd.ini directamente si es lo único que encuentra.
  • Ingesta de Spotnet: verificación de firmas de spots y síntesis de NZB, integradas de serie.

Vista previa y biblioteca

Panel y ajustes

Cola con un cajón de detalle por descarga: barras de progreso por archivo, bloques de verificación, contribución por servidor
Cajón de la cola: barras por archivo, bloques de verificación, contribución por servidor.
Ajustes: editor de servidores y controles en vivo de velocidad y programación
Cada ajuste se edita en el navegador. La mayoría se aplican en vivo.
Diseño del panel en el teléfono
Diseño para móvil como es debido, el mismo daemon.
  • Gráficos en vivo, sin librerías. Todo se sondea una vez por segundo -un área de rendimiento, un área apilada por proveedor, una línea temporal de salud de la verificación, el consumo restante de la cola, un histograma de velocidad- y los gráficos amplían su ventana temporal a medida que ensanchas el navegador.
  • Monitor de recursos: CPU, RAM frente al presupuesto, escrituras en disco y red en un solo gráfico, con aviso de poco espacio.
  • Clasificación de proveedores. Los servidores se reordenan solos según su rendimiento en vivo, y cada uno muestra los bytes de la sesión, el número de conexiones, la utilización y la fiabilidad.
  • Gestión de la cola: arrastra para reordenar, fija prioridad y categoría en línea, abre un cajón por descarga, pausa de forma optimista o «pausar durante N minutos».
  • Todo se configura en el navegador: servidores (con pruebas de conexión en vivo), velocidad y programación, conexiones/ventana/decodificadores, disco y cuota, carpetas vigiladas y scripts, filtros de indexación, biblioteca, RSS y seguridad con rotación de claves. Los ajustes sobreviven a los reinicios.
  • Diagnósticos integrados: un visor de registro en la propia interfaz, un benchmark del sistema que encuentra los techos de red, cálculo y disco y te dice qué hacer con ellos, el analizador de diversidad de servidores y la escalera de conexiones.
  • Uso de datos: barras apiladas por proveedor de 14 días, historial diario y contadores de por vida para las cuentas de bloque.
  • 28 idiomas. El panel llega totalmente traducido, escrituras de derecha a izquierda incluidas; el manual y este sitio están en 16.
  • Detalles que se agradecen. Arrastra y suelta un .nzb en cualquier parte, notificaciones de escritorio, sonidos de finalización, un asistente de primer arranque y serve --open.

Despliegue