Von der NZB zur geprüften Datei
bevor andere fertig geladen haben.

nzbfast ist ein Usenet-Downloader, der um einen einzigen Durchlauf herum gebaut ist: Jedes Byte wird dekodiert, geprüft und entpackt, während es lädt. Danach kommt kein Zusammensetz-Durchlauf mehr, nichts bleibt am Ende zu prüfen oder zu entpacken. In dem Moment, in dem sich der Fortschrittsbalken füllt, ist die Datei fertig und nachweislich intakt.

8,31 Gbps auf einer 10 GbE-Leitung 190 GB → 4m33s bis zur geprüften Datei RAR-Volumes berühren nie die Festplatte Halb so viel Platte wie die Konkurrenz RAM-budgetiert · 0 Swaps, nie
Download Die Zahlen ansehen

macOS · Windows · Linux · Docker: eine einzige, in sich geschlossene Programmdatei, Reparatur- und Entpack-Tools eingebaut.

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

Warum es schnell ist

Drei Ideen, die die gängigen Clients nicht voll ausreizen

Das ist Architektur, keine Mikro-Optimierung, und jedes bisschen davon ist im Benchmark-Log mit Befehlen belegt, die du selbst nachfahren kannst.

🔁

Pipelined NNTP

Mehrere Artikel-Anfragen bleiben pro Verbindung gleichzeitig unterwegs, sodass ein Round-Trip den Socket nie leerlaufen lässt und TCP sein Congestion-Window zwischen Artikeln nie verfallen lässt. An vier Standorten haben wir +12 % bis +270 % gegenüber seriell gemessen, und eine Leitung sättigt schon bei 8 Verbindungen statt 30–50.

🚿

Die Ein-Pass-Pipeline

Artikel werden per SIMD an Ort und Stelle dekodiert, einmal an ihre endgültigen Offsets geschrieben, aus den Decode-Puffern PAR2-geprüft, und Store-Modus-RAR-Inhalte werden während des Downloads entpackt. Die Volumes existieren nie als Dateien. Schreiblast = Inhalt × 1,0.

🕸️

Union-Verfügbarkeit

Ein Artikel gilt erst als „fehlend“, wenn jedes konfigurierte Backbone ihn verweigert hat. Blockgenaue Buchführung entscheidet VOLLSTÄNDIG / REPARIERBAR / UNMÖGLICH, bevor Bytes verschwendet werden, holt die passgenaue Mindestmenge an Recovery-Blöcken und bricht aussichtslose Downloads in Sekunden ab.

Die Pipeline

Jedes Byte nur einmal anfassen

Die Konkurrenz schreibt die Archiv-Volumes, liest sie zum Prüfen zurück, liest sie zum Entpacken erneut und schreibt dann die Ausgabe, grob 2× Schreiben und 2× Lesen. nzbfast macht es stattdessen so:

socket ──TLS──▶ rapidyenc SIMD-Dekodierung (an Ort und Stelle - 4,95 GB/s pro Kern)
                   │
                   ├─▶ pwrite an den endgültigen Offset   (einfache Posts)
                   │      └─ oder: RAR-Map-Übersetzung ─▶ pwrite direkt in die
                   │         entpackte Datei (Store-Modus-Posts - die RAR-
                   │         Volumes berühren nie die Festplatte)
                   ├─▶ PAR2-Block-Hasher - jeder Block wird aus dem Decode-
                   │      Puffer MD5-geprüft; die Prüfung endet mit dem Download
                   └─▶ Verfügbarkeits-Register - blockgenauer Zustand, live
Beschädigter Post? Defekte Blöcke sind in dem Moment bekannt, in dem ihre Artikel scheitern, die passgenaue Mindestmenge an Recovery-Volumes wird während des Downloads geholt (22 Blöcke geholt für 20 benötigte, in der Bench-Runde), und die Reparatur fasst nur die beschädigten Bereiche an. Unmöglicher Post? Er bricht in Sekunden ab und hat dabei fast nichts geladen, bevor deine Quota es merkt.

Kernfunktionen

Alles, was ein ernsthaftes Setup braucht

