Twelve lines below, the samples property KDoc — on get() = context.filesDir — says:
Internal storage, not the external files dir. Files placed in the external dir by adb push or adb shell cp stay owned by the shell user, and the app then gets EACCES trying to read them — which presents as an unparseable input rather than a permission problem.
Different directories, and the second exists specifically to explain why the first fails. Anyone following the class KDoc stages files the benchmark can't read, gets a skip, and reads the skip as "not staged yet" — walking into the exact failure the property KDoc warns about, guided by the instruction in the same file.
The fix is not a corrected command
Restating the mechanism in a second place is what let these drift, and a replacement command I hadn't executed would be the same defect with a fresher date. The class KDoc now names [samples] as the single place that answers it.
Two things added because they're checkable rather than remembered:
The exact filenames, via [H264_SAMPLE] and [AV1_SAMPLE]. The old text said <file>.mp4, so even the right directory left you guessing.
A note that the two skips every green E2E leg reports are these.
Not claimed
That the benchmark misbehaves on CI. An earlier version of this ticket said so; it was wrong, and measuring settled it — both tests report SKIPPED on the gating legs, the guards work, and "harmless in CI" is accurate. The failure that prompted the look is Media3EngineTest, tracked as #102.
Closes #101.
The class KDoc said:
> Populate with: `adb push <file>.mp4 /sdcard/Android/data/org.libremediaconverter/files/`
Twelve lines below, the `samples` property KDoc — on `get() = context.filesDir` — says:
> **Internal storage, not the external files dir.** Files placed in the external dir by `adb push` or `adb shell cp` stay owned by the shell user, and the app then gets EACCES trying to read them — which presents as **an unparseable input rather than a permission problem**.
Different directories, and the second exists specifically to explain why the first fails. Anyone following the class KDoc stages files the benchmark can't read, gets a skip, and reads the skip as *"not staged yet"* — walking into the exact failure the property KDoc warns about, guided by the instruction in the same file.
## The fix is not a corrected command
**Restating the mechanism in a second place is what let these drift**, and a replacement command I hadn't executed would be the same defect with a fresher date. The class KDoc now names `[samples]` as the single place that answers it.
Two things added because they're checkable rather than remembered:
- **The exact filenames**, via `[H264_SAMPLE]` and `[AV1_SAMPLE]`. The old text said `<file>.mp4`, so even the right directory left you guessing.
- A note that the two skips every green E2E leg reports **are these**.
## Not claimed
That the benchmark misbehaves on CI. An earlier version of this ticket said so; **it was wrong**, and measuring settled it — both tests report `SKIPPED` on the gating legs, the guards work, and *"harmless in CI"* is accurate. The failure that prompted the look is `Media3EngineTest`, tracked as **#102**.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #101.
The class KDoc said:
Twelve lines below, the
samplesproperty KDoc — onget() = context.filesDir— says:Different directories, and the second exists specifically to explain why the first fails. Anyone following the class KDoc stages files the benchmark can't read, gets a skip, and reads the skip as "not staged yet" — walking into the exact failure the property KDoc warns about, guided by the instruction in the same file.
The fix is not a corrected command
Restating the mechanism in a second place is what let these drift, and a replacement command I hadn't executed would be the same defect with a fresher date. The class KDoc now names
[samples]as the single place that answers it.Two things added because they're checkable rather than remembered:
[H264_SAMPLE]and[AV1_SAMPLE]. The old text said<file>.mp4, so even the right directory left you guessing.Not claimed
That the benchmark misbehaves on CI. An earlier version of this ticket said so; it was wrong, and measuring settled it — both tests report
SKIPPEDon the gating legs, the guards work, and "harmless in CI" is accurate. The failure that prompted the look isMedia3EngineTest, tracked as #102.