Funktionen

Oben die Kurzfassung, darunter alle Details.

  • Pipelined NNTP auf Leitungstempo: 8,31 Gbps gemessen auf 10 GbE.
  • Ein-Pass-Pipeline: Dekodieren, Prüfen und Entpacken überlappen; RAR-Volumes berühren nie die Festplatte; verschachtelte Archive werden im selben Durchlauf entpackt.
  • Union-Verfügbarkeit über mehrere Provider: vervollständigt aus der Vereinigung deiner Server oder bricht früh ab.
  • Speicher-Budget: begrenzter RAM, sauberes Auslagern, niemals Swapping.
  • Absturzfestes Fortsetzen: Journal auf Artikelebene; kill −9 mitten im Job, und es macht genau da weiter, wo es aufgehört hat.
  • SABnzbd-kompatible + NZBGet-JSON-RPC-APIs: Sonarr/Radarr/nzb360/LunaSea laufen unverändert.
  • Eingebauter Indexer: scannt Newsgroups in einen lokalen, durchsuchbaren Index mit Newznab-Schnittstelle.
  • Posterwand: Artwork, Bewertungen, Besetzung, Episodenraster; keine API-Keys.
  • Watchlist-Auto-Grab + Qualitäts-Upgrades: holt beim ersten Auftauchen und rüstet bis zur Zielqualität auf.
  • Eine einzige, in sich geschlossene Programmdatei: par2 + RAR-Entpacken eingebettet.

Engine & Tempo

  • Pipelined NNTP. Mehrere gleichzeitig offene Anfragen pro Verbindung schlagen sowohl die Round-Trip-Latenz als auch den Verfall des TCP-Congestion-Windows. Wir messen irgendwo zwischen +12 % und +270 % gegenüber seriellem Abruf, und rund 8 Verbindungen pro Server genügen, um die Leitung auszulasten.
  • SIMD-yEnc-Dekodierung (rapidyenc, mit NEON- und AVX-Kerneln) läuft mit 4,95 GB/s pro Kern und dekodiert an Ort und Stelle, während die Bytes im Empfangspfad eintreffen.
  • Gemeinsame Warteschlange über alle Server. Ohne jedes Tuning gleichen sich die Provider bis auf etwa 2 % selbst aus. Die tatsächliche Rate jedes Servers wird mitverfolgt, und das Ende eines Jobs wird doppelt vergeben, damit ein einzelner langsamer Server das Finale nicht in die Länge zieht.
  • Job-übergreifendes Durchziehen. Das Ende von Job N überlappt den Start von Job N+1, sodass die Leitung über eine ganze Warteschlange hinweg von Kante zu Kante ausgelastet bleibt: hier 2 % Leerlauf gegenüber 61 % Dunkelzeit bei SABnzbd im selben Benchmark.
  • Watchdog für langsame Jobs. Kriecht ein Download auf einem einzigen langsamen Server dahin, während der Rest untätig wartet, wandert er ans Ende der Warteschlange (der Fortschritt bleibt erhalten) und läuft weiter, sobald die Warteschlange frei ist.
  • Prefetch auf freien Servern: ein Server, den der aktive Job nicht nutzen kann, weil seine Artikel dort nicht liegen, beginnt stattdessen mit dem nächsten Job in der Warteschlange, statt untätig zu bleiben.
  • Verbindungs-Tuning-Leiter. Statt zu raten, misst sie, wo der Durchsatz jedes Providers wirklich aufhört zu steigen (angefragte gegenüber gewährten Verbindungen) und pendelt sich dort ein.
  • Auto-Tempo-Regler: ein optionaler RTT-Regler nach LEDBAT-Art, der dem übrigen Verkehr in deinem Haushalt den Vortritt lässt und sich mit dem nimmt, was von der Leitung übrig ist.
  • Tempolimits und ein Wochenplan: live verstellbare Obergrenzen, ein Zeitplan in lokaler Zeit (sommerzeitfest) und ein „Pause für N Minuten“, das von selbst wieder anläuft.
  • Speicher-Budget. Ein einziges globales RAM-Budget (automatisch ein Viertel des RAM, gedeckelt, übersteuerbar). Wird es knapp, schrumpfen zuerst die Puffer, dann wandern Daten auf die Platte und werden zurückgelesen, sobald der Job zur Ruhe kommt. Geswappt wird nie. Ein 190-GB-Job läuft in einem 1-GB-Budget bei ~1,1 GB Spitzen-RSS durch, und für NAS-Geräte gibt es ein vermessenes, dokumentiertes 2-GB-Profil.
  • Gegendruck. Eine langsame Festplatte drosselt die Sockets, statt den RAM volllaufen zu lassen. Sie hält ein Schreiblimit auf ±1 % genau ein, und der RAM sinkt unter Druck sogar.
  • Speicher-Rückgabe nach dem Job: sobald er im Leerlauf ist, gibt der Daemon freigewordenen Speicher ans Betriebssystem zurück und fällt zwischen Jobs unter macOS auf rund 8 MB.

