Funzionalità

La versione breve in alto, tutti i dettagli sotto.

  • NNTP in pipeline a velocità di linea: 8.31 Gbps misurati su 10 GbE.
  • Pipeline a passata unica: decodifica, verifica ed estrazione si sovrappongono; i volumi RAR non toccano mai il disco; gli archivi annidati si estraggono nella stessa passata.
  • Disponibilità in unione multi-provider: completa dall'unione dei tuoi server, o interrompe subito.
  • Budget di memoria: RAM limitata, spill controllato, mai swap.
  • Ripresa a prova di crash: journal a livello di articolo; kill −9 a metà job e riprende da dove si era fermato.
  • API compatibile SABnzbd + JSON-RPC NZBGet: Sonarr/Radarr/nzb360/LunaSea funzionano senza modifiche.
  • Indexer integrato: scansiona i gruppi in un indice locale, ricercabile, servito via Newznab.
  • Bacheca dei poster: copertine, valutazioni, cast, griglie episodi; nessuna chiave API.
  • Prelievo automatico da watchlist + upgrade di qualità: preleva alla prima apparizione, migliora fino alla qualità obiettivo.
  • Un unico eseguibile autonomo: par2 + estrazione RAR integrati.

Motore & velocità

  • NNTP in pipeline. Tenere più richieste in volo su ogni connessione batte sia la latenza di andata e ritorno sia il decadimento della finestra di congestione TCP. Misuriamo tra +12% e +270% rispetto al recupero seriale, e per saturare la linea bastano circa 8 connessioni per server.
  • Decodifica yEnc SIMD (rapidyenc, con kernel NEON e AVX) a 4.95 GB/s per core, decodificata sul posto man mano che i byte arrivano nel percorso di ricezione.
  • Coda condivisa multi-server. Senza alcun tuning i provider si bilanciano da soli entro il ~2%. La velocità reale di ciascuno viene tracciata, e la coda finale di un job viene inviata in doppio, così un singolo server lento non può trascinare il traguardo.
  • Saturazione tra job. La coda del job N si sovrappone all'avvio del job N+1: la linea resta accesa da un capo all'altro dell'intera coda: qui 2% di inattività contro il 61% al buio di SABnzbd nello stesso benchmark.
  • Watchdog dei job lenti. Un download che arranca su un unico server lento mentre gli altri restano fermi viene spostato in fondo alla coda, con l'avanzamento conservato, e riprende quando la coda si svuota.
  • Prefetch sui server inattivi: un server che il job attivo non può usare, perché non custodisce i suoi articoli, comincia il prossimo job in coda invece di restare fermo.
  • Ottimizzazione connessioni a gradini. Invece di tirare a indovinare, misura dove il throughput di ogni provider smette davvero di crescere (connessioni richieste contro concesse) e si assesta lì.
  • Regolatore automatico di velocità: un governatore RTT opzionale in stile LEDBAT, che cede il passo al resto del traffico di casa e si prende ciò che resta della linea.
  • Limiti di velocità e pianificazione settimanale. Tetti regolabili al volo, orari in ora locale (a prova di ora legale) e una «pausa per N minuti» che riprende da sola.
  • Budget di memoria. Un unico budget globale di RAM (automatico: un quarto della RAM, con tetto, sovrascrivibile). Quando si stringe, prima si riducono i buffer, poi i dati fanno spill su disco e vengono riletti una volta che il job si assesta. Non va mai in swap. Un job da 190 GB si chiude dentro un budget di 1 GB a ~1.1 GB di picco RSS, e per i NAS c'è un profilo da 2 GB misurato e documentato.
  • Backpressure. Un disco lento frena i socket invece di lasciar riempire la RAM: resta entro ±1% da un tetto di scrittura, e sotto pressione la RAM addirittura scende.
  • Rilascio della memoria a fine job: appena inattivo, il daemon restituisce al sistema la memoria liberata, scendendo a circa 8 MB tra un job e l'altro su macOS.

