Jumping back in live stream before startup collapses seek window

[jkarsrud]

When seeking backward/jumping back in a live stream by setting video.currentTime, the seekrangechanged event fires as expected, with the start and end properties moving along correctly. After the seekrangechange event has triggered a couple of times, the end property is equal to the video element's currentTime.

This only happens in Chrome 45 on Windows 10, in Chrome 45 on OS X it works as exptected.

[tdrews]

Thanks for the report.

I'm not exactly sure I understand what you see: so, you seek back into the middle of the seek range, but then after some time passes, seek.end gets set to the current time, so you cannot seek back to the live-edge?

[jkarsrud]

Yes, that's correct.

A better example: When I start streaming I get a start of 5000 and end of ~11000 through the seekrangechanged event. If I set the currentTime to ~7000, the end will — after a few seconds — become ~7000 instead of the expected ~11000. So the live-edge seems to be moved back to where I seeked.

If I seek by using the scrubber, the seeking works as expected, with the live-edge staying where it's supposed to.

I haven't been able to figure out where in shaka-player this happens other than what events are fired, or if it might be an issue with the streaming server sending some data that's misinterpreted. I will keep digging to see if I can figure out why this happens.

[joeyparrish]

@jkarsrud We have been unable to reproduce on Windows 10 with Chrome beta (47). We have QA giving it another try with Chrome stable (46). Are you still seeing this issue?

[joeyparrish]

Unable to reproduce with Chrome 46, either.

[joeyparrish]

Since we can't reproduce, I'm removing this from the v1.6.0 milestone.