DASH availabilityStartTime is in the future
The manifest claims the presentation starts later than the current time, so no segment is available yet and playback cannot begin.
What it means
availabilityStartTime is the anchor for every segment availability calculation in live DASH. We compared it against the origin’s own Date response header where one was available, and against this machine’s clock otherwise, and it is in the future.
Why it matters
Segment availability is derived forward from availabilityStartTime. If that anchor is ahead of now, every segment computes as "not yet available" and the player has nothing legal to request. Playback either never starts or starts and immediately stalls.
How to fix it
- Check the clock on the packager host — this is almost always NTP drift on the encoder or packager, not a manifest authoring mistake.
- Confirm availabilityStartTime is expressed in UTC with a trailing Z, not in local time without an offset.
- If the value is correct, verify the origin’s Date header: a wrong server clock produces the same symptom from the other direction.
Check your own stream
The free DASH validator runs this check on every analysis and links each finding straight back here.
Open the DASH validator →Frequently asked questions
- What does "DASH availabilityStartTime is in the future" mean?
- availabilityStartTime is the anchor for every segment availability calculation in live DASH. We compared it against the origin’s own Date response header where one was available, and against this machine’s clock otherwise, and it is in the future.
- Why does it matter?
- Segment availability is derived forward from availabilityStartTime. If that anchor is ahead of now, every segment computes as "not yet available" and the player has nothing legal to request. Playback either never starts or starts and immediately stalls.
- How do I fix it?
- 1. Check the clock on the packager host — this is almost always NTP drift on the encoder or packager, not a manifest authoring mistake. 2. Confirm availabilityStartTime is expressed in UTC with a trailing Z, not in local time without an offset. 3. If the value is correct, verify the origin’s Date header: a wrong server clock produces the same symptom from the other direction.
- Can a validator catch this before viewers do?
- Yes. The free DASH MPD validator checks this on every run, together with UTCTiming, clock drift and segment addressing — the live problems that only appear on other people's devices.
- What is the first thing to try?
- Check the clock on the packager host — this is almost always NTP drift on the encoder or packager, not a manifest authoring mistake.
Related DASH checks
- DASH manifest has no UTCTiming elementA live MPD without UTCTiming forces players to trust the device clock, so any skew on the viewer’s machine becomes stalls or missing segments.
- 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.