Segment delay is not applied after version upgrade.

[brodiddev]

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

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

yes

What version of Shaka Player are you using?

4.9.5

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

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

What browser and OS are you using?
window Chrome

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

What are the manifest and license server URIs?

https://global-media.com/live/brodi/master.m3u8

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

streaming: {
    bufferingGoal: 5,
    rebufferingGoal: 2,
    lowLatencyMode: true,
    useNativeHlsOnSafari: false,
    infiniteLiveStreamDuration: true,
  },
  manifest: {
    hls: {
      liveSegmentsDelay: 1.5,
      sequenceMode: false,
    },
  },
  abr: {
    enabled: false,
  },

What did you do?

I tested the first playback segment with both versions of Shaka Player.

What did you expect to happen?
Version 4.8.4 first calls and plays the third segment of the video playlist.

Version 4.9.5 initially calls and plays the first segment of the video playlist.
What actually happened?

Are you planning send a PR to fix it?
When updating from version 4.8.4 to version 4.9.5, liveSegmentsDelay is not applied.

The default value of liveSegmentsDelay is 3, which means that the 3rd segment out of 5 segments is requested and played first.

However, no matter how you set liveSegmentsDelay after the version upgrade, the first segment among the five segments is always called and played.

4.9.5 version

[avelad]

I see you are using 1 second duration segments, try changing the inaccurateManifestTolerance config to 0. This setting impacts your stream I think.

[avelad]

I also see that your segments are 1 second, but #EXT-X-TARGETDURATION:2 says the duration is 2.

[brodiddev]

Since we are using lowlatencyMode, inaccurateManifestTolerance is already 0.
Even if you change lowlatencyMode to false, the result is the same.
If sequenceMode is set to true, there may be cases where the sync is out of sync, so sequenceMode was set to false to play segments based on timestamps.
X-TARGETDURATION:2, but what problem occurs if the segment is 1 second?

[avelad]

X-TARGETDURATION:2, but what problem occurs if the segment is 1 second?

We use that value to calculate the delay: https://github.com/shaka-project/shaka-player/blob/main/lib/hls/hls_parser.js#L3418-L3423

[brodiddev]

TARGETDURATION indicates the maximum length of a segment, so even if the segment is 1 second, shouldn't TARGETDURATION be set to 2 seconds?
It says so in the overview below. Am I doing something wrong?
https://datatracker.ietf.org/doc/html/rfc8216#section-2
https://datatracker.ietf.org/doc/html/rfc8216#section-4.3.3.1

[avelad]

If the maximum duration of your segment is 1, why do you use 2? In any case, this is the way Shaka works.

[brodiddev]

Thank you for adding it to the 4.11 milestone.

[avelad]

Can you test if this patch solves your issue?

test.patch

[brodiddev]

I think it would be more accurate because it calculates the delay based on the sum of the segment lengths. thank you!