Seeking not working as expected on certain multi period DASH streams in 4.4.x

[littlespex]

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

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

N/A

What version of Shaka Player are you using?

4.4.2. This issue does not occur in 4.3.12.

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?
Both

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

What browser and OS are you using?
Chrome 117.0.5938.62, Safari 16.6 (18615.3.12.11.2), MacOS Ventura 13.5.2 (22G91)

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
N/A

What are the manifest and license server URIs?

Sent via email

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

Default

What did you do?

1. Load the stream
2. Once playback begins, seek somewhere in the middle of the stream (most noticeable when seeking to a different period)

What did you expect to happen?
The player jumps to the new playhead time, starts loading segments starting at the new playhead time and begins playback.

What actually happened?

The player loads all segments between the original playhead time and the seek time resulting in a long "buffering" period before playback resumes.

seek_issue_4.4.x.mp4

[avelad]

@littlespex are you interested on send a PR to fix it?

[littlespex]

We are still trying to find the root cause of the issue. Any thoughts?

[littlespex]

Update: The issue was introduced in commit f1c5a1c

@joeyparrish Any thoughts as to why this change would result in the player loading all segments between the current playhead time and the seek time?

[littlespex]

The segment iterator is not returning the correct initial value, and the update_ function has to tick through all the interim values before finding the correct segment. Adding the following code at the end of StreamingEngine's getSegmentReferenceNeeded_ function fixes the issue, but seems dangerous:

      while (mediaState.segmentIterator && presentationTime > ref.endTime) {
        ref = mediaState.segmentIterator.next().value;
      }

[koenoe]

This issue is still happening for us, we don't have it in 4.3.x, but we do in 4.4.x and 4.5.x