fix: find rip output by suffix, not by pasting the reported disc name #9

Merged

nugget merged 1 commit from fix/disc-name-sanitised-in-filenames into main

2026-08-22 23:37:12 -05:00

claude commented

2026-08-22 23:25:09 -05:00

Collaborator

MakeMKV sanitises the disc name when it builds output filenames, so the name it reports is not the name it writes.

A Monty Python disc reported MONTY PYTHON’S LIFE OF BRIAN (U+2019, bytes e2 80 99) and wrote MONTY PYTHON'S LIFE OF BRIAN_t01.mkv (ASCII 0x27).

rip_disc.py predicted the output path from the reported name, so it looked for a file that never existed. All four rips from that disc were reported FAILED with "0 read errors" while sitting complete on disk, every log saying Copy complete. 1 titles saved.

The failure mode is quiet in the worst way: the completion message passes, only the existence test fails, so it reads as "the output vanished" rather than "the checker looked in the wrong place."

Change

Locate output by its _tNN.mkv suffix — MakeMKV's own, and immune to mangling of the leading name.
README: this entry, plus a note that a container duration can far exceed its video (a menu asset held 20s of video over a 5-minute audio bed and reported 300s against the scan's 20s — authoring, not a bad rip).

Verification

syntax + --help gate from AGENTS.md: pass
reproduced the exact mismatch: old predicted-path check exists=False, new suffix match finds the real file
confirmed against the four real rips this came from

MakeMKV sanitises the disc name when it builds output filenames, so the name it **reports** is not the name it **writes**. A Monty Python disc reported `MONTY PYTHON’S LIFE OF BRIAN` (U+2019, bytes `e2 80 99`) and wrote `MONTY PYTHON'S LIFE OF BRIAN_t01.mkv` (ASCII `0x27`). `rip_disc.py` predicted the output path from the reported name, so it looked for a file that never existed. **All four rips from that disc were reported FAILED with "0 read errors" while sitting complete on disk**, every log saying `Copy complete. 1 titles saved.` The failure mode is quiet in the worst way: the completion message passes, only the existence test fails, so it reads as "the output vanished" rather than "the checker looked in the wrong place." ## Change - Locate output by its `_tNN.mkv` suffix — MakeMKV's own, and immune to mangling of the leading name. - README: this entry, plus a note that a container duration can far exceed its video (a menu asset held 20s of video over a 5-minute audio bed and reported 300s against the scan's 20s — authoring, not a bad rip). ## Verification - syntax + `--help` gate from AGENTS.md: pass - reproduced the exact mismatch: old predicted-path check `exists=False`, new suffix match finds the real file - confirmed against the four real rips this came from

claude added 1 commit

2026-08-22 23:25:09 -05:00

fix: find rip output by suffix, not by pasting the reported disc name eb159e6c35

MakeMKV sanitises the disc name when it builds output filenames, so the name it
reports is not always the name it writes. A Monty Python disc reported

    MONTY PYTHON’S LIFE OF BRIAN     (U+2019, bytes e2 80 99)

and wrote

    MONTY PYTHON'S LIFE OF BRIAN_t01.mkv   (ASCII apostrophe, 0x27)

rip_disc.py predicted the output path by pasting the reported name together with
the title number, so it looked for a file that was never created. All four rips
from that disc were reported FAILED with "0 read errors" while sitting complete
on disk, every MakeMKV log saying "Copy complete. 1 titles saved."

The failure is quiet in the worst way: the completion message is checked and
passes, and only the existence test fails, so the output looks like it vanished
rather than like the checker looked in the wrong place. Nothing was deleted only
because there was nothing at the guessed path to delete.

Locate the output by its "_tNN.mkv" suffix instead. The suffix is MakeMKV's own
and survives any mangling of the leading name.

Also record two entries in the README: this one, and that a title's container
duration can far exceed its video. A menu asset on the same disc held 20 seconds
of video over a five-minute audio bed and reported 300s against the scan's 20s,
which is authoring, not a bad rip -- the playlist remains what settles identity.