Playback: characterize byte-range LL-HLS over CMAF/fMP4 fatal load failure and upstream fix path

[MrFr3di]

Objective

Track the known Media3 failure for byte-range LL-HLS delivery over CMAF/fMP4 media and remove the characterization once a stable Media3 release carries the upstream fix.

CMAF/fMP4 and LL-HLS are not alternatives here: CMAF/fMP4 is the media packaging; LL-HLS is the HLS delivery/signaling path. MuxTV must accept provider-supplied HLS/LL-HLS independently of Apple TV support.

Failure family

The deterministic fixture uses:

• local MockWebServer only;
• MuxTV's real PlaybackMediaSourceFactory / MuxTvHttpClients / HlsMediaSource / ExoPlayer path;
• exact AndroidX CMAF audio_init.mp4 test data;
• the first 512 bytes of AndroidX CMAF audio_2.m4s exposed as #EXT-X-PART ... BYTERANGE="512@0";
• assertions on the fatal DataSpec.subrange -> HlsMediaChunk.feedDataToExtractor cause chain and the single Range: bytes=0-511 request.

Affected flow:

LL-HLS EXT-X-PART + BYTERANGE -> bounded CMAF/fMP4 DataSpec fully consumed -> nextLoadPosition == dataSpec.length -> retry -> zero-length DataSpec.subrange(...) -> IllegalArgumentException -> fatal source error.

This is an upstream Media3 loader behavior, not a CMAF-format rejection and not an Apple-specific MuxTV architecture choice.

Landed characterization

Merged PR #274 landed the characterization on main as merge commit:

a8350d4752a987e8280f0e823884b53bebbee30c

The merge contains only the Android instrumentation characterization plus scoped Apache-2.0 attribution for AndroidX test-data bytes; no production HLS/parser/player behavior changed.

Terminology-only follow-up PR #276 renames/comments the test explicitly as LL-HLS-over-CMAF/fMP4 while preserving the same fixture bytes and assertions.

Exact 1.10.1 / 1.11.0 attribution

The identical characterization blob ea206954db072da8cd9370faccf35ffe9f783d59 reproduced the same fatal signature on:

• Media3 1.10.1 control, evidence-only PR test(evidence): reproduce LL-HLS failure on Media3 1.10.1 #271;
• Media3 1.11.0 merge-candidate head used for test(playback): characterize byte-range LL-HLS failure #274.

API26/API36 evidence succeeded on both version lines. Therefore the defect is pre-existing across 1.10.1 -> 1.11.0; it was not introduced by the dependency upgrade.

Upstream status

• upstream issue: HLS: fatal IllegalArgumentException in HlsMediaChunk.feedDataToExtractor when a byte-range EXT-X-PART chunk is re-loaded after full consumption androidx/media#3350
• AndroidX main fix commit: 6bb2737e5f07907611f587f8f9f9b43853eb0ebc — Propagate EOF as ParserException for an HLS media chunk fully loaded;
• checked 2026-09-01: stable Media3 1.11.0 does not contain the fix.

Workaround policy

No MuxTV parser workaround is currently justified. Do not strip LL-HLS tags, disable LL-HLS, change player ownership, or alter buffer/cache/network policy merely to mask this upstream defect.

If real provider impact ever requires an app-side fallback before the fixed stable Media3 exists, it must first prove ordinary HLS, EXT-X-SKIP, complete-segment fallback, security/header ownership and secret-redaction behavior.

Acceptance / remaining gate

• sanitized CMAF/fMP4 fixture reproduces the byte-range LL-HLS failure through MuxTV's real HLS path;
• identical-fixture 1.10.1 vs 1.11.0 attribution recorded;
• API26/API36 evidence exists for both version lines;
• no live third-party URL required;
• no production workaround landed;
• characterization merged to main;
• first stable Media3 carrying the upstream fix is available;
• dependency is upgraded through its normal owner;
• characterization is inverted/updated to prove corrected behavior;
• exact-head Hosted Full + API26/API36 evidence is green on the fixed stable version.

Keep this issue open only as that upstream stable-fix watch. Close it without an app-side parser fallback if the released Media3 fix resolves the fixture.

Related: #186, #179.

[MrFr3di]

Upstream status checked on 2026-08-31:

• AndroidX main contains fix commit 6bb2737e5f07907611f587f8f9f9b43853eb0ebc (2026-07-31), Propagate EOF as ParserException for an HLS media chunk fully loaded, explicitly referencing HLS: fatal IllegalArgumentException in HlsMediaChunk.feedDataToExtractor when a byte-range EXT-X-PART chunk is re-loaded after full consumption androidx/media#3350. The change prevents retrying a fully-consumed/corrupted bounded HLS chunk.
• The current Media3 release branch / stable 1.11.0 source still has the old EOF propagation path and therefore does not contain that fix.
• This confirms Playback: characterize byte-range LL-HLS over CMAF/fMP4 fatal load failure and upstream fix path #264 remains a real compatibility follow-up, while also confirming it is pre-existing relative to MuxTV's accepted 1.10.1 baseline and should not be patched opportunistically in chore(deps): upgrade Media3 to 1.11.0 #263.

