Funktionen

Oben die Kurzfassung, darunter alle Details.

  • Pipelined NNTP auf Leitungstempo: 9,0-9,3 Gbps gemessen auf einer 10-GbE-Leitung, deren eigene Obergrenze bei 9,8 liegt.
  • 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 +64 % bis +270 % gegenüber seriellem Abruf, nachgewiesen bei jeder Round-Trip-Zeit, von einer 14-ms-Rechenzentrumsleitung bis zu 63 ms per Satellit.
  • 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 5.0.4 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 ein Job fertig ist und der Daemon in den Leerlauf fällt, gehen die aufgebauten Puffer und Caches ans Betriebssystem zurück, statt für den nächsten Job gehalten zu werden.

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-, 7z- und zip-Posts werden schon während des Downloads gemappt und entpackt, ob gespeichert oder komprimiert, 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.
  • Einfache Split-Dateien. Sets, die nach HJSplit-Art in .001/.002- oder .1/.2-Teile zerlegt sind und gar keinen Archivkopf haben, werden erkannt und wieder zur Originaldatei zusammengefügt, statt als lose Teile auf deiner Platte zu landen.
  • 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 und separate .rev-Recovery-Volumes 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.
  • Komprimiert und verschlüsselt, im selben Durchlauf: Komprimierte Sets werden über die native RAR-Engine dekodiert, während die Volumes eintreffen, alles von RAR 1.5 bis zum neuen RAR7, und verschlüsselte werden beim Schreiben entsperrt, sobald Sie das Passwort angegeben haben - auch Ketten, bei denen das Passwort jeder Schicht in der darüberliegenden steckt. Ein Set ohne Passwort parkt 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 spielt 33 Fehlerprofile, und bei jedem einzelnen Testlauf laufen acht End-to-End-Durchgänge: eine saubere Referenz plus abgebrochene Verbindungen, Funkstille, Brownouts, Korruption, gedrosselte Leitungen, TLS-Abschneiden und 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. LunaSea und andere NZBGet-Fernsteuerungen verbinden sich unverändert. (nzb360: SABnzbd API)
  • 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. Sie kann auch deiner Plex-Watchlist folgen: Verknüpfe dein Konto oder füge die Adresse der Liste ein, und alles, was du dort hinzufügst, wird auch hier beobachtet.
  • Benachrichtigungen dort, wo du ohnehin hinschaust. E-Mail, Discord, Slack, Telegram, Pushover, ntfy, Gotify und jeder Apprise-Server, den du betreibst, dazu Bibliotheks-Refreshes für Kodi, Plex und Jellyfin und ein Webhook, den du selbst als Vorlage baust.
  • Watch-Ordner. Leg eine .nzb hinein, und sie wird geladen; die Datei verschwindet, sobald sie übernommen wurde. Unterordner werden ebenfalls beobachtet, und eine Datei, die in watch/tv landet, kommt in der Kategorie tv an.
  • 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.
  • Verhalten pro Kategorie. Jede Kategorie bringt ihren eigenen Zielordner, ihre Priorität und ihr Nachbearbeitungsskript mit, sodass Serien und Filme unter verschiedenen Regeln an verschiedenen Orten landen können.
  • 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“. Wähle in der Warteschlange oder im Verlauf viele Zeilen auf einmal aus und handle mit allen zusammen - mit der Maus oder von der Tastatur.
  • Ein Verlauf, der alles behält. Fertige Jobs wandern in einen eigenen Speicher ohne Zeilenlimit, mit Seiten und Suche, und sie überstehen Neustarts. Grenzen nach Alter und Anzahl gibt es, wenn du sie willst, und sie sind aus.
  • 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.
  • HTTPS ist eingebaut. Zeig ihm ein Zertifikat und einen Schlüssel, und der eine Listener antwortet https statt http, Dashboard wie API. Ein kaputtes oder abgelaufenes Zertifikat verweigert den Start und nennt die Datei, statt später anderswo als Browserfehler aufzutauchen.
  • Diagnose eingebaut: ein Log-Viewer direkt in der UI, den du nach Tag filtern und exportieren kannst, eine Antwort pro Download auf „warum ist das langsam?“, die die bremsende Stufe benennt, 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