Insufficient PAR Blocks

Also known as: not enough par blocks, need more blocks

The specific repair failure where missing blocks outnumber the recovery blocks posted with a release. A set posted with ten percent parity survives roughly ten percent loss and no more. Downloading additional .par2 volumes helps only when the poster uploaded them and they still exist. Otherwise the remedy is a second provider on an independent backbone that holds the segments the first one lacks.

The unit is the block, not the byte, and that changes the arithmetic in a way that surprises readers who reason in percentages. PAR2 divides the protected files into fixed-size blocks when the recovery set is created, and any block containing even one absent or wrong byte counts as one block lost. Damage scattered thinly across a set is therefore more expensive than the same volume of damage in one contiguous run.

The ledger

Two numbers decide the outcome. The first is the count of blocks the client cannot reconstruct from the data it holds. The second is the count of recovery blocks available across the index and all .volNNN+NN.par2 volumes. Clients usually print both, as blocks needed against blocks found, and the gap between them is the entire content of the error. It is exact: needing 412 blocks with 400 available fails in precisely the manner that needing 4,000 does.

Parity percentage is not a safety margin

A release posted with ten percent recovery survives roughly ten percent block loss. The figure is chosen by the poster at creation time, it is fixed once the set is posted, and it varies widely; some sets carry very little and older material was often posted with less than is customary now. Nothing on the reading side raises it. This is also why two jobs showing the same completion figure end differently. Completion describes the loss, parity describes the tolerance, and only the pair together predicts the result.

When more volumes exist, and when they do not

Additional parity is worth fetching only if three things hold: the poster created the volumes, the NZB lists them, and their articles are still on the server. Any of the three can fail. A set may have been posted with an index and one small volume. An NZB assembled from a partial scan can omit volumes that were posted. Recovery volumes expire on the same schedule as everything else, so an old release commonly loses its parity at the same time as its content. Where volumes are listed and unfetched, instructing the client to download the remainder is the first thing worth doing.

Distinguishing it from a repair that never ran

Three conditions get reported in similar language. A shortfall of blocks means repair ran and the arithmetic failed. No .par2 files found means the release was posted without recovery data or the NZB omits it, and no arithmetic happened at all. Repair disabled in the client's settings means the stage was skipped, which then presents downstream as an unpack failure on a set that could have been fixed. The par-check setting is worth confirming once, since a client set to skip repair silently converts recoverable jobs into corrupt ones. Fault for a genuine shortfall lies with the poster's parity choice combined with the spool's losses; neither the indexer nor the local machine can produce it.

Frequently asked questions

How many par2 blocks are needed to repair?

Exactly as many recovery blocks as there are lost blocks, or more. The client prints both figures, and the requirement is met when available blocks reach the number needed. There is no partial credit and no rounding in the reader's favour: one block short and the repair produces nothing at all.

Can more par2 files be downloaded to fix insufficient blocks?

Only if the poster created additional volumes, the NZB lists them, and their articles still exist on the server. Most clients fetch only as much parity as the shortfall requires, so unfetched volumes sitting in the queue are worth requesting first. Once every listed volume has arrived, no further parity can be obtained anywhere.