Dall'NZB a un file verificato
prima che gli altri finiscano di scaricare.

nzbfast è un downloader Usenet costruito attorno a un'unica passata: ogni byte viene decodificato, verificato ed estratto mentre scarica. Dopo non resta nessuna passata di assemblaggio, niente da verificare o da estrarre una volta finito. Nell'istante in cui la barra di avanzamento si riempie, il file è pronto e dimostrabilmente integro.

9.0-9.3 Gbps su una linea 10 GbE 190 GB → 4m47s per un file verificato I volumi RAR non toccano mai il disco Metà del disco che serve ai concorrenti Budget di RAM · 0 swap, mai
Scarica Guarda i numeri

macOS · Windows · Linux · Docker: un unico eseguibile autonomo, strumenti di riparazione ed estrazione integrati.

nzbfast dashboard mid-download at 61 MB/s: throughput peaking at 104 MB/s across a full history graph, live resource and per-provider charts, and the download/verify/extract pipeline stages overlapping

Perché è veloce

Circa il 95% dei download usenet in una sola passata

Abbiamo misurato cosa viene davvero pubblicato su usenet prima di decidere cosa ottimizzare, e un'idea da sola fa quasi tutto il lavoro. Tutto è misurato nel log dei benchmark con comandi riproducibili.

🚿

Una passata, quasi ogni forma

Gli articoli vengono decodificati SIMD sul posto, scritti una sola volta ai loro offset finali e verificati PAR2 dagli stessi buffer. L'archivio viene estratto durante il download, così i suoi volumi non esistono mai come file. Vale per gli archivi semplici, cifrati, annidati e 7z, cioè circa il 95% di tutto ciò che viene pubblicato, in volume. Anche gli archivi davvero compressi vengono estratti mentre arrivano, e ricorrono a una seconda passata solo quando il set è troppo grande per stare in memoria durante la decompressione.

🕸️

Disponibilità in unione

Un articolo è «mancante» solo quando ogni backbone configurato lo ha rifiutato. Una contabilità esatta al blocco decide COMPLETO / RIPARABILE / IMPOSSIBILE prima di sprecare byte, recupera il minimo su misura di blocchi di recupero e interrompe in pochi secondi i download senza speranza.

🔁

NNTP in pipeline, fatto bene

Tenere più richieste in volo per connessione non è un'idea nostra, e i client migliori lo fanno. Il nostro è insolitamente efficiente: su quattro siti abbiamo misurato da +12% a +270% rispetto al seriale, e una linea satura con 8 connessioni invece di 30–50, così hai la piena velocità senza martellare il tuo provider. SABnzbd lo distribuisce ancora disattivato.

La pipeline

Tocca ogni byte una volta sola

I concorrenti scrivono i volumi dell'archivio, li rileggono per verificarli, li rileggono di nuovo per estrarli, poi scrivono l'output, grosso modo 2× scritture e 2× letture. nzbfast fa invece così:

socket ──TLS──▶ decodifica SIMD rapidyenc (sul posto - 4.95 GB/s per core)
                   │
                   ├─▶ pwrite all'offset finale          (post semplici)
                   │      └─ oppure: traduzione RAR-map ─▶ (sblocco, se cifrato) ─▶
                   │         pwrite dritto nel file estratto
                   │         (i volumi rar non toccano mai il disco - archivi
                   │         semplici, cifrati e annidati allo stesso modo)
                   ├─▶ hasher a blocchi PAR2 - ogni blocco verificato in MD5 dal
                   │      buffer di decodifica; la verifica finisce col download
                   └─▶ registro di disponibilità - salute esatta al blocco, in tempo reale
Post danneggiato? I blocchi difettosi sono noti nell'istante in cui i loro articoli falliscono, il minimo su misura di volumi di recupero viene scaricato durante il download (22 blocchi scaricati per 20 necessari, nel giro di bench), e la riparazione tocca solo gli intervalli danneggiati. Post impossibile? Si interrompe in pochi secondi avendo scaricato quasi nulla, prima che la tua quota se ne accorga.

Funzionalità di punta

Tutto ciò che serve a una configurazione seria

