Player enters endless seeking state when setting currentTime() to duration()

[dsine-de]

Description

If I set the currentTime() of a player to the duration() to go to the end of a HLS video, the player shows the seeking spinner endlessly.

Reduced test case

https://codepen.io/phelaz/pen/ZENzWNo

Steps to reproduce

1. Open the test case CodePen (e.g. Firefox because Edge/Chromium browsers sometimes show MEDIA_ERR_DECODE errors)
2. Wait for the loadeddata event to enable the "Go to end" button
3. Press the "Go to end" button (this sets the currentTime() to the duration() return value)
4. The player shows the loading spinner but is unable to show a frame

Errors

No response

What version of Video.js are you using?

8.12.0

Video.js plugins used.

No response

What browser(s) including version(s) does this occur with?

Edge 124.0.2478.80, Firefox 125.0.3

What OS(es) and version(s) does this occur with?

Windows 11

[welcome[bot]]

👋 Thanks for opening your first issue here! 👋

If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can. To help make it easier for us to investigate your issue, please follow the contributing guidelines.

[mister-ben]

This reproduces from Video.js 8.11.8 with VHS 3.12.0. 8.11.4/3.11.2 and below are OK. Possibly an effect of #1489. On 8.11.4 and below logging player.duration() on durationchange events, you see the duration drops to 733.999999 from 734 on the seek

[mike-capyh]

We're running into (I think?) the same issue. It is also an infinite spinner on seek, and also resolved by downgrading VHS to 3.11.2 (by downgrading video.js from 8.17.3 to 8.11.4).

Our tests used VOD manifests with separate main and audio playlists. The segment timings between the two are mostly aligned, but not down to the millisecond.

Some of our observations so far:

• It can happen during seek or regular playback, with/without browser caching disabled (although seek seems to trigger it more consistently).
• During the infinite spinner, a tracepoint on the call to fixBadTimelineChange in hasEnoughInfoToAppend_ will get hammered repeatedly; as far as I could tell, relevant state was stuck at the same values after each fixBad cycle.
• An example of pendingTimelineChanges during such a stuck state shows main and audio trying to go in opposite directions:

  >>> this.timelineChangeController_.pendingTimelineChanges_.main
  Object { type: "main", from: 13, to: 12 }
  >>> this.timelineChangeController_.pendingTimelineChanges_.audio
  Object { type: "audio", from: 13, to: 14 }

• Setting a break on the shouldFixBadTimelineChanges call and manually doctoring the audio values to match the video values will unjam the loop and allow playback to get at least a little bit farther.

We eventually tried version 3.15.0 (video.js version 8.19.1). The infinite spinner does still sometimes happen, but is much rarer, and manual re-seek usually unjams it. Playback still feels somewhat less reliable than in 3.11.2 though.