Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Playback does not start with certain precise seek ranges
See original GitHub issueHave you read the FAQ and checked for duplicate open issues? Yes
What version of Shaka Player are you using? 2.5.15
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
What browser and OS are you using? Chrome/Tizen OS
For embedded devices (smart TVs, etc.), what model and firmware version are you using? Model: UE40MU6100U, Firmware: T-KTMDEUC-1280.5, BT-S
What are the manifest and license server URIs? Private information
What did you do? Start playback of DASH VOD sample
What did you expect to happen? Playback should be success
What actually happened? Playback does not start. Many identical seek attempts at start. Full log here shaka.log.txt.
Suspicious piece of log:
Jumping forward 1.4586666666666666 seconds to catch up with the seek range.
Playhead before start & start is unbuffered
Seek to 1.458666
...
Jumping forward 6.666666665378074e-7 seconds to catch up with the seek range.
Playhead before start & start is unbuffered
Seek to 1.458666
On LG webOS, player seek to position 1.458667 and playback starts successfully:
Jumping forward 1.4586666666666666 seconds to catch up with the seek range.
Playhead in safe region or in buffered region.
Seek to 1.458667
I suspect that these platforms have different current time rounding policies.
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Correction: it’s not the limited precision of numbers, but rather the limited precision of video.currentTime. We compare that to a segment time with lots of digits, and seeking forward by < 1ms gets rounded down inside the browser. We can solve it by rounding up to the ms before we seek.
With the content provided, I can see this issue on desktop Chrome. It’s not specific to Tizen at all, though it does appear to be specific to the content. The limited precision of numbers in JS is causing things to go crazy.