Repository navigation
Live multi-period DASH: playback stalls after SCTE crash-out (operator early ad end) #3252
Description
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
- Build Media3 demo app from 1.6.1 (or current release) with
EventLoggerenabled. - Use a live multi-period DASH stream with SCTE-35 in MPD EventStream (Ateme packager, client-side ad insertion / CSAI).
- Do not attach any ad SDK or metadata-driven ad logic.
Normal path (control — passes) - Play through a full scheduled mid-roll: cue-out → ad period → cue-in.
- Observe smooth ad→content transition (post-Stream/App freeze in DASH Multi-Period Live-Stream #1698 behavior).
Crash-out path (fails) - During an active mid-roll, trigger operator crash-out (early ad end / SCTE early return).
- 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
- Penultimate period gets finite
- 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=1Event@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
positionDiscontinuitywithAUTO_TRANSITION(or equivalent forward progress), - Continue loading segments and playing without multi-minute freeze.
Actual result
After crash-out:
- Brief playback (~4–5 s) then freeze for ~30–90 s (on our app) or
StuckPlayerExceptionat ~83 s (sample app). EventLoggershowsperiod=0whileperiodCount=2or3for the entire stall window.- Tail period logged as
period [?](open / unset duration). - No
AUTO_TRANSITIONduring stall. - Recovery only when live window evicts head period:
positionDiscontinuityreason=REMOVE, e.g.period 0→1, large position jump. - 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 bugreportto android-media-github@google.com after filing this issue.
Activity
marcbaechinger commentedon Jun 3, 2026
Thanks for your report.
I understand you are playing a DASH live stream that emits SCTE metadata.
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-outin 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
EventLoggerto 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 commentedon Jun 4, 2026
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 commentedon Jun 4, 2026
Thanks! I will plan for that. What timezone are you in?
ajeetfancode commentedon Jun 4, 2026
I am in IST
google-oss-bot commentedon Jun 23, 2026
Hey @ajeetfancode. We need more information to resolve this issue but there hasn't been an update in 14 weekdays. I'm marking the issue as stale and if there are no new updates in the next 7 days I will close it automatically.
If you have more information that will help us get to the bottom of this, just add a comment!
google-oss-bot commentedon Jul 1, 2026
Since there haven't been any recent updates here, I am going to close this issue.
@ajeetfancode if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.