Implementation preference remains: reproduce with a sanitized MuxTV fixture first, then consume the first stable Media3 release containing the upstream fix if practical before considering an app-side parser fallback.

[MrFr3di]

Implementation started — deterministic RED slice

Draft PR #266 (test/ll-hls-byte-range-regression) now carries the first evidence slice from accepted main@ec16787de24a61ba94afeb6432c10b8880d65f85 / Media3 1.10.1.

The test is intentionally test-only and does not add a production workaround. It uses a local MockWebServer, MuxTV's real PlaybackMediaSourceFactory / MuxTvHttpClients HLS path and Apache-2.0 AndroidX CMAF fixture bytes. The synthetic live playlist exposes a truncated CMAF part as #EXT-X-PART ... BYTERANGE="512@0".

RED is accepted only if the instrumentation run proves the real part request reached the origin as Range: bytes=0-511 and the failure is the known exhausted-chunk IllegalArgumentException path rather than a fixture/compile/setup failure. If that exact RED is reproduced, the same test will be carried unchanged to the accepted Media3 1.11.0 baseline after #263 lands for attribution.

Upstream fix reference remains AndroidX commit 6bb2737e5f07907611f587f8f9f9b43853eb0ebc; current stable 1.11.0 does not contain it.

[MrFr3di]

A/B characterization complete

The same LlHlsByteRangeCharacterizationTest.kt blob (ea206954db072da8cd9370faccf35ffe9f783d59) now has exact-head device evidence on both Media3 lines:

• 1.11.0 — PR test(playback): characterize byte-range LL-HLS failure #267 head 140575a8cbded35676502e8e87fff4156f2fd4f5: Hosted Full #1966, focused API36 #371, and product matrix #464 (API26 + API36) all green.
• 1.10.1 control — closed evidence PR test(evidence): reproduce LL-HLS failure on Media3 1.10.1 #271 head 723a855b95b2189320c6226b08045ab488f543c0: focused API36 #372 and product matrix #465 (API26 + API36) green.

The test passes only when the known fatal DataSpec.subrange / HlsMediaChunk.feedDataToExtractor signature and single bounded media request are observed. Therefore the defect is reproduced identically before and after the Media3 1.11.0 update and is not attributable to that upgrade.

As of 2026-09-01, official Media3 release notes still list 1.11.0 as latest stable; upstream fix commit 6bb2737e5f07907611f587f8f9f9b43853eb0ebc remains the preferred remediation path once released. No MuxTV parser workaround is being introduced.

[MrFr3di]

Characterization merge-candidate evidence

Current characterization branch has been rebuilt on the current main and fully re-verified.

Exact base: main@37d485aa429f709256cde1ebd388965287f9a24b.
Exact head: 0f01786cb66e10f58e5bd5194a00f52d267bd571.

Diff remains bounded to two test-scope files: the unchanged LL-HLS characterization test blob ea206954db072da8cd9370faccf35ffe9f783d59 plus a scoped Apache-2.0 attribution/license copy for the AndroidX test-data bytes. No production playback/network/dependency code changed.

GREEN on this exact head:

• Hosted CI contract fix(sources): gate Android 17 local-network preparation #261 / 33468901232;
• Media3 lint docs: synchronize Player evidence and next variance phase #58 / 33468901242;
• App TV lint refactor(player): invert feature dependencies behind stable playback ports #216 / 33468901297;
• Focused API36 #375 / 33468901236;
• Product matrix #467 / 33468901231: API26 success, API36 success, aggregate gate success;
• Hosted Full #1971 / 33468901246.

The same test blob was already run on the Media3 1.10.1 control in closed PR #271 and reproduced the same known fatal signature on API26/API36. This establishes the defect as pre-existing across 1.10.1 -> 1.11.0, not an upgrade regression.

No app-side workaround is introduced. The remaining #264 gate is upstream: adopt the first stable Media3 release carrying fix 6bb2737e5f07907611f587f8f9f9b43853eb0ebc (or released equivalent), then invert/update this characterization to the corrected behavior and re-run exact-head evidence.

[MrFr3di]

Merged characterization into main via PR #274.

Merge commit: a8350d4752a987e8280f0e823884b53bebbee30c.
Merged head: 0f01786cb66e10f58e5bd5194a00f52d267bd571.

The merged change is still test-only: deterministic LL-HLS byte-range characterization plus scoped Apache-2.0 attribution for AndroidX CMAF test-data. No MuxTV production playback workaround was added.

The implementation/evidence phase is therefore complete. #264 remains open only for the upstream release gate: detect the first stable Media3 release carrying fix 6bb2737e5f07907611f587f8f9f9b43853eb0ebc (or released equivalent), upgrade normally, invert/update this characterization to corrected behavior, and close the issue if exact-head Hosted Full + API26/API36 stay green.