Repository navigation
Quick Runs Miss a Repair Failure the Full Run Finds #1175
Description
Problem
A quick run exists to reproduce every issue a full run finds, in less processing time. The full-mode run behind the refreshed corpus catalog found one case a quick run misses. So the quick run reports a file as repaired that the full run reports as a failed repair.
It shows on a file whose defect sits in a stream the re-encode repair copies, such as a PGS subtitle with an invalid bitmap size:
- Full mode: the whole file is re-encoded. The bad subtitle segment is copied through, verify fails again, and the file reads
RepairFailedandVerifyFailed. - Quick mode: the re-encode repair runs with
-t 30. The 30-second output never reaches the bad segment, so verify passes and the file readsRepaired.
The quick run hides the failure, so a regression in this repair path would not show up in quick runs. It also leaves the catalog's Error and VerifyFailed membership out of step with what a quick run reports. The previous catalog came from a quick-mode run and recorded Repaired.
To Investigate
- Make quick mode reach the full-mode outcome. For example, keep the repair re-encode's verify on the content the original verify failed on, rather than on the first 30 seconds.
- Check that
reduce_corpus.pybuilds a clip that keeps the defect and reproduces the full-mode outcome under a quick run of the reduced corpus. Its gate compares the clip's state against the catalog. - Audit the other quick-mode limits (
QuickScanon probe,idet, and the repair re-encode) for the same masking. - Bring the HAC
regression-diff.mdpersistent-failures entry in line once quick and full membership agree, or name the known gap until they do.
Activity
ptr727 commentedon Nov 2, 2026
Reduce evidence from the full-mode 3.23.53 catalog.
RepairedandVerified. The catalog's ground state isRepairFailedandVerifyFailed. Reduce then keeps the source whole, which is 6 GB of the corpus. A quick run of the whole file still repairs through the snippet, so keeping it whole does not reproduce the full-mode outcome either.ClearedTags, withTagsdetected) cannot be clipped either. Every cutter strips the tags, so each clip misses that detection. The best rung (artificial-container) misses only that detection. Reduce keeps that 2.6 GB source whole.Together these take the staged reduced corpus from 5.1 GB to 13 GB. Promotion is on hold, and the current reduced corpus stays in place until this is fixed. After that, reduce is rerun.
ptr727 commentedon Nov 2, 2026
The maintainer answered #1182 on 2026-11-02. A quick run is not expected to match a full run, so quick mode stays as it is, and the first item under "To Investigate" is dropped. The corpus goal is a set of reasonably sized files that reproduces every known issue.
What remains here is the reduce side. The repair-snippet file is kept whole because no cutter produces a clip that reproduces the catalog's
RepairFailedandVerifyFailed. A clip has to carry the defect where the run that judges the clip will reach it, and that file is then kept as a clip rather than whole.Keep MP4 Track Names and Snippet-Reachable Defects in Reduced Clips (#…
ptr727 commentedon Nov 3, 2026
The reduce side is fixed on
developby #1183. It stays open until a promotion carries it tomain.--testsnippetsand no--quickscan, so a repair re-encodes only the clip's first 30 seconds while verify reads the whole clip. A copied PGS defect has to sit inside that snippet for the clip to endRepairFailedagain.locate_issue.py --write-rulesleads aRepairFailedsource's window by at most half the snippet.artificial-containerrung now carries them as titles, and it passes as a 51 MB clip instead of 2.4 GB.regions, which no tool writes, and the located ones inlocated, so a locate run cannot overwrite a tuned window.The full reduce over the refreshed catalog is still to run, as the corpus refresh.