Corrupt Archive

The extractor's error message is more precise than it looks and is usually discarded too quickly. RAR stores a CRC32 for each file it contains, checked as data is written out, so a failure names the volume being read and the file being extracted at the moment of the mismatch. That pair of names turns a vague corruption complaint into a specific, addressable location inside the set.

Reading the CRC error as a coordinate

The named volume is where the bad data physically sits. Because an NZB lists every file in the release with its own segment set, a client can be pointed at that one volume and re-download it alone. On a large release this is a few hundred megabytes rather than the whole set, and where a second source on a different backbone is configured the refetch usually succeeds, because the missing articles were absent only from the first spool.

Clean verification followed by a failing extraction

This combination rules out the ordinary explanation, since PAR2 confirming the files match what was posted means the download reproduced the release faithfully. Three explanations remain. The set may have been reconstructed against recovery files belonging to a different posting of the same release, which happens when two NZBs sharing a release name land in one folder. Files from two separate grabs may be mixed in that folder, so the extractor is reading one volume from one posting and the next from another. Or the release was posted broken, which is uncommon but does occur and is recognizable because every reader hits the identical failure from every source.

Which layer actually failed

• Provider or spool. Articles missing beyond what parity covered, leaving reconstructed data that does not match. Verification would have reported damage before extraction began.
• Poster. A release archived incorrectly at creation. Verification passes, extraction fails, everywhere and for everyone.
• Local storage. A failing drive, an unstable external enclosure or a filesystem error altering bytes after they were written and verified. Re-running verification on the stored files is the test; a set that verified clean an hour ago and reports damage now was changed on disk, not in transit.
• Encryption. A wrong password reported as a checksum failure, which is not corruption at all.

Refetching one volume instead of the release

Most clients can requeue a single file from an NZB, and the practical procedure is to delete the damaged volume, fetch that entry again, and re-run verification against the existing .par2 files before extracting. Downloading the entire release again is slower and, if the missing articles are absent from the same source, produces the identical result. Where the same volume fails repeatedly from every configured source, its articles are gone and the set is not completable from those spools.