Weaver vs. SABnzbd and NZBGet

SABnzbd and NZBGet are mature, trustworthy downloaders. Both get the fundamentals right, and for a clean, well-posted download all three clients — Weaver included — end in the same place: a verified result with no wasted work. This page is not about which client “catches more corruption.” It’s about the machinery underneath: what each client checks, when it touches your disks, and which situations make the differences visible.

If you only remember one thing: the differences barely matter on a healthy download. They matter when something goes wrong — damaged posts, obfuscated names, very large jobs — and in how much disk traffic the whole pipeline generates along the way.

The shared foundation

All three clients stand on the same two integrity sources:

• yEnc article checksums. Every downloaded article carries a checksum, and every client verifies it during download. Damaged articles are detected and retried the moment they arrive — this part is equal everywhere.
• PAR2 recovery sets. The PAR2 files posted alongside a release carry checksums for every file, sliced into fixed-size blocks, plus recovery data that can rebuild missing or damaged blocks.

The interesting question is what each client does between those two: how it decides a finished download is intact without reading everything back from disk.

Verifying without re-reading

Re-reading a completed download to verify it doubles your disk traffic and adds minutes to large jobs. All three clients avoid it on the happy path — with different machinery.

SABnzbd combines the article checksums it already collected into a single whole-file checksum, then compares that against a value derived from the PAR2 data, plus a file-size check. One comparison per file, zero bytes re-read. It’s a remarkably small mechanism, and decades of real-world use have proven it sufficient. The same comparison doubles as obfuscation handling: if an oddly-named file’s checksum matches a PAR2 entry, SABnzbd renames it to its real name — also without reading it.

NZBGet performs the same style of whole-file quick check. Its extra trick appears when a file is damaged: because it kept per-piece checksums from the download, it can mark which blocks of a damaged file are still good and hand that map straight to its repair engine, instead of treating the file as one opaque failure.

Weaver keeps verification at the PAR2 block level for every file, all the time. As articles decode, Weaver derives a checksum for each PAR2 block from the same single pass that verifies the article — no extra hashing — and each block gets its own verdict. A block only counts as verified when two independently-produced references agree: the article checksums written by the poster and the block checksums written by whoever created the PAR2 set. Blocks that can’t meet that bar simply fall back to being read and checked at completion, and repair never trusts any of it blindly — it re-derives everything it touches.

Does finer-grained checking catch more corruption?

In practice, no — and it’s worth being straight about this. Against real-world corruption (transport damage, truncation, bad articles), a whole-file checksum comparison is already overwhelmingly reliable, and SABnzbd’s long history is the proof. Weaver’s per-block verdicts are not a stronger corruption detector on a clean download. Their value shows up in the situations below: damage, obfuscation, partial downloads, and pipelines that avoid writing data twice.

When something is damaged

This is the path where the mechanisms diverge most, and it’s also the moment you’re most likely to be watching the queue.

• SABnzbd knows that a file is damaged, but not where. Its quick check produces one verdict per file, so a single bad block sends the job to a full PAR2 verification pass — which re-reads the entire set from disk to locate the damage — before repair can start. On a job of tens or hundreds of gigabytes, that re-read is usually the single slowest step in the whole pipeline.
• NZBGet narrows the cost meaningfully: files that pass the quick check are skipped, and damaged files bring their good-block map along, so the repair engine doesn’t need to rediscover what’s already known.
• Weaver already holds a per-block picture when the download finishes: which blocks verified, which are damaged, which are missing. Healthy files don’t get re-read to diagnose a damaged neighbor, and repair planning starts from the block verdicts rather than from a fresh scan of the whole set. After repair, only the files that repair actually rewrote are re-verified — not everything.

The practical difference: with one damaged block in a large job, the time between “download finished” and “repair running” is dominated by re-reading in the whole-file model, and mostly disappears in the per-block model.

Obfuscated posts

Posts with scrambled names are routine on Usenet, and each client resolves them differently:

• SABnzbd renames a file when its whole-file checksum matches a PAR2 entry — free, but it requires the file to be fully intact, since one bad article means no whole-file match.
• NZBGet reads the first 16 KB of each candidate file and matches it against the identity hashes in the PAR2 data — small reads, per file.
• Weaver identifies files by their block-verdict pattern against the PAR2 set, which works without reading anything back and doesn’t require the file to be undamaged for the blocks that did verify. Files that can’t be identified in-stream fall through to the same full verification pass the other clients use.

Extraction and total disk traffic

All three clients unpack archives while the download is still running (SABnzbd’s Direct Unpack, NZBGet’s Direct Unpack, Weaver’s incremental extraction), so a healthy job finishes unpacking shortly after it finishes downloading. The difference is in how many times the payload crosses your disks.

The traditional pipeline writes every archive volume to disk, verifies, then reads every volume back to extract, then writes the extracted result: roughly two full writes and one full read per job. For supported jobs, Weaver’s direct store skips materializing archive volumes entirely — extraction reads directly from verified download data, and the volumes are never written as files at all. That saves a full write and a full read of the entire archive payload, which matters for job turnaround, for SSD wear, and for temporary-space headroom on large jobs.

This capability is also the honest answer to why Weaver carries per-block verification machinery in the first place: when there is no file on disk to fall back on, block-level verdicts are the verification. A whole-file-checksum model has nothing to check until the file exists.

Repair

• SABnzbd delegates to an external par2 executable (commonly par2cmdline-turbo) — battle-tested, and the repair run performs its own verification pass as part of the process.
• NZBGet integrates its repair engine and feeds it the good-block knowledge from download time.
• Weaver integrates its repair engine as well, plans repairs from block verdicts, streams reconstruction, and re-verifies exactly the files repair rewrote.

All three produce correct repairs. The differences are in how much reading happens before and after the reconstruction itself.

Summary

Mechanism	SABnzbd	NZBGet	Weaver
Verification verdict granularity	Whole file	Whole file, plus good-block map for damaged files	Every PAR2 block, every file
Clean download re-read	None	None	None
Damaged download: locating the damage	Full re-read of the set	Damaged files only, with good blocks pre-mapped	Already known per block
Obfuscated-name resolution	Whole-file checksum match (intact files)	Reads 16 KB per candidate file	Block-verdict identity, no read
Unpack during download	Yes (Direct Unpack)	Yes (Direct Unpack)	Yes (incremental extraction)
Archive volumes written to disk	Always	Always	Skipped for supported jobs
Repair engine	External par2 executable	Integrated	Integrated
Post-repair verification scope	Repair tool’s own pass	Quick-checks repaired files	Re-reads only rewritten files

The fair conclusion

If SABnzbd or NZBGet has served you well, nothing on this page says your downloads were at risk — they weren’t. All three clients verify honestly and repair correctly. The differences are about cost, and they concentrate in specific circumstances: how long a damaged job spends re-reading before repair starts, how obfuscated posts resolve, and how many times a large job’s payload crosses your disks end to end. If those situations are rare in your usage, any of the three is a fine choice. If they’re routine — large jobs, imperfect posts, SSD-backed temporary space — the block-level model is where Weaver spends its complexity, and this page is the plain-language account of what that buys.