Live multi-period DASH: playback stalls after SCTE crash-out (operator early ad end)

[ajeetfancode]

Version

Media3 1.10.1

More version details

Also reproduced on Media3 sample/demo app (same version family).

Devices that reproduce the issue

Not device-specific; observed across multiple Android versions

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Yes

Reproduction steps

Setup

1. Build Media3 demo app from 1.6.1 (or current release) with EventLogger enabled.
2. Use a live multi-period DASH stream with SCTE-35 in MPD EventStream (Ateme packager, client-side ad insertion / CSAI).
3. Do not attach any ad SDK or metadata-driven ad logic.
   Normal path (control — passes)
4. Play through a full scheduled mid-roll: cue-out → ad period → cue-in.
5. Observe smooth ad→content transition (post-Stream/App freeze in DASH Multi-Period Live-Stream #1698 behavior).
   Crash-out path (fails)
6. During an active mid-roll, trigger operator crash-out (early ad end / SCTE early return).
7. Observe MPD update sequence:
   • Penultimate period gets finite @duration (good, DASH-IF §13.6.3)
   • New open tail period is added (period [?])
   • Often a second crash-out update closes the short ad period and adds another open tail
8. Observe player behavior for 60–120 s.

MPD snapshots (crash-out sequence)

Captured from packager (Ateme, live CSAI). XML validates; fails Media3 interoperability on crash-out.

Snapshot	Period structure	Notes
mpd_0039	1 × open P58	Normal live tail
mpd_0040	P58 closed PT2M39.48S + open P59	Good: penultimate closure. Bad: P59 = new cue-out (out_of_network=1, Event@duration=1000 @ timescale 25 → ~40 s) instead of crash-out return
mpd_0045	P58 + P59 closed PT20.48S + open P60	Good: P59 closed; Good: return on P60 (out_of_network=0, no Event@duration) — but ~20 s late
Crash-out tail signaling (mpd_0040 / P59):

• out_of_network_indicator=1
• Event@duration="1000" → interpreted as ~39998 ms break
• Expected per DASH-IF IOP Part 5 §5.5.2: out_of_network=0 + immediate return or splice cancel — not a new full cue-out

Note: Shaka player is able to play the same dash stream with no issues

Expected result

After crash-out MPD update, ExoPlayer should:

• Hand off to the correct period within a few seconds, or
• Emit positionDiscontinuity with AUTO_TRANSITION (or equivalent forward progress),
• Continue loading segments and playing without multi-minute freeze.

Actual result

After crash-out:

1. Brief playback (~4–5 s) then freeze for ~30–90 s (on our app) or StuckPlayerException at ~83 s (sample app).
2. EventLogger shows period=0 while periodCount=2 or 3 for the entire stall window.
3. Tail period logged as period [?] (open / unset duration).
4. No AUTO_TRANSITION during stall.
5. Recovery only when live window evicts head period: positionDiscontinuity reason=REMOVE, e.g. period 0→1, large position jump.
6. Player does not report a clear onPlayerError() in all captures; UX is a silent stall.

Media

MPD files: DashWithCrashOut.zip

Bug Report

• You will email the zip file produced by adb bugreport to android-media-github@google.com after filing this issue.

[marcbaechinger]

Thanks for your report.

I understand you are playing a DASH live stream that emits SCTE metadata.

Do not attach any ad SDK or metadata-driven ad logic.

If I play a live DASH stream and I do not attach any SDK or metadata-driven ad logic, ExoPlayer emits the metadata to the metadata output and does not perform any ad insertion logic. It plays through the periods the DASH manifest rolls through.

An SCTE crash-out in such a scenario appears to me to be a server side inserted DASH period that contains segments that fail or stop to load for some reasons of the media or ExoPlayer.

From your detailed report it seems that you can reproduce this behavior. Can you provide us with a bug report of right after that happens? Ideally you add an EventLogger to the player as an analytics listener.

Obviously best would be if you can provide us with a URI so we can repro this ourselves and we would be able to verify a possible fix

If you're unable to share bug reports or test content publicly, please send them to android-media-github@google.com using a subject in the format "Issue #3252".

[ajeetfancode]

Hi @marcbaechinger
I can provide a live DASH stream for replication, but due to encoder resource constraints, we can only keep it running for a limited time for testing.
Whenever you are ready to investigate, please let me know on the email I have sent. I will spin up the encoders and provide the stream URL via email, which will remain active for 4 hours from that point.

[marcbaechinger]

Thanks! I will plan for that. What timezone are you in?

[ajeetfancode]

I am in IST