[krseager]

This PR will...

Reset details.requestScheduled when a different live audio or subtitle track is selected, so its playlist loads right away.

Why is this Pull Request needed?

Re-selecting a live track honoured the stale reload schedule from its previous selection, delaying the switch by up to one target duration.

Are there any points in the code the reviewer needs to double check?

Levels have the same pattern and are not changed here.

Resolves issues:

Fixes #8091

Checklist

• changes have been done against master branch, and PR does not conflict
• new unit / functional tests have been added (whenever applicable)
• API or design changes are documented in API.md

[robwalch]

I don't quite follow. Were the track.details being switched (back) to, not previously loaded a target duration before requestScheduled? Doesn't that mean they either do not need to be reloaded immediately because requestScheduled is in the future, or they do because it is more than a target duration in the past?

[robwalch]

Are you sure there isn't an issue with audio segment loading being blocked while switching (both with and without full audio buffer flush)?

[robwalch]

If there are level details with the needed fragments then the audio-stream-controller state should not change to WAITING_TRACK allowing for immediate segment loading. Something like:

  protected waitForLive(levelInfo: Level) {
    const details = levelInfo.details;
    return (
      details?.live &&
      details.type !== 'EVENT' &&
      (details.expired ||
        // unless the responses are not advancing the playlist (3 strikes)
        // wait until the end of the playlist advances past the playhead or load position
        (details.misses < 3 && details.partEnd <= this.playhead))
    );
  }

instead of what is there now, which is causing the wait:

hls.js/src/controller/base-stream-controller.ts

Lines 687 to 694 in dd2a4d3

	protected waitForLive(levelInfo: Level) {
	const details = levelInfo.details;
	return (
	details?.live &&
	details.type !== 'EVENT' &&
	(this.levelLastLoaded !== levelInfo || details.expired)
	);
	}

Using requestScheduled in waitForLive didn't quite work because it may not be updated when toggling options and cancelling requests - setting it back to -1 in those cases might work.

details.partEnd <= this.playhead prevents the use of a playlist that could not cover any part of playback. With details.misses < 3 it yields if the playlist is not changing after three reloads.

this.levelLastLoaded !== levelInfo could be restored in combination with the above, or with comparison of details.partEnd < this.levelLastLoaded.details.partEnd or perhaps advancedDateTime.

[robwalch]

Closing in favor of #8107. Please review, and let me know if you find edge-cases or a reason to update the reload schedule on switch.