10 × 200 MB downloads, queued at once
10 Gbit/s · 0 ms RTT · TLS
VS. SABnzbd
71.4% faster53.6% less CPU timeVS. NZBGet
620.7% faster83.4% less CPU timeQ10-unthrottled · Queue-drain clock; output verification completes afterward.
SELF-HOSTED · ALL-IN-ONE DOWNLOADER
Weaver coordinates downloading, verification, repair, and extraction as one pipeline. It prioritizes whatever gets your finished file to disk next, with no external unpackers or repair tools.
single binary · repairs while downloading · Docker · Linux · macOS · Windows
ONE COORDINATED PIPELINE
Along with prioritizing recovery blocks, Weaver pulls forward the archive pieces that unblock identification and extraction, keeping the whole job advancing.
Balances latency and load, backs off when a provider hits capacity, and saves backup servers until your primaries are truly exhausted.
Like other downloaders, Weaver verifies clean files as data arrives. It also records repair-block checksums, so damaged files reach repair with the bad blocks already identified.
PAR2 verification and repair run in process, tuned for modern CPUs and accelerated by the GPU on supported Macs.
For common RAR posts, Weaver writes the finished file as data arrives instead of writing and rereading the archive. Repair still works, and 7z extraction resumes instead of restarting.
RAR, 7z, ZIP, tar, gzip, bzip2, xz, zstd, and brotli are handled in process, with no external unpackers or repair tools to maintain.
STREAMING EXTRACTION
A conventional RAR pipeline writes the archive, reads it back, then writes the extracted file. That is three trips across storage, and on a NAS every trip runs at network speed with two of them starting only after the download ends. Weaver removes the archive round trip for the store-method RARs commonly used for video.
CONVENTIONAL DIRECT UNPACK
Three storage passes
WEAVER RAR
One storage pass
Decoded bytes are written at their final file offsets as articles arrive, so the archive volumes never need to land on disk. Encrypted archives and PAR2 repair still work. If streaming cannot finish, Weaver reconstructs the archive from bytes it already has and falls back without starting the download over.
Compressed 7z data must still be stored, but Weaver decodes it while the split archive arrives and writes output concurrently. When damage interrupts extraction, it keeps the verified prefix, waits for repair, and resumes instead of throwing away completed work.
CHECKED TWO WAYS, READ ONCE
Two different people vouch for a Usenet post. The poster stamps a checksum on every article. The PAR2 set stamps a checksum on every repair block. The two grids are cut at unrelated places, so a stretch of data that satisfies both was seen intact by both. Weaver computes both grids from the single checksum pass it already runs while decoding.
ONE STREAM OF DECODED BYTES
ARTICLE GRID
Cut where the poster split the file into articles. Catches damage in transit and tells Weaver which article to fetch again, from a different server, right away.
REPAIR GRID
Cut where the PAR2 set defines its repair blocks, which almost never line up with articles. This is the evidence repair actually needs, and Weaver has it before the file is closed.
When the last article lands and both grids agree, the file is done. There is no verification pass afterwards and nothing is read back from disk.
Other downloaders know a file is bad and hand it to PAR2 to find out where. Weaver hands PAR2 the list of bad blocks, so repair starts with the answer instead of the question.
A post can carry more than one recovery set, each with its own block size. Weaver tracks every grid in the same pass, so each set gets its own verdict. One clean set never signs off on another, and one damaged set never drags a clean one into repair.
Checksums detect corruption, not forgery. Anything the grids cannot vouch for is verified the conventional way at completion.
END-TO-END BENCHMARKS
From the moment an NZB is submitted to a finished file. Same fixtures, same shaped link, same transport, every client paired in the same measurement block.
10 Gbit/s · 0 ms RTT · TLS
VS. SABnzbd
71.4% faster53.6% less CPU timeVS. NZBGet
620.7% faster83.4% less CPU timeQ10-unthrottled · Queue-drain clock; output verification completes afterward.
1 Gbit/s · 100 ms RTT · TLS
VS. SABnzbd
105.8% faster57.4% less CPU timeVS. NZBGet
125.4% faster47.9% less CPU timeB3-bluray-rtt100 · Submission to terminal state and verified output; median over paired blocks.
Animations compress each race to 13 seconds. CPU traces illustrate measured averages, not sampled activity; 100% equals one CPU core. “Faster” is (baseline time ÷ Weaver time − 1) × 100; CPU savings compare total CPU seconds.
ONE BINARY, MORE FORMATS
Weaver handles extraction and repair inside the application, including archive and compression formats that other Usenet downloaders do not route automatically.
| FORMAT | WEAVER | NZBGET | SABNZBD |
|---|---|---|---|
| RAR (all formats) | Native + streaming | External UnRAR | External UnRAR |
| 7z | Native + streaming | External 7-Zip | External 7zz |
| ZIP | Native | External 7zz | |
| TAR | Native | Native - limited formats | |
| xz, zstd, brotli, bzip2 & gzip | Native | ||
| PAR2 | Native | Native | External process |
Native means no separate unpacker or repair executable is required.
HOW IT COMPARES
SABnzbd and NZBGet already handle the fundamentals well: all three prioritize needed repair data and retry bad articles across servers. Weaver goes further by sharing progress across the entire pipeline.
| WEAVER | NZBGET | SABNZBD | |
|---|---|---|---|
| Beyond repair | Prioritizes identification and extraction blockers | Priority, then file order | Priority, then file order |
| Server handling | Latency/load routing plus adaptive capacity | Penalty windows plus fixed limits | Penalty windows plus 502 thread reduction |
| Damaged-file evidence | Repair-block evidence captured in flight | File-level plus partial block checks | File-level evidence |
| Article decoding | Hardware-accelerated yEnc and uuencode | Hardware-accelerated yEnc; standard uuencode | Hardware-accelerated yEnc; standard uuencode |
| Runtime | Native Rust; every stage runs in parallel | Native C++; thread per connection | Python with native decoding, TLS, and disk I/O; core coordination remains GIL-bound |
| Existing integrations | NZBGet API plus both script formats | NZBGet native | SABnzbd native |
Architectural comparison. Exact performance varies with hardware, providers, and archive shape.
Need setup steps first? Read the installation guide →
latest release: v0.13.1