L'elenco completo (ogni regolazione, ogni integrazione) è nella pagina delle funzionalità.

  • Download a velocità di linea: NNTP in pipeline misurato a 9.0-9.3 Gbps su una linea 10 GbE il cui tetto è di 9.8; il client più veloce in ogni prova di benchmark pulita, a ogni dimensione.
  • Pipeline a passata unica: decodifica, verifica ed estrazione si sovrappongono; i volumi dell'archivio non toccano mai il disco, che il post sia semplice, cifrato o annidato; serve 1× di disco dove agli altri serve ~2×. Su una release cifrata da 94 GB sono 90 GB scritti invece di 180 GB.
  • Disponibilità in unione multi-provider: instradamento esatto al blocco tra i backbone; verdetti preliminari; riparazione su misura; interruzione precoce dei post impossibili.
  • Budget di memoria: un unico budget globale di RAM con livelli di spill gestiti con grazia. Non manda mai in swap la tua macchina: un job da 190 GB si completa dentro un budget di 1 GB (~1.1 GB di picco RSS).
  • Ripresa a prova di crash: un journal a livello di articolo fa sì che un crash o un kill −9 a metà download costi quasi nulla: riprende, riscaricando solo quanto non era stato salvato.
  • API drop-in: API compatibile SABnzbd e JSON-RPC NZBGet: Sonarr, Radarr, nzb360 e LunaSea funzionano senza modifiche. Importazione in un clic della tua configurazione SAB/NZBGet.
  • Link nzblnk:, risolti: incollane uno sulla dashboard, oppure cliccane uno direttamente su un board una volta che l'installazione macOS o Windows ha registrato lo schema. Il post offuscato viene cercato prima nel tuo indice, poi presso i tuoi indicizzatori, e la password del link va al lavoro.
  • Indexer integrato: scansiona i tuoi newsgroup in un indice locale ricercabile, e serve Newznab così anche il tuo stack *arr può cercarlo.
  • Bacheca dei poster con metadati senza chiave: copertine, valutazioni, cast e trame per tutto ciò che è nel tuo indice, senza nessuna chiave API da richiedere.
  • Automazione della watchlist: indica una serie o un film (già uscito o no); viene prelevato appena compare, poi migliorato di qualità fino a raggiungere il tuo obiettivo.
  • Un unico eseguibile: riparazione (par2) ed estrazione (RAR) viaggiano dentro il binario. Estrai, avvia, fatto, e entrambi eguagliano o battono gli strumenti autonomi quando corrono da soli.

Benchmark

190.6 GB → un file verificato da 167.9 GB

Stessa macchina, stessi sei provider, esecuzioni alternate una dopo l'altra. Tempo fino a quando esiste un file utilizzabile ed estratto, l'unica metrica che conta. Ogni concorrente ottimizzato al suo meglio documentato (incluso l'attivare il pipelining di SABnzbd, che di serie ne è privo).

nzbfast4m 47s
NZBGet 26.29m 06s · +90%
SABnzbd 5.0.419m 29s · +307%
rustnzb 1.3.4nessun file utilizzabile

NZB da 190.6 GB → singolo mkv da 167.9 GB, M1 Ultra su 10 GbE, 6 provider × 8 connessioni. Lo stesso job si completa dentro un budget di memoria di 1 GB. Tabelle complete, tutti e sette gli scenari e le prove che non vinciamo (più come riprodurle) nella pagina dei benchmark.

Si integra nel tuo stack

Puntaci i tuoi strumenti esistenti

Sonarr / Radarr

API completa compatibile SABnzbd. Aggiungi nzbfast come client di download «SABnzbd» e funziona e basta: prelievi, categorie, priorità, tentativi, script di post-elaborazione (contratto SAB_*), storico. La facciata Newznab permette inoltre agli *arr di cercare nel tuo indice locale come se fosse un indexer.

Step-by-step setup →

nzb360 / LunaSea

Il daemon parla anche il JSON-RPC di NZBGet. I telecomandi per telefono più diffusi pilotano nzbfast senza modifiche. E la dashboard stessa ha un layout per telefono di prima classe per quando sei lontano dallo schermo grande. (nzb360: SABnzbd API.)

Arrivi da SAB o NZBGet?

Un clic importa i tuoi server da un'installazione SABnzbd o NZBGet esistente (legge anche sabnzbd.ini direttamente). Cartelle monitorate, feed RSS con filtri, cartelle smart con archiviazione TV e regole di pulizia vengono al seguito.

Provalo nei prossimi due minuti

Estrai, doppio clic sul launcher, rispondi a tre domande (o lascia che trovi la tua configurazione SABnzbd), e la dashboard si apre. Primo download entro due minuti.