We use cookies to understand how the site is used and to improve it. You can accept them, or carry on with them switched off.
Also known as: PAR2 repair failed
The outcome when PAR2 verification finds more missing or damaged data than the recovery blocks in the set can reconstruct. Fetching the release's remaining .par2 volumes sometimes supplies enough blocks; more often the shortfall is too large and the absent segments must come from a server on a different backbone. Repair also fails when the disk runs out of space mid-check, which looks much the same in logs.
PAR2 does not degrade gracefully. Reed-Solomon reconstruction either has enough recovery blocks to solve for the missing ones or it does not, and there is no intermediate state in which a set comes out mostly repaired. A job one block short and a job a hundred blocks short produce the same outcome and, in most clients, the same log line. That is why the failure feels abrupt: the last fraction of a percent of a download carries exactly the weight of the first.
The count of blocks the client cannot supply is compared against the count of recovery blocks it can obtain from the .par2 files. At or below, the set rebuilds exactly, byte for byte. One over, nothing is written. Repeating the repair, moving the files, or switching to a different implementation does not alter the arithmetic; par2cmdline, MultiPar and the repair built into a download client solve the same equation and reach the same verdict.
Clients do not download the whole recovery set by default, and this is the most common reason a repair failure is premature. The small index .par2 is fetched first and used to verify. The client then calculates the shortfall and requests only as many .volNNN+NN.par2 volumes as that shortfall requires, leaving the rest in the queue unfetched. If the log shows repair failing while volumes remain unrequested, the set has not exhausted its redundancy; more often the volumes themselves failed to download, which is a missing-article problem wearing a repair failure's label. A repair that failed after every volume in the set arrived has genuinely run out of parity.
Verification and reconstruction both need working room on disk. Repair writes reconstructed data rather than patching files in place, so the stage can need free space on the order of the set size again, on top of the archive already stored. Running out part way through aborts the repair, and several clients report that abort in wording close to a genuine block shortfall. Permissions on the incomplete folder do the same thing. Checking free space on the volume holding the incomplete folder before concluding anything about the release is worth the ten seconds, because this cause is local, common and completely invisible in the block counts.
Files that verified clean are intact and remain usable independently of the set-level verdict, since PAR2 reports status per file and the failure applies to the reconstruction rather than to files that never needed it. Where the damage falls inside one archive volume, refetching that single volume from a source on a different backbone is far cheaper than a fresh download, and the NZB already lists its segments. Where the missing data is spread across most files, the release is not obtainable from that spool and a second source is the only technical remedy.
Browse all terms in Errors & Troubleshooting, or see the full Usenet glossary.