Repeated initial segment load & cancellations

[grabofus]

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

If the problem is related to FairPlay, have you read the tutorial?
Not related

What version of Shaka Player are you using?
4.10.9

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

Can you reproduce the issue with the latest code from main?
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 / Windows

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
Reproduced on webOS 4

What are the manifest and license server URIs?
VOD:
https://sample-videos-zyrkp2nj.s3-eu-west-1.amazonaws.com/big-buck-bunny/dash/master.mpd
Live:
https://livesim2.dashif.org/livesim2/testpic_2s/Manifest.mpd

What configuration are you using? What is the output of player.getConfiguration()?
Default config

JSON.stringify(player.getNonDefaultConfiguration(), null, 2)
> '{}'

What did you do?

• Added & selected a custom Network Throttling Profile to Chrome with 500ms latency
  • Not necessary, but makes reproduction consistent
• Load VOD/Live DASH stream to the player
• On loadedmetadata seek to 50s (or Date.now() / 1000 - 50 for live)
  • Do not use second parameter of player.load(url, startPos), the issue doesn't happen that way

Reproduction demo:
https://sample-videos-zyrkp2nj.s3.eu-west-1.amazonaws.com/20240809_shaka_start_issue/index.html

What did you expect to happen?
Player should seek to 50s, and start playback with the least amount of requests possible.

What actually happened?
The player requested 9.m4s 10 times, cancelling all but the last request.

Due to a race-condition VideoWrapper.PlayheadMover.moveTo can be called with the target time equaling the origin time. The onTick_ function only considers seek successful if the currentTime changed from originTime but doesn't take into account whether it was expected to change in the first place.

Are you planning send a PR to fix it?
Yes