Die Ein-Pass-Pipeline

  • Einmal schreiben. Dekodierte Artikel werden per pwrite direkt an ihre endgültigen Datei-Offsets geschrieben. Keine Temp-Dateien, kein separater Zusammensetz-Durchlauf.
  • PAR2-Prüfung im Datenstrom. Jeder Block wird beim Eintreffen aus den Decode-Puffern MD5-gehasht, sodass die Verifikation genau dann fertig ist, wenn der Download es ist. Das schlägt den Quick-Check, mit dem sich die anderen Clients begnügen, und kostet nichts.
  • Direktes Entpacken: RAR-Posts im Store-Modus (die meisten Scene-Releases) werden schon während des Downloads gemappt und entpackt, sodass die Volumes gar nicht erst auf der Festplatte landen. Die Schreiblast beträgt Inhalt × 1,0 und der Plattenbedarf 1×, wo andere rund 2× verlangen.
  • Verschachtelte Archive, und Tiefe kostet fast nichts. Archive in Archiven - RAR im RAR, 7z im RAR, viele Ebenen tiefe Leitern - werden entschachtelt, während die Bytes ankommen, innerhalb des Durchlaufs, den wir ohnehin machen. Genau darin liegt der Unterschied: Ein Client, der jede Ebene herausschreibt, schließt, wieder öffnet und erneut liest, zahlt pro Ebene einen vollen Durchlauf, jede weitere Ebene kostet ihn also noch einen Umweg über die Platte. Unsere fahren im ersten Durchlauf mit, und die Nutzlast kommt aus einer zehnstufigen Leiter genauso heraus wie aus einer einstufigen. Eine Kopie auf der Platte, wo Herausschreiben-und-neu-Lesen zwei oder drei hält.
  • Deobfuskierung. Verschleierte Posts werden anhand ihrer PAR2-Metadaten umbenannt, ROT13-verwürfelte Namen gerettet und hash-benannter Müll erkannt und aussortiert.
  • Passgenaue Reparatur. Beschädigte Blöcke sind bekannt, sobald sie auftreten, sodass nur die byteminimale Menge an Recovery-Volumes geholt wird (ein Knapsack-Problem) und die Reparatur nichts als die beschädigten Bereiche anfasst.
  • RAR-Recovery-Records. Wenn das PAR2 aufgebraucht ist, oder nie gepostet wurde, reparieren die in den RARs eingebetteten Recovery-Records beschädigte Volumes an Ort und Stelle.
  • Reparatur auf jeder Ebene. Ein PAR2-Set, das in einer inneren Schicht steckt, wird gefunden und auf seiner eigenen Ebene ausgeführt, und ein Nur-PAR-Post (Daten gelöscht, nur ein Recovery-Set mit 100 % Deckung zurückgelassen) wird erst komplett rekonstruiert und dann entpackt.
  • Fallback für Komprimiertes und Verschlüsseltes: Nicht-Store-Posts landen auf der Platte und werden über die native RAR-Engine entpackt, alles von RAR4 bis zum neuen RAR7, überlappt mit dem Rest der Warteschlange. Verschlüsselte Sets parken mit einer klaren Meldung, statt still zu scheitern.
  • Es sucht das Passwort selbst. Die meisten verschlüsselten Posts brauchen dich gar nicht. Es probiert die NZB-Metadaten und die {{pw}}-Namenskonvention, die *arr-API, dann jede kurze Textnotiz, die neben den Dateien liegt, und zuletzt die Namen der Release und der Dateien selbst. Diese Suche wiederholt es auf jeder Ebene: Eine Kette, die das Passwort jeder Schicht in der Schicht darüber versteckt - ein anderes Passwort pro Ebene - schließt sich bis ganz nach unten auf, ohne dass du etwas tippst. Was wirklich übrig bleibt, bekommt das 🔑-Entsperren im Dashboard: Es entsperrt im Hintergrund und legt dann normal ab.
  • Sicherheitsgurte. Reparierte Quell-Volumes sind schreibgeschützt, solange das erneute Entpacken läuft, die eigene Prüfsumme der fertigen Datei wird Ende-zu-Ende verifiziert (standardmäßig aktiv), und ein Exit-Code meldet nur dann „Erfolg“, wenn das Endergebnis wirklich benutzbar ist.

