Playback fails with: cannot find segment: currentPeriod.startTime=0

[madsva]

Have you read the FAQ and checked for duplicate open issues?: Yes

What version of Shaka Player are you using?: 2.3.7

Can you reproduce the issue with our latest release version?: Yes

Can you reproduce the issue with the latest code from master?: Yes

Are you using the demo app or your own custom app?: Custom app

If custom app, can you reproduce the issue using our demo app?: No, the stream runs on http, not https, however, it can be reproduced using the https://shaka-player-demo.appspot.com/docs/api/tutorial-basic-usage.html app running locally and on chromecast devices (running in non-published mode)

What browser and OS are you using?: Chrome, Mac OS High Sierra

What are the manifest and license server URIs?: Everything mailed to [email protected]

What did you do? Tried to playback the DASH stream

What did you expect to happen? Playback would start

What actually happened?
Got the following message in the console:
streaming_engine.js:1359 (audio:9) looking up segment: presentationTime=1528977027.4810002 currentPeriod.startTime=0
streaming_engine.js:1368 (audio:9) cannot find segment: currentPeriod.startTime=0 lookupTime=1528977027.4810002
streaming_engine.js:1359 (video:1) looking up segment: presentationTime=1528977027.4810002 currentPeriod.startTime=0
streaming_engine.js:1368 (video:1) cannot find segment: currentPeriod.startTime=0 lookupTime=1528977027.4810002

[TheModMaker]

Sorry for the delay. The manifest URL you sent us is giving us 404 errors. Could you send us an updated URL?

[madsva]

No problems :-)

I've requested an public clear stream that does not time out from the customer. I will get back regarding this. One note: I've tried to modify the availabilityStartTime through a proxy to now() (instead of 1970...) and it actually started playback, though with a lot of jitter/hick-ups (or whatever you would call it).

I'll get back as soon as I've got a stream available.

Thanks.

[madsva]

I've sent a mail with a public clear stream.

[TheModMaker]

Your stream is not setting availabilityStartTime correctly. This time represents the wall-clock time that the presentation starts at (presentation time 0). So when I fetched the manifest at 2018-06-20 19:40:52, the availabilityStartTime was 1970-01-01 00:00:00, so that makes the current presentation time 17702 days, 19:40:42.

But the segments don't align with that. The segment list starts at 83890000000 and ends at 84010000000. With a timescale of 10000000, that means the segments represent the presentation time range of 2:19:49 - 2:20:05. So your segments are 17702 days in the past.

You need to update the availabilityStartTime to match the correct start time. You could also use Period@start to do the same thing. Note that after #999, we will be able to play this content; but your content is against the spec, so other players may not be able to play it.

Also note that your timeShiftBufferDepth is 16 seconds. That is extremely small and makes the seek window hard to stay in. If it takes a bit to download the next segment, we will fall outside that window and need to seek to get back in the window. That is probably why you are seeing the hick-ups; setting a larger time-shift window would give us more room to play in and avoid seeking to stay in the window.

[madsva]

Thank you - much appreciated!

We'll try to adjust the manifest based on your finding and recommendations.

One last thing: what about the UTCTiming element (this is missing as well) - is this recommended practise to add this or is it okay to leave out?

[TheModMaker]

It is highly recommended to include a UTCTiming element. It is not strictly required, but not including it can cause clock-sync issues which can make us unable to find the segment. If the server and client clocks are different by a large amount, we will calculate the incorrect "current time" and we may try to play segments that no longer exist (or don't exist yet).

[madsva]

All right - we'll make sure the UTCTiming element is added as well.

Regarding the timeShiftBufferDepth - what is the recommended size for this value?

[TheModMaker]

Thinking about this more, 16 seconds is probably fine. We use 3 seconds for the non-seekable HLS streams.

But note that your manifest doesn't have a suggestedPresentationDelay attribute, so we will assign a default value of 10 seconds. This means that we will play 10 seconds from the live edge since the segments at the live edge don't exist yet. If we play too close to the live edge, we might not be able to fetch segments, so we will stall and fall backwards. So we play a bit behind it so the segments are available. Since you have a 16 second window, that means that the seek window will only be 6 seconds long.

[shaka-bot]

Closing due to inactivity. If this is still an issue for you or if you have further questions, you can ask us to reopen or have the bot reopen it by including @shaka-bot reopen in a comment.