The player should always re-process the MPD when availabilityStartTime reached.

[arikkrol1]

http://bitcdn-kronehit-live.bitmovin.com/mpds/stream.php?streamkey=bitcodin&segmenthost=bitcdn-kronehit-live.bitmovin.com&liveoffset=20

In the console the message 'The stream is not available yet' appears

[tdrews]

Thanks for the report.

The server seems to set the MPD's @availabilityStartTime to the current time, and the client's clock may be slightly behind this value. The player has a clock sync mechanism but it does not work unless the server sets the Access-Control-Expose-Headers HTTP header. The player will also fetch another MPD, with the delay specified by @minUpdatePeriod, when the stream is not available (or appears not to be available), but the MPD's @minUpdatePeriod is quite large in this case (and the server may just reset @availabilityStartTime anyways).

We'll investigate a solution.

[joeyparrish]

Here's what seems to be happening.

1. Your server changes availabilityStartTime to the current time every time the manifest is accessed. This does not make sense, and as far as I can tell, does not represent a real use-case. The availabilityStartTime should not constantly change in a real stream.

2. Your server doesn't allow us to access the Date header for clock synchronization. This means the availabilityStartTime may appear to be slightly in the future, which according to spec, means the stream is not yet available. Allowing cross-origin access to the Date header on your server would help.

3. Because minUpdatePeriod is huge (595 hours), we don't fetch a new manifest for 24 days. If we did, thanks to your constantly-changing availabilityStartTime and clock desync, we would still see that it is in the future and the stream would still not be available according to the spec.

4. The bug on our side is that we could wait for availabilityStartTime to pass and then reprocess the same manifest we already have. This would allow playback to continue once the delta between the client & server clocks has passed.

So we will add code to wait for availabilityStartTime to pass and reprocess the manifest, and we strongly recommend you both allow Date header access and do not constantly change availabilityStartTime.

Since this content does not appear to be realistic, I am pushing this out to a later milestone than the one we are currently working on.