Zuverlässigkeit & Verfügbarkeit

  • Verfügbarkeits-Check vor dem Start. Pipelinete STAT-Sweeps bauen in Sekunden eine Matrix aus Artikel × Server auf und markieren den Job als VOLLSTÄNDIG, REPARIERBAR oder UNMÖGLICH, bevor auch nur ein Byte Inhalt geladen ist. Ein unmöglicher Post bricht ab, ohne fast etwas gezogen zu haben.
  • Union-Routing. Ein Artikel gilt erst dann als fehlend, wenn ihn jeder aktive Server verweigert hat; bis dahin wird er zu dem Server geleitet, der ihn vorhält. Backbones unterscheiden sich in Retention und Takedowns, und so vervollständigt die Vereinigung klammheimlich Posts, die kein einzelner Server schaffen würde.
  • Absturzfestes Journal. Das Journal arbeitet auf Artikelebene. Schick mitten im Job ein kill −9, und es kommt zurück und lädt nur nach, was noch nicht gesichert war; Warteschlange und Verlauf überstehen Neustarts.
  • Parken und erneut versuchen: fehlgeschlagene Jobs parken im Verlauf, und ein erneuter Versuch holt nur die Teile, die noch fehlen.
  • Chaos-getestet. Ein Mock-NNTP-Server fährt bei jedem einzelnen Testlauf zehn End-to-End-Fehlerszenarien durch: 430er, Korruption, Abschneiden, Hänger, tote Server, kill −9.
  • Provider-Zuverlässigkeitswertung. Die Vollständigkeitsraten pro Server werden dauerhaft festgehalten und im Dashboard angezeigt, mit einer Warnung unterhalb von 98 %.
  • Server-Diversitäts-Analyse. Sie zieht STAT-Stichproben über deine Server und gruppiert sie nach den Lücken, die sie teilen, so erkennst du, welche „unterschiedlichen“ Provider in Wahrheit dasselbe Backbone sind, bevor du für Redundanz zahlst, die du gar nicht hast.
  • Quotas, Block-Konten und ein Platten-Wächter: Tages- und Monats-Quotas, Lebenszeit-Byte-Budgets für Block-Konten (automatisch ausgenommen, sobald aufgebraucht), eine Pause bei wenig Plattenplatz und eine tägliche Verbrauchshistorie pro Provider.
  • Duplikat-Erkennung: Dupekey und Dupescore, wobei eine zurückgehaltene Alternative automatisch nachrückt, sobald ein Grab fehlschlägt.
  • Retention-bewusstes Routing. Posts, die älter sind als die Retention eines Servers, überspringen ihn ganz, und was kein Server ausliefern kann, scheitert sofort, statt sich im Kreis zu drehen.