La pipeline a passata unica

  • Scrittura unica. Gli articoli decodificati vengono scritti (pwrite) direttamente al loro offset finale nel file. Niente file temporanei, nessuna passata di assemblaggio a parte.
  • Verifica PAR2 nel flusso. Ogni blocco riceve l'hash MD5 dai buffer di decodifica appena arriva, così la verifica finisce nell'istante stesso in cui finisce il download. Batte il quick-check di cui si accontentano gli altri client, e non costa nulla.
  • Estrazione diretta: i post RAR in modalità store (la maggior parte delle release scene) vengono mappati ed estratti mentre scaricano, così i volumi non finiscono mai su disco. Le scritture su disco si fermano a contenuto × 1.0 e lo spazio richiesto a 1×, dove agli altri serve grosso modo 2×.
  • Archivi annidati, e la profondità non costa quasi nulla. Gli archivi dentro archivi - RAR dentro RAR, 7z dentro un RAR, scale profonde molti livelli - vengono disannidati mentre i byte arrivano, dentro la passata che stavamo già facendo. La differenza è tutta qui: un client che scrive ogni livello su disco, lo chiude, lo riapre e lo rilegge paga una passata intera per livello, quindi ogni livello in più gli costa un altro giro sul disco. I nostri viaggiano nella prima passata, e il payload esce da una scala di dieci livelli come esce da una di uno. Una copia su disco dove scrivi-e-rileggi ne tiene due o tre.
  • Deoffuscamento. I post offuscati vengono rinominati dai loro metadati PAR2, i nomi mescolati in ROT13 vengono recuperati, e la robaccia dai nomi hash viene classificata e tenuta fuori.
  • Riparazione su misura. I blocchi danneggiati si conoscono appena si presentano, così viene scaricato solo l'insieme di volumi di recupero dal minor numero di byte (un problema dello zaino) e la riparazione tocca soltanto gli intervalli danneggiati.
  • Record di recupero RAR. Quando il PAR2 è esaurito, o non è mai stato postato, i record di recupero incorporati nei RAR riparano i volumi danneggiati sul posto.
  • Riparazione a ogni profondità. Un set PAR2 impacchettato dentro uno strato interno viene trovato ed eseguito al proprio livello, e un post di soli PAR (dati cancellati, lasciato solo un set di recupero al 100%) viene ricostruito per intero e poi estratto.
  • Fallback per compressi e cifrati: i post non-store si materializzano e si estraggono con il motore RAR nativo, tutto dal RAR4 al nuovo RAR7, in sovrapposizione con il resto della coda. I set cifrati si parcheggiano con un messaggio chiaro invece di fallire in silenzio.
  • Va a cercarsi la password da solo. La maggior parte dei post cifrati non ha bisogno di te. Prova i metadati dell’NZB e la convenzione di nome {{pw}}, l’API degli *arr, poi qualsiasi breve nota di testo pubblicata accanto ai file e, in mancanza d’altro, i nomi della release e dei file stessi. Ripete quella ricerca a ogni livello: una catena che nasconde la password di ciascuno strato dentro lo strato superiore - una password diversa a ogni livello - si sblocca fino in fondo senza che tu digiti nulla. Quel che resta davvero passa dallo sblocco 🔑 sulla dashboard: sblocca in background, poi archivia normalmente.
  • Reti di sicurezza. I volumi sorgente riparati sono protetti da scrittura mentre gira la ri-estrazione, il checksum proprio del file finito viene verificato da capo a fondo (attivo per impostazione predefinita), e un codice di uscita segnala «successo» solo quando lo stato finale è davvero utilizzabile.

Affidabilità & disponibilità

  • Controllo di disponibilità preliminare. Scansioni STAT in pipeline costruiscono in pochi secondi una matrice articolo × server e marcano il job COMPLETO, RIPARABILE o IMPOSSIBILE prima di scaricare un solo byte di contenuto. Un post impossibile si interrompe avendo tirato giù quasi nulla.
  • Instradamento in unione. Un articolo conta come mancante solo quando ogni server attivo lo ha rifiutato; fino a quel momento va al server che ce l'ha. I backbone differiscono per retention e takedown, così l'unione completa in sordina i post che nessun singolo server potrebbe portare a termine.
  • Journal a prova di crash. Il journal lavora alla granularità del singolo articolo. Dài un kill −9 a metà job e torna su, riscaricando solo ciò che non era stato reso persistente; coda e storico sopravvivono ai riavvii.
  • Parcheggia e riprova: i job falliti si parcheggiano nello storico, e una riprova recupera soltanto i pezzi ancora mancanti.
  • Collaudato al caos. Un server NNTP simulato mette in scena dieci scenari di guasto end-to-end (errori 430, corruzione, troncamenti, stalli, server morti, kill −9) a ogni singola esecuzione dei test.
  • Punteggio di affidabilità dei provider. I tassi di completamento per server vengono conservati a lungo e mostrati nella dashboard, con un avviso sotto il 98%.
  • Analisi della diversità dei server. Campiona con STAT tutti i tuoi server e li raggruppa in base alle lacune che condividono, così capisci quali provider «diversi» sono in realtà lo stesso backbone prima di pagare per una ridondanza che non hai davvero.
  • Quote, account a blocchi e guardia del disco: quote giornaliere e mensili, budget di byte a vita per gli account a blocchi (esclusi in automatico una volta esauriti), una pausa a spazio scarso e lo storico d'uso giornaliero per provider.
  • Rilevamento dei duplicati: dupekey e dupescore, con un'alternativa tenuta da parte che viene promossa in automatico nell'istante in cui un prelievo fallisce.
  • Instradamento consapevole della retention. I post più vecchi della retention di un server lo saltano del tutto, e ciò che nessun server può servire fallisce subito invece di girare a vuoto.

