Repository navigation
Closed
Labels
pre-existingReview finding classed pre-existing per local-strict-review Disposing of FindingsReview finding classed pre-existing per local-strict-review Disposing of Findings
Description
Behavior
A signal-ended FfMpeg verify run is recorded in ToolErrorScope.SignalCount, so DeleteFailedFile() keeps the file and a failed repair leaves its state unchanged. The repair runs themselves are not covered. FfMpegTool.ConvertToMkv(), the FfMpeg re-encode, and HandBrakeTool.ConvertToMkv() run with CommandResultValidation.None, so a run killed by a signal reports as executed with a non-zero exit, and the repair tier just fails.
- A verify finds a genuine decode error, for example FFmpeg exit 183 for invalid data.
- The remux tier fails, then the FfMpeg re-encode is killed by a signal, for example by the out-of-memory killer during a long encode, and HandBrake fails or is killed too.
VerifyAndRepair()setsVerifyFailedandRepairFailed, and withDeleteInvalidFileson,DeleteFailedFile()deletes the file, although the repair never ran to a result.
This predates the change for #1090, which covers only the verify run. CodeRabbit raised it on #1093.
Reproduction shape
- Set
Verify: true,AutoRepair: trueandDeleteInvalidFiles: true. - Process a file whose verify reports a decode error, and kill the FfMpeg re-encode with SIGKILL while it runs.
- The file ends
VerifyFailedandRepairFailed, and it is deleted.
The decision
- Treat a signal-ended repair run as a tool that did not run. Record it in
ToolErrorScope.Count, so the failed repair leaves the state unchanged and the file is kept, and the next run repairs again. A repair that crashes on the same input every time re-runs on every run. - Treat it like the signal-ended verify. Record it in
SignalCount, which keeps the file and also leaves the state unchanged, the same outcome as choice 1 through the Decide How a Signal-Terminated FfMpeg Verify Run Is Classified #1090 path. - Keep the current behavior. The verify already judged the media corrupt, so a killed repair still ends in a delete.
Choices 1 and 2 differ only in which count carries it. The question is whether a killed repair should block the delete at all.
Metadata
Metadata
Assignees
Labels
pre-existingReview finding classed pre-existing per local-strict-review Disposing of FindingsReview finding classed pre-existing per local-strict-review Disposing of Findings
Activity
ptr727 commentedon Oct 30, 2026
Decision: count a signal-killed repair run as a tool that did not run. Record it in
ToolErrorScope.Count, so the failed repair leaves the state unchanged, the file is kept, and the next run repairs again. This is choice 1. It matches how a launch failure is treated, and the accepted cost is that a repair that crashes on the same input re-runs on every run. It is now an ordinary fix.Keep a File Whose Repair Run a Signal Ended (#1112)