Features

The short version up top, the full detail below.

  • Pipelined NNTP at line rate: 8.31 Gbps measured on 10 GbE.
  • One-pass pipeline: decode, verify and extract overlap; RAR volumes never touch disk; nested archives unpack in the same pass.
  • Multi-provider union availability: complete from the union of your servers, or abort early.
  • Memory budget: bounded RAM, graceful spill, never swaps.
  • Crash-safe resume: article-level journal; kill −9 mid-job and it picks up where it left off.
  • SABnzbd-compatible + NZBGet JSON-RPC APIs: Sonarr/Radarr/nzb360/LunaSea work unmodified.
  • Built-in indexer: scan groups into a local, searchable, Newznab-serving index.
  • Poster wall: artwork, ratings, cast, episode grids; no API keys.
  • Watchlist auto-grab + quality upgrades: grab on first appearance, upgrade to target quality.
  • Single self-contained executable: par2 + RAR unpack embedded.

Engine & speed

  • Pipelined NNTP. Keeping several requests in flight per connection beats both round-trip latency and TCP congestion-window decay. We measure anywhere from +12% to +270% over serial fetching, and about 8 connections per server is enough to saturate the line.
  • SIMD yEnc decode (rapidyenc, with NEON and AVX kernels) runs at 4.95 GB/s per core, decoded in place as the bytes land in the receive path.
  • Multi-server shared queue. Providers self-balance to within ~2% with no tuning. Each one's real rate is tracked, and the tail of a job is duplicate-dispatched so a single slow server can't drag out the finish.
  • Cross-job soak. The tail of job N overlaps the start of job N+1, so the line stays lit edge to edge across a whole queue: 2% idle here versus SABnzbd's 61% dark in the same bench.
  • Slow-job watchdog. A download crawling on one slow server while the rest sit idle gets bumped to the back of the queue, progress kept, and resumes once the queue clears.
  • Idle-server prefetch: a server the active job can't use, because its articles aren't stored there, starts on the next queued job instead of sitting idle.
  • Connection-tuning ladder. Rather than guess, it measures where each provider's throughput actually stops climbing (connections asked for versus granted) and settles there.
  • Auto-speed governor: an optional LEDBAT-style RTT governor that yields to the rest of your household's traffic and takes what's left of the line.
  • Speed limits and a weekly scheduler: live-adjustable caps, a local-time (DST-safe) schedule, and a "pause for N minutes" that resumes on its own.
  • Memory budget. One global RAM budget (auto: a quarter of RAM, capped, overridable). As it tightens, buffers shrink first, then data spills to disk and reads back once the job settles. It never swaps. A 190 GB job finishes inside a 1 GB budget at ~1.1 GB peak RSS, and there's a measured, documented 2 GB profile for NAS boxes.
  • Backpressure. A slow disk throttles the sockets instead of letting RAM fill. It holds within ±1% of a write cap, and RAM actually falls under pressure.
  • Post-job memory trim: once idle, the daemon hands freed memory back to the OS, dropping to around 8 MB between jobs on macOS.

The one-pass pipeline

  • Write once. Decoded articles are pwritten straight to their final file offsets. No temp files, no separate assembly pass.
  • In-stream PAR2 verification. Every block is MD5-hashed from the decode buffers as it arrives, so verification finishes the moment the download does. That beats the quick-check the other clients settle for, and it costs nothing.
  • Direct extraction: store-mode RAR posts (most scene releases) are mapped and extracted while they download, so the volumes never land on disk at all. Disk written comes to content × 1.0 and disk needed to 1×, where others want roughly 2×.
  • Nested archives, and depth barely costs anything. Archives inside archives - RAR in RAR, 7z inside RAR, ladders many levels deep - are denested as the bytes arrive, inside the pass we were already making. That is the whole difference: a client that writes each layer out, closes it, reopens it and scans it again pays a fresh pass for every level, so each layer it goes down costs it another round trip through the disk. Ours ride along in the first pass, and the payload comes out of a ten-level ladder the same way it comes out of a one-level one. One copy on disk where write-out-and-rescan holds two or three.
  • Deobfuscation. Obfuscated posts are renamed from their PAR2 metadata, ROT13-scrambled names get rescued, and hash-named junk is classified and gated out.
  • Exact-fit repair. Damaged blocks are known as they happen, so only the minimum-byte set of recovery volumes gets fetched (a knapsack solve) and repair touches nothing but the damaged spans.
  • RAR recovery records. When PAR2 is exhausted, or was never posted, embedded RAR recovery records repair damaged volumes in place.
  • Repair at every depth. A PAR2 set packed inside an inner layer is found and run at its own level, and a par-only post (data deleted, a 100%-recovery set left behind) is rebuilt whole and then unpacked.
  • Compressed and encrypted fallback: non-store posts materialise and unpack through the native RAR engine, everything from RAR4 to the new RAR7, overlapped with the rest of the queue. Encrypted sets park with a clear message instead of failing quietly.
  • It goes looking for the password itself. Most encrypted posts never need you. It tries the NZB's own metadata and the {{pw}} filename convention, the *arr API, then any short text note posted alongside the files, and failing all that the release and file names themselves. It repeats that hunt at every level, so a chain that hides each layer's password inside the layer above it - a different password at every level - unlocks all the way down with nothing typed. Anything genuinely left over gets a 🔑 unlock on the dashboard: it unlocks in the background, then files as normal.
  • Safety rails. Repaired source volumes are write-protected while re-extraction runs, the finished file's own checksum is verified end to end (on by default), and an exit code reports "success" only when the end state is genuinely usable.