Automatisierung & Integrationen

  • SABnzbd-kompatible API: die ganze Oberfläche, die die *arrs tatsächlich nutzen: addfile/addurl, Kategorien, Prioritäten, Pause/Fortsetzen pro Job, erneut versuchen, Paginierung, zweistufige API-Keys. Sonarr und Radarr sprechen mit ihr, als wäre sie SABnzbd.
  • NZBGet-JSON-RPC-Fassade. nzb360, LunaSea und andere NZBGet-Fernsteuerungen verbinden sich unverändert.
  • Newznab-Server. Dein lokaler Index beantwortet t=search/tvsearch/movie, sodass die *arrs deine eigenen Scans wie einen Indexer behandeln können.
  • RSS-Auto-Grab: Der Feed eines Indexers ist dasselbe, was ein News-Reader abonniert, nur listet er auf, was gerade im Usenet gepostet wurde. Alles, was auf die Filter passt, lädt sich von selbst herunter. Feeds, gefiltert mit einer Sprache im NZBGet-Stil, live im Dashboard hinzugefügt und bearbeitet.
  • Watchlist. Nenn die Serien und Filme, die du willst, auch solche, die noch nicht ausgestrahlt sind. Jede Episode wird bei ihrem ersten Auftauchen geholt und aufgerüstet, bis sie deine Zielqualität erreicht (etwa 720p → 1080p REMUX), wobei die überholte Kopie erst gelöscht wird, nachdem das Upgrade verifiziert wurde. Ein Ausstrahlungskalender zeigt, was kommt.
  • Watch-Ordner. Leg eine .nzb hinein, und sie wird geladen; die Datei verschwindet, sobald sie übernommen wurde.
  • Smarte Ordner: Regex-, Stichwort- und Größenregeln sortieren Downloads schon beim Einreihen in Kategorien, mit optionaler TV-Ablage nach Show/Season NN/Show - S01E02.ext.
  • Aufräumregeln: Müll-Endungen werden entfernt, sobald ein Job abgeschlossen ist.
  • Verschieben auf ein NAS: fertige Downloads wandern nach dem Entpacken und Umbenennen in einen Zielordner, das Kategorie-Layout bleibt erhalten, und Ziele je Kategorie können Serien und Filme auf verschiedene Shares schicken. Ist das Share nicht erreichbar, bleiben die Dateien, wo sie sind.
  • Nachbearbeitungs-Skripte. Sie halten sich an SABnzbds SAB_*-Umgebungsvertrag, sodass die Skripte, die du schon hast, unverändert laufen.
  • Ein-Klick-Migration. Sie importiert Server aus einer SABnzbd-ini oder einer NZBGet-conf und liest sabnzbd.ini direkt, wenn nur das zu finden ist.
  • Spotnet-Ingestion: Spot-Signaturprüfung und NZB-Synthese, direkt eingebaut.

Vorschau & Bibliothek

Dashboard & Einstellungen

Queue with a per-download detail drawer: per-file progress bars, verify blocks, per-server contribution
Warteschlangen-Drawer: Balken pro Datei, Prüf-Blöcke, Beitrag pro Server.
Settings: server editor and live speed/scheduling controls
Jede Einstellung im Browser editierbar. Die meisten gelten sofort.
Phone layout of the dashboard
Richtiges Handy-Layout, derselbe Daemon.
  • Live-Diagramme, ohne Libraries. Alles pollt einmal pro Sekunde (eine Durchsatz-Fläche, eine gestapelte Fläche pro Provider, eine Prüfstatus-Zeitleiste, ein Warteschlangen-Burn-down, ein Tempo-Histogramm) und die Diagramme weiten ihr Zeitfenster, sobald du das Browserfenster breiter ziehst.
  • Ressourcen-Monitor: CPU, RAM gegen das Budget, Schreibvorgänge und Netzwerk in einem einzigen Diagramm, mit einer Warnung bei wenig Plattenplatz.
  • Provider-Rangliste. Die Server sortieren sich nach Live-Leistung selbst um und zeigen jeweils Sitzungs-Bytes, Verbindungszahl, Auslastung und Zuverlässigkeit.
  • Warteschlangen-Verwaltung: zum Umsortieren ziehen, Priorität und Kategorie inline setzen, einen Drawer pro Download öffnen, optimistisch pausieren oder „Pause für N Minuten“.
  • Alles im Browser konfigurierbar: Server (mit Live-Verbindungstests), Tempo und Zeitplan, Verbindungen/Fenster/Decoder, Platte und Quota, Watch-Ordner und Skripte, Ingest-Filter, Bibliothek, RSS und Sicherheit mit Key-Rotation. Die Einstellungen überstehen Neustarts.
  • Diagnose eingebaut: ein Log-Viewer direkt in der UI, ein System-Benchmark, der deine Netzwerk-, Rechen- und Platten-Obergrenzen findet und dir sagt, was dagegen zu tun ist, die Server-Diversitäts-Analyse und die Verbindungs-Leiter.
  • Datenverbrauch: gestapelte Balken pro Provider über 14 Tage, Tageshistorie und Lebenszeit-Zähler für Block-Konten.
  • 28 Sprachen. Das Dashboard kommt vollständig übersetzt, Rechts-nach-links-Schriften eingeschlossen; das Handbuch und diese Seite gibt es in 16.
  • Komfort. Eine .nzb einfach irgendwohin ziehen, Desktop-Benachrichtigungen, Abschluss-Sounds, ein Erststart-Assistent und serve --open.

Deployment