JMR-dev/LibreMediaConverter
1
0
Fork 0
Code Issues 16 Pull Requests Actions Packages Projects Releases Wiki Activity

MediaProbe's container-alias arms: read whether each is a fixture gap or dead by construction #262

New Issue
Open
opened 2026-09-07 16:51:00 +00:00 by JMR-dev · 0 comments
JMR-dev commented 2026-09-07 16:51:00 +00:00 (Migrated from github.com)
Copy Link
Copy Source

Found by the union coverage read of 2026-09-07 (E9 in docs/e2e-read-findings.md), which
merged the JVM exec with the API 34 instrumented .ec against one set of class files. These are
arms that neither suite takes, on lines both suites fully execute.

The sites

MediaProbe.containerFrom — the when over demuxer names, one missed arm each:

MediaProbe.kt:303   "matroska" in names || "webm" in names
MediaProbe.kt:305   "mp4" in names
MediaProbe.kt:306   "mov" in names || "qt" in names
MediaProbe.kt:309   "asf" in names || "asf_o" in names

Why this is a read and not simply a test

names is info.getFormat().split(','), and ffprobe reports a demuxer group, not one name —
"mov,mp4,m4a,3gp,3g2,mj2" for the MP4 family, "matroska,webm" for Matroska. In an || the
second half is only evaluated when the first is absent. If ffprobe never emits qt without mov,
or webm without matroska, then that half is dead by construction and is F6-shaped, not a
fixture gap.

Determine it per site. Do not assume the answer is the same for all four: :305 is a bare
membership test with no || at all, so its missed arm is a different shape from the others'.

The related one just outside the filter

MediaProbe.kt:312 — "aac" in names || "adts" in names. The only AAC fixture in the repo is
app/src/androidTest/assets/sample_aac.m4a, which is AAC-in-M4A: ffprobe reports the MP4
demuxer group for it, so it matches :305 and never reaches :312 at all. There is no raw
ADTS file anywhere under app/src. That one looks like a genuine fixture gap rather than a
construction artefact, and it is the reason this ticket exists rather than being folded into an
F-entry.

Acceptance

Per site, one of:

  • a fixture and a test whose named mutation goes red — e.g. for :312, point the AAC_ADTS
    arm at Container.MP3 and the test must fail; or
  • an entry in docs/coverage-read-findings.md recording which alias cannot occur without its
    primary, with the ffprobe output that shows it.

CLAUDE.md's rule applies: a green mutation is only evidence when the mutation is a real change.

Found by the **union** coverage read of 2026-09-07 (E9 in `docs/e2e-read-findings.md`), which merged the JVM exec with the API 34 instrumented `.ec` against one set of class files. These are arms that **neither** suite takes, on lines both suites fully execute. ## The sites `MediaProbe.containerFrom` — the `when` over demuxer names, one missed arm each: ``` MediaProbe.kt:303 "matroska" in names || "webm" in names MediaProbe.kt:305 "mp4" in names MediaProbe.kt:306 "mov" in names || "qt" in names MediaProbe.kt:309 "asf" in names || "asf_o" in names ``` ## Why this is a read and not simply a test `names` is `info.getFormat().split(',')`, and ffprobe reports a **demuxer group**, not one name — `"mov,mp4,m4a,3gp,3g2,mj2"` for the MP4 family, `"matroska,webm"` for Matroska. In an `||` the second half is only evaluated when the first is absent. If ffprobe never emits `qt` without `mov`, or `webm` without `matroska`, then that half is **dead by construction** and is F6-shaped, not a fixture gap. Determine it per site. Do not assume the answer is the same for all four: `:305` is a bare membership test with no `||` at all, so its missed arm is a different shape from the others'. ## The related one just outside the filter `MediaProbe.kt:312` — `"aac" in names || "adts" in names`. The only AAC fixture in the repo is `app/src/androidTest/assets/sample_aac.m4a`, which is **AAC-in-M4A**: ffprobe reports the MP4 demuxer group for it, so it matches `:305` and never reaches `:312` at all. There is no raw ADTS file anywhere under `app/src`. That one looks like a genuine fixture gap rather than a construction artefact, and it is the reason this ticket exists rather than being folded into an F-entry. ## Acceptance Per site, one of: - a fixture and a test whose **named mutation goes red** — e.g. for `:312`, point the `AAC_ADTS` arm at `Container.MP3` and the test must fail; or - an entry in `docs/coverage-read-findings.md` recording which alias cannot occur without its primary, with the ffprobe output that shows it. `CLAUDE.md`'s rule applies: a green mutation is only evidence when the mutation is a real change.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
above-cut
Worked autonomously overnight: local, JVM-verifiable, no product decision
 accessibility
Barrier affecting people with disabilities
 backlog
Held for manual review: product/UX call, CI/workflow, hardware, or unverifiable here
 bug
Something isn't working
 confirmed
Reviewer demonstrated the defect
 documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 plausible
Reviewer could not fully demonstrate it; treat as unproven
 question
Further information is requested
 sev:high
High severity
 sev:low
Low severity
 sev:medium
Medium severity
 wontfix
This will not be worked on
No labels bug
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
JMR-dev
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: JMR-dev/LibreMediaConverter#262