Reliability & availability

  • Pre-flight availability check. Pipelined STAT sweeps build a per-article × per-server matrix in seconds and mark the job COMPLETE, REPAIRABLE or IMPOSSIBLE before a byte of content is fetched. An impossible post aborts having pulled almost nothing.
  • Union routing. An article counts as missing only once every live server has refused it; until then it routes to whichever server holds it. Backbones differ in retention and takedowns, so the union quietly completes posts that no single server could.
  • Crash-safe journal. The journal works at article granularity. Send a kill −9 mid-job and it comes back, refetching only what hadn't been persisted; the queue and history outlive restarts.
  • Park and retry: failed jobs park in history, and a retry pulls only the pieces still missing.
  • Chaos-tested. A mock NNTP server runs ten end-to-end failure scenarios (430s, corruption, truncation, stalls, dead servers, kill −9) on every single test run.
  • Provider reliability scoring. Per-server completion rates are kept for good and shown in the dashboard, with a warning below 98%.
  • Server diversity analyser. It STAT-samples across your servers and clusters them by the gaps they share, so you can tell which "different" providers are really the same backbone before paying for redundancy you don't actually have.
  • Quotas, block accounts and a disk guard: daily and monthly quotas, lifetime byte budgets for block accounts (auto-excluded once spent), a low-disk pause, and per-provider daily usage history.
  • Dupe detection: dupekey and dupescore, with a held alternative promoted automatically the moment a grab fails.
  • Retention-aware routing. Posts older than a server's retention skip it entirely, and anything no server can serve fails at once rather than spinning.

Automation & integrations

  • SABnzbd-compatible API: the whole surface the *arrs actually use: addfile/addurl, categories, priorities, per-job pause/resume, retry, pagination, two-tier API keys. Sonarr and Radarr talk to it as if it were SABnzbd.
  • NZBGet JSON-RPC facade. nzb360, LunaSea and other NZBGet remotes connect unmodified.
  • Newznab server. Your local index answers t=search/tvsearch/movie, so the *arrs can treat your own scans as an indexer.
  • RSS auto-grab: an indexer's feed is the same thing a news reader subscribes to, except it lists what has just been posted to Usenet. Anything matching the filters downloads itself. Feeds are filtered with an NZBGet-style language, added and edited live from the dashboard.
  • Watchlist. Name the shows and films you want, even ones that haven't aired yet. Each episode is grabbed on its first appearance and upgraded until it reaches your target quality (say, 720p → 1080p REMUX), with the superseded copy deleted only after the upgrade has verified. An airdate calendar shows what's coming.
  • Watch folder. Drop a .nzb in and it downloads; the file disappears once it's been taken.
  • Smart folders: regex, keyword and size rules sort downloads into categories at enqueue time, with optional TV filing to Show/Season NN/Show - S01E02.ext.
  • Cleanup rules: junk extensions are removed once a job completes.
  • Move to a NAS: finished downloads move to a destination folder after unpack and renaming, keeping the category layout, and per-category destinations can send TV and films to different shares. If the share is unreachable, the files stay put.
  • Post-processing scripts. They honour SABnzbd's SAB_* environment contract, so the scripts you already have run as they are.
  • One-click migration. It imports servers from a SABnzbd ini or an NZBGet conf, and reads sabnzbd.ini directly if that's all it can find.
  • Spotnet ingestion: spot signature verification and NZB synthesis, built right in.

Preview & library

Dashboard & settings

Queue with a per-download detail drawer: per-file progress bars, verify blocks, per-server contribution
Queue drawer: per-file bars, verify blocks, per-server contribution.
Settings: server editor and live speed/scheduling controls
Every setting editable in the browser. Most apply live.
Phone layout of the dashboard
Proper phone layout, same daemon.
  • Live charts, no libraries. Everything polls once a second (a throughput area, per-provider stacked area, a verify-health timeline, queue burn-down, a speed histogram) and the charts widen their time window as you widen the browser.
  • Resource monitor: CPU, RAM against budget, disk writes and network on a single chart, with a low-disk warning.
  • Provider leaderboard. Servers re-sort themselves by live performance, each showing session bytes, connection count, utilisation and reliability.
  • Queue management: drag to reorder, set priority and category inline, open a per-download drawer, pause optimistically, or "pause for N minutes".
  • Everything is configurable in the browser: servers (with live connection tests), speed and schedule, connections/window/decoders, disk and quota, watch folders and scripts, indexing gates, library, RSS, and security with key rotation. Settings survive restarts.
  • Diagnostics built in: an in-UI log viewer, a system benchmark that finds your network, compute and disk ceilings and tells you what to do about them, the server-diversity analyser, and the connection ladder.
  • Data usage: 14-day stacked per-provider bars, daily history, and lifetime counters for block accounts.
  • 28 languages. The dashboard ships fully localised, right-to-left scripts included; the manual and this site are in 16.
  • Quality of life. Drag and drop a .nzb anywhere, desktop notifications, completion sounds, a first-run wizard, and serve --open.

Deployment