Regression (4.10.12 => 4.11.1): Going backward/forward in a video doesn't go where it should

[awsms]

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

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

Can you reproduce the issue with the latest code from main?
If you're using the master on your demo website, then yes.

Are you using the demo app or your own custom app?
I found this issue in a custom app (FreeTube).

If custom app, can you reproduce the issue using our demo app?
Yes.

What browser and OS are you using?
EndeavourOS, and I'm using the Thorium web browser.

What did you do?

1. Go to the demo website.
2. Launch any demo video.
3. Wait around 20 seconds

4. Open the player controller of the browser, then go backward or forward:

What did you expect to happen?
To go at the correct timestamp (+5/-5 from the current playback time).

What actually happened?
If going backward, the video will restart at 0s. If going forward, the playback will be at exactly 5s.

Are you planning to send a PR to fix it?
No.

Cross-referencing the original issue I opened on FreeTube, it seems to not be reproducible on Windows:
FreeTubeApp/FreeTube#6004

[joeyparrish]

Can you reproduce the issue with the latest code from main?
If you're using the master on your demo website, then yes.

We are not. That is the latest release. Please try the nightly demo for the latest version:

https://nightly-dot-shaka-player-demo.appspot.com/

Please let us know how it works with the nightly.

Regression (4.10.12 => 4.11.1)

So 4.10.12 is okay, but 4.11.1 is not? Can you try later 4.10 releases? Can you try, say, 4.10.26? See also https://index-dot-shaka-player-demo.appspot.com/

If you can pin down the first bad release, a git bisect from there can pin down the exact commit that broke it.

[awsms]

Can you reproduce the issue with the latest code from main?
If you're using the master on your demo website, then yes.

We are not. That is the latest release. Please try the nightly demo for the latest version:

https://nightly-dot-shaka-player-demo.appspot.com/

Please let us know how it works with the nightly.

Thanks for the link! I'm able to reproduce the bug.

Regression (4.10.12 => 4.11.1)

So 4.10.12 is okay, but 4.11.1 is not? Can you try later 4.10 releases? Can you try, say, 4.10.26? See also https://index-dot-shaka-player-demo.appspot.com/

If you can pin down the first bad release, a git bisect from there can pin down the exact commit that broke it.

Yes that's it, I bisected FreeTube's commits to see from when this behavior started, and it was right back when the dependency bumped from 4.10.12 to 4.11.1. I will have a look later on to bisect shaka-player as well.

See also https://index-dot-shaka-player-demo.appspot.com/

I missed that website! I can confirm you it began to happen starting 4.11.0 exactly! It's not reproducible on the 4.10.26 website.

[joeyparrish]

If you are willing to bisect this in Shaka, that is very helpful! If you can reproduce in 4.10.26, then your bisect can exist in one branch only (4.10.12 - 4.10.26). If not, you can always bisect in the main branch by using 4.10.0 up to the latest commit. Let me know if you need any pointers on our 🦇💩 build system.

[awsms]

If you are willing to bisect this in Shaka, that is very helpful! If you can reproduce in 4.10.26, then your bisect can exist in one branch only (4.10.12 - 4.10.26). If not, you can always bisect in the main branch by using 4.10.0 up to the latest commit. Let me know if you need any pointers on our 🦇💩 build system.

Hi Joey, you probably missed my edit since you commented just a few seconds before I edited. The bug appeared exactly from the 4.11.0 release 😄
The bug was introduced in a commit from:
https://github.com/shaka-project/shaka-player/commits/v4.11.x/?before=e3d425fbcfd81bf9b3f2ce741fe2a60bf4810667+315
to
https://github.com/shaka-project/shaka-player/commits/v4.11.x/?after=e3d425fbcfd81bf9b3f2ce741fe2a60bf4810667+454

[absidue]

Likely to be related to #7188 as that added the media session management and the downstream app removed its media session handling during the upgrade. The downstream app previously operated directly on the video element when it received the seek events (currentTime +=/-=) but it looks like shaka-player operates on the seek bar instead. It is also possible that the problem is with the sending of the current position to the media session, so that it is seeking to where it thinks is correct based on the information it received but isn't actually where the user wants to go. I haven't looked into it too deeply yet though.

Snippet taken from the old downstream code:

case 'seekbackward':
  video_.currentTime -= (details.seekOffset || defaultSkipInterval.value)
  break
case 'seekforward':
  video_.currentTime += (details.seekOffset || defaultSkipInterval.value)
  break
case 'seekto': {
  const { start: seekRangeStart } = player.seekRange()

  if (details.fastSeek) {
    video_.fastSeek(seekRangeStart + details.seekTime)
  } else {
    video_.currentTime = seekRangeStart + details.seekTime
  }
  break
}

[awsms]

Hi, just to tell you that I'm still able to reproduce this bug on the nightly website!