Die komplette Liste (jede Stellschraube, jede Integration) steht auf der Funktionsseite.

  • Downloads auf Leitungstempo: Pipelined NNTP gemessen mit 8,31 Gbps auf 10 GbE; der schnellste Client auf jeder sauberen Benchmark-Etappe, bei jeder Größe.
  • Ein-Pass-Pipeline: Dekodieren, Prüfen und Entpacken überlappen; Store-Modus-RAR-Volumes berühren nie die Festplatte; verschachtelte Archive werden im selben Durchlauf entpackt; braucht 1× Platte, wo andere ~2× brauchen.
  • Union-Verfügbarkeit über mehrere Provider: blockgenaues Routing über Backbones; Vorab-Urteile; passgenaue Reparatur; früher Abbruch unmöglicher Posts.
  • Speicher-Budget: ein globales RAM-Budget mit sanften Auslager-Stufen. Es bringt deine Maschine nie zum Swappen: Ein 190-GB-Job läuft in einem 1-GB-Budget durch (~1,1 GB Spitzen-RSS).
  • Absturzfestes Fortsetzen: ein Journal auf Artikelebene heißt: Ein Absturz oder kill −9 mitten im Download kostet fast nichts. Es setzt fort und lädt nur neu, was noch nicht gesichert war.
  • Drop-in-APIs: SABnzbd-kompatible API und NZBGet-JSON-RPC: Sonarr, Radarr, nzb360 und LunaSea laufen unverändert. Ein-Klick-Import deiner SAB-/NZBGet-Konfiguration.
  • Eingebauter Indexer: scannt deine Newsgroups in einen durchsuchbaren lokalen Index und bietet Newznab, damit auch dein *arr-Stack darin suchen kann.
  • Posterwand mit schlüssellosen Metadaten: Artwork, Bewertungen, Besetzung und Handlung für alles in deinem Index, ganz ohne API-Keys, für die man sich anmelden muss.
  • Watchlist-Automatik: nenn eine Serie oder einen Film (ausgestrahlt oder nicht); geladen wird beim ersten Auftauchen, dann bis zu deiner Zielqualität aufgerüstet.
  • Eine einzige Programmdatei: Reparatur (par2) und Entpacken (RAR) stecken in der Binary. Auspacken, starten, fertig.

Benchmarks

190,6 GB → eine geprüfte 167,9-GB-Datei

Dieselbe Maschine, dieselben sechs Provider, Läufe verschränkt hintereinander. Zeit, bis eine benutzbare, entpackte Datei existiert, die einzige Kennzahl, die zählt. Jede Konkurrenz auf ihr dokumentiertes Bestes getunt, SABnzbds Pipelining etwa eingeschaltet, obwohl es ohne ausgeliefert wird.

nzbfast4m 33s
NZBGet 26.27m 58s · +75 %
SABnzbd 5.0.419m 32s · +329 %
rustnzb 1.3.4keine benutzbare Datei

190,6 GB NZB → eine einzelne 167,9 GB mkv, M1 Ultra auf 10 GbE, 6 Provider × 8 Verbindungen. Derselbe Job läuft in einem 1-GB-Speicher-Budget durch. Vollständige Tabellen, alle sieben Szenarien und die Etappen, die wir nicht gewinnen (plus Reproduktionsanleitung) auf der Benchmark-Seite.

Passt zu deinem Stack

Richte deine bestehenden Tools darauf

Sonarr / Radarr

Volle SABnzbd-kompatible API. Füge nzbfast als „SABnzbd“-Download-Client hinzu, und es läuft einfach: Grabs, Kategorien, Prioritäten, erneute Versuche, Nachbearbeitungs-Skripte (SAB_*-Vertrag), Verlauf. Die Newznab-Fassade lässt die *arrs außerdem deinen lokalen Index durchsuchen, als wäre er ein Indexer.

nzb360 / LunaSea

Der Daemon spricht auch NZBGets JSON-RPC. Die beliebten Handy-Fernsteuerungen bedienen nzbfast unverändert. Und das Dashboard selbst hat ein vollwertiges Handy-Layout, wenn du mal weg vom großen Bildschirm bist.

Umstieg von SAB oder NZBGet?

Ein Klick importiert deine Server aus einer bestehenden SABnzbd- oder NZBGet-Installation (liest auch sabnzbd.ini direkt). Watch-Ordner, RSS-Feeds mit Filtern, smarte Ordner mit TV-Ablage und Aufräumregeln kommen gleich mit.

Probier es in den nächsten zwei Minuten

Auspacken, Launcher doppelklicken, drei Fragen beantworten (oder es deine SABnzbd-Konfiguration finden lassen), und das Dashboard öffnet sich. Erster Download in unter zwei Minuten.

nzbfast herunterladen Die komplette Funktionsliste lesen