Automazione & integrazioni

  • API compatibile SABnzbd: tutta la superficie che gli *arr usano davvero: addfile/addurl, categorie, priorità, pausa/ripresa per job, riprova, paginazione, chiavi API a due livelli. Sonarr e Radarr le parlano come se fosse SABnzbd.
  • Facciata JSON-RPC NZBGet. nzb360, LunaSea e gli altri telecomandi NZBGet si collegano senza modifiche.
  • Server Newznab. Il tuo indice locale risponde a t=search/tvsearch/movie, così gli *arr possono trattare le tue scansioni come un indexer.
  • Prelievo automatico da RSS: il feed di un indicizzatore è la stessa cosa a cui si abbona un lettore di notizie, solo che elenca ciò che è appena stato pubblicato su Usenet. Tutto ciò che corrisponde ai filtri si scarica da solo. Feed filtrati con un linguaggio in stile NZBGet, aggiunti e modificati al volo dalla dashboard.
  • Watchlist. Elenca le serie e i film che vuoi, anche quelli non ancora in onda. Ogni episodio viene prelevato alla prima apparizione e migliorato finché non raggiunge la qualità obiettivo (per esempio, 720p → 1080p REMUX), con la copia superata cancellata solo dopo che l'upgrade è stato verificato. Un calendario delle uscite mostra cosa sta per arrivare.
  • Cartella monitorata. Lasciaci un .nzb e viene scaricato; il file sparisce una volta preso in carico.
  • Cartelle smart: regole di regex, parole chiave e dimensione smistano i download nelle categorie al momento dell'accodamento, con archiviazione TV opzionale in Show/Season NN/Show - S01E02.ext.
  • Regole di pulizia: le estensioni spazzatura vengono rimosse quando un job si completa.
  • Spostamento su NAS: dopo estrazione e rinomina i download completati vanno in una cartella di destinazione mantenendo la struttura delle categorie, e le destinazioni per categoria possono mandare serie e film su condivisioni diverse. Se la condivisione non è raggiungibile, i file restano dove sono.
  • Script di post-elaborazione. Rispettano il contratto d'ambiente SAB_* di SABnzbd, così gli script che hai già girano così come sono.
  • Migrazione in un clic. Importa i server da un ini di SABnzbd o da un conf di NZBGet, e legge direttamente sabnzbd.ini se è tutto ciò che riesce a trovare.
  • Ingestione Spotnet: verifica delle firme degli spot e sintesi degli NZB, integrate di serie.

Anteprima & libreria

Dashboard & impostazioni

Queue with a per-download detail drawer: per-file progress bars, verify blocks, per-server contribution
Cassetto della coda: barre per file, blocchi di verifica, contributo per server.
Settings: server editor and live speed/scheduling controls
Ogni impostazione modificabile nel browser. La maggior parte si applica al volo.
Phone layout of the dashboard
Un vero layout per telefono, stesso daemon.
  • Grafici live, zero librerie. Tutto si aggiorna una volta al secondo (un'area del throughput, un'area impilata per provider, una timeline della salute delle verifiche, il burn-down della coda, un istogramma delle velocità) e i grafici allargano la finestra temporale man mano che allarghi il browser.
  • Monitor delle risorse: CPU, RAM rispetto al budget, scritture su disco e rete in un unico grafico, con un avviso di spazio scarso.
  • Classifica dei provider. I server si riordinano da soli in base alle prestazioni dal vivo, ciascuno con i byte di sessione, il numero di connessioni, l'utilizzo e l'affidabilità.
  • Gestione della coda: trascina per riordinare, imposta priorità e categoria inline, apri un cassetto per singolo download, metti in pausa in modo ottimistico oppure «pausa per N minuti».
  • Tutto configurabile dal browser: i server (con test di connessione dal vivo), velocità e pianificazione, connessioni/finestra/decoder, disco e quota, cartelle monitorate e script, filtri di indicizzazione, libreria, RSS e sicurezza con rotazione delle chiavi. Le impostazioni sopravvivono ai riavvii.
  • Diagnostica integrata: un visore dei log dentro l'interfaccia, un benchmark di sistema che individua i tetti di rete, calcolo e disco e ti dice come intervenire, l'analisi della diversità dei server e la scala delle connessioni.
  • Utilizzo dati: barre impilate per provider su 14 giorni, storico giornaliero e contatori a vita per gli account a blocchi.
  • 28 lingue. La dashboard arriva completamente localizzata, scritture da destra a sinistra comprese; il manuale e questo sito sono in 16.
  • Qualità della vita. Trascina un .nzb ovunque, notifiche desktop, suoni di completamento, una procedura guidata al primo avvio e serve --open.

Distribuzione