Repository navigation
Repeated live DASH Source errors: DashManifestParser ParserException contentIsMalformed dataType=4 #3418
Description
Media3 version
1.7.1 (androidx.media3:media3-exoplayer / media3-exoplayer-dash)
Devices that reproduce the issue
Samsung SM-S921B, Android 16
Devices that do not reproduce the issue
Not isolated to one OEM. Same ExoPlaybackException: Source error / DashManifestParser stack seen on other Android devices on this live DASH feed.
Reproducible in the demo app?
Cannot provide a public URL. Stream is authenticated live DASH (SSAI). Repro is: play live DASH for an extended period; MPD reload occasionally fails.
Reproduction steps
- Play a live DASH stream (
application/dash+xml/master.mpd). - Leave playback running (manifest refreshes).
- Observe repeated
TYPE_SOURCEfailures in one session (examples below: 19:05, 19:18, 20:07 on 2026-09-13).
Expected result
MPD refresh either succeeds, or a failed HTTP load is reported as an IO / HTTP error (HttpDataSourceException / response code) without DashManifestParser treating the payload as a malformed MPD.
Actual result
Repeated:
androidx.media3.exoplayer.ExoPlaybackException: Source error
Caused by: androidx.media3.common.ParserException:
inputStream does not contain a valid media presentation description
{contentIsMalformed=true, dataType=4}
at androidx.media3.exoplayer.dash.manifest.DashManifestParser.parse(DashManifestParser.java:124)
at androidx.media3.exoplayer.dash.manifest.DashManifestParser.parse(DashManifestParser.java:69)
at androidx.media3.exoplayer.upstream.ParsingLoadable.load(ParsingLoadable.java:185)
Same session, three times:
| Time | Load failure immediately before | Then Exo |
|---|---|---|
| 19:05:32 / 19:05:41 | HTTP 500 on .../DASH_ENC/master.mpd |
Source error + ParserException |
| 19:18:36 / 19:18:59 | HTTP 500 on master.mpd (other region) |
same |
| 20:06:16 / 20:07:13 | UnknownHostException for the MPD host |
same |
In another session, initialize GET on .../master.mpd returned HTTP 504, empty body (~6.4s); Exo still surfaced the same ParserException / contentIsMalformed=true / dataType=4 on the play MPD.
We do not have the response body for a 3002-after-HTTP-200 case. Bodies were not captured in logcat.
Question
Is contentIsMalformed=true / DashManifestParser.parse expected when:
- the MPD URL returns HTTP 500 (non-MPD or error body), or
- the body is empty (504), or
- DNS fails then a later parse runs?
If yes, we will treat this as working as designed and handle 5xx/empty at the data source. If not, we can recapture a Charles HAR with response.content when we next hit HTTP 200 + this exception.
Media
Redacted log + stub HAR (no PII, no full query string, no MPD XML — bodies were never logged):
media3-repeated-source-manifest-errors-redacted.logmedia3-mpd-http-500-redacted.har
Bug Report Checklist
- Searched existing issues for
DashManifestParser/contentIsMalformed/ Source error on live DASH - Media3 version listed
- Device listed
- Demo app (private live stream)
- Steps / expected / actual
- Stack traces (redacted log attached)
Activity
rahulkumar-viewlift commentedon Sep 18, 2026
Redacted attachments (PII stripped; no MPD XML — bodies were not captured in logcat):
https://gist.github.com/rahulkumar-viewlift/26128f22bbfd39f06aa7f1bd0ffdca3f
media3-repeated-source-manifest-errors-redacted.log— three Source/ParserExceptionstacks from one sessionmedia3-mpd-http-500-redacted.har— stub HAR for the HTTP 500 MPD loads (not a proxy capture)tonihei commentedon Oct 1, 2026
If I understand correctly, for as long as the DataSource returns bytes instead of trowing an exception, the parser will attempt to parse it as an MPD and then correctly reports it as malformed when whatever content it received is not a valid MPD.
Are you using a custom
DataSourceby any chance? Or if not, please specify which Media3 network stack you are using, as I think return codes like 500 would usually result in a different kind of reported error because the DataSource throws an exception instead of returning the error body from the failed HTTP request.