DASH manifest has no UTCTiming element

What it means

Your MPD has type="dynamic" but declares no <UTCTiming> element. In live DASH, which segment is available right now is computed from wall-clock time relative to availabilityStartTime. UTCTiming tells the player where to get an authoritative clock; without it the player falls back to the device’s own clock.

Why it matters

Device clocks drift, and plenty of them are wrong by minutes. A viewer whose clock runs fast will request segments that do not exist yet and see 404s; one whose clock runs slow will sit further behind the live edge than intended, or fall outside the DVR window entirely. This is the classic "works on my machine, fails for 5% of viewers" live DASH bug, and it is invisible in testing because your own clock is usually correct.

How to fix it

1. 1.Add a <UTCTiming> element as a direct child of <MPD>, before the first <Period>.
2. 2.The widely supported scheme is urn:mpeg:dash:utc:http-iso:2014 with a value pointing at an ISO-8601 time endpoint, for example https://time.akamai.com/?iso.
3. 3.urn:mpeg:dash:utc:http-head:2014 is a good alternative: the player reads the Date header from a HEAD request, so your own CDN can serve it.
4. 4.Declare more than one UTCTiming element if you want a fallback; players try them in order.

Frequently asked questions

What does "DASH manifest has no UTCTiming element" mean?

Your MPD has type="dynamic" but declares no <UTCTiming> element. In live DASH, which segment is available right now is computed from wall-clock time relative to availabilityStartTime. UTCTiming tells the player where to get an authoritative clock; without it the player falls back to the device’s own clock.

Why does it matter?

Device clocks drift, and plenty of them are wrong by minutes. A viewer whose clock runs fast will request segments that do not exist yet and see 404s; one whose clock runs slow will sit further behind the live edge than intended, or fall outside the DVR window entirely. This is the classic "works on my machine, fails for 5% of viewers" live DASH bug, and it is invisible in testing because your own clock is usually correct.

How do I fix it?

1. Add a <UTCTiming> element as a direct child of <MPD>, before the first <Period>. 2. The widely supported scheme is urn:mpeg:dash:utc:http-iso:2014 with a value pointing at an ISO-8601 time endpoint, for example https://time.akamai.com/?iso. 3. urn:mpeg:dash:utc:http-head:2014 is a good alternative: the player reads the Date header from a HEAD request, so your own CDN can serve it. 4. Declare more than one UTCTiming element if you want a fallback; players try them in order.

How can I detect this automatically?

Paste your MPEG-DASH streaming URL into StreamTest's free DASH validator. It runs this check on every analysis, flags the finding, and links straight back to this page — no sign-up required.

Related DASH checks

• DASH availabilityStartTime is in the futureThe manifest claims the presentation starts later than the current time, so no segment is available yet and playback cannot begin.
• The DASH manifest is not well-formed XMLThe document could not be parsed as XML, so nothing else could be checked.
• The document has no MPD root elementThe XML parsed, but its root is not <MPD>, so it is not a DASH manifest.
• MPD declares no profileWithout @profiles a player cannot tell which DASH feature set the manifest expects.
• MPD declares no minBufferTimePlayers use this required attribute to size the initial buffer before starting playback.
• MPD contains no periodsThere is no <Period>, so the manifest describes no content at all.