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

MediaProbe never probes a second audio track, so the guard that makes 'first track wins' true is unasserted #263

New Issue
Open
opened 2026-09-07 16:51:04 +00:00 by JMR-dev · 0 comments
JMR-dev commented 2026-09-07 16:51:04 +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) — an arm
neither the JVM suite nor the instrumented suite takes, on a line both fully execute.

MediaProbe.kt:386   } else if (mime.startsWith("audio/") && audio == null) {

The missed arm is audio != null — a file whose second (or later) audio track is offered to
this branch after the first has already been recorded. Every fixture under app/src/androidTest/assets
carries at most one audio track, so the guard has never had to refuse anything.

Why it is worth closing rather than exempting

The guard is what makes "first audio track wins" true. Without it the last track would win, and
nothing in either suite would notice — this is the HardwareFallbackTest shape from E1: an
assertion that passes because its premise never arises.

Note the neighbouring video branch at :380-385 has the same structure and the same question;
check whether it is in the same position before closing this.

Acceptance

A fixture with two audio tracks (ffmpeg -i a.wav -i b.wav -map 0:a -map 1:a -c:a aac two_audio.mp4
or similar, added under app/src/androidTest/assets with its provenance recorded the way the other
fixtures are).

Mutation that must go red: delete && audio == null. The probe then reports the second
track's codec, so a test asserting the first track's codec fails. Assert the codec, not merely that
some audio was found — the latter is true either way.

Found by the union coverage read of 2026-09-07 (E9 in `docs/e2e-read-findings.md`) — an arm neither the JVM suite nor the instrumented suite takes, on a line both fully execute. ``` MediaProbe.kt:386 } else if (mime.startsWith("audio/") && audio == null) { ``` The missed arm is **`audio != null`** — a file whose second (or later) audio track is offered to this branch after the first has already been recorded. Every fixture under `app/src/androidTest/assets` carries at most one audio track, so the guard has never had to refuse anything. ## Why it is worth closing rather than exempting The guard is what makes "first audio track wins" true. Without it the **last** track would win, and nothing in either suite would notice — this is the `HardwareFallbackTest` shape from E1: an assertion that passes because its premise never arises. Note the neighbouring video branch at `:380-385` has the same structure and the same question; check whether it is in the same position before closing this. ## Acceptance A fixture with two audio tracks (`ffmpeg -i a.wav -i b.wav -map 0:a -map 1:a -c:a aac two_audio.mp4` or similar, added under `app/src/androidTest/assets` with its provenance recorded the way the other fixtures are). **Mutation that must go red:** delete `&& audio == null`. The probe then reports the *second* track's codec, so a test asserting the first track's codec fails. Assert the codec, not merely that some audio was found — the latter is true either way.
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#263