Live HLS streams freeze on variant switches when ignoreManifestProgramDateTime is true.

[JulianDomingo]

Have you read the FAQ and checked for duplicate open issues?
Yes. No related open issue exists regarding this behavior when ignoreManifestProgramDateTime is true.

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

N/A

What version of Shaka Player are you using?

Latest from main, and reproducible on all maintained version branches.

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?
Custom app, initially reported by Pluto TV's Cast app which uses Shaka Player.

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

What browser and OS are you using?
Chrome, ChromeOS

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
Chromecast with Google TV, latest prod firmware

What are the manifest and license server URIs?

N/A (Pluto TV app library content)

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

Pluto TV-specific configuration; to avoid surfacing the entirety of their configs, the only relevant one to note is ignoreManifestProgramDateTime: true.

What did you do?

1. Cast any live channel from Pluto TV's production app from Google Play Store.
2. Let the live stream run and observe.

What did you expect to happen?
The live stream will continue to run without interruption and/or errors.

What actually happened?

The live stream eventually freezes (the time it takes for this varies randomly). Console logs indicate this is caused by Shaka infinitely stalling after a variant switch due to the timestamp offsets applied to the segments when it needs to drop old ones:

shaka-player/lib/hls/hls_parser.js

Lines 604 to 613 in e8f37f0

	segmentIndex.dropFirstReferences(numSegmentsToDrop);
	// Now adjust timestamps back to begin at 0.
	const segmentN = segmentIndex.earliestReference();
	if (segmentN) {
	const streamOffset = -segmentN.startTime;
	// Modify all SegmentReferences equally.
	streamInfo.stream.segmentIndex.offset(streamOffset);
	// Update other parts of streamInfo the same way.
	this.offsetStreamInfo_(streamInfo, streamOffset);

Based on the media times of the segment references after the offset is applied:

The media times are not properly aligned.

Looking at the upstream code leading to the console log line (video:N) looking up segment from new stream endTime: ${TIME}, the ${TIME} is determined by mediaState in StreamingEngine. However, these are based on the old media times, whereas the times maintained by the mediaSequenceToStartTime in HlsParser are the new media times.

While a preferable fix here would be further investigating why/how a time misalignment occurs during variant switches, a simple (and proven fix according to PlutoTV) is to simply ignore the time offset-related logic when Shaka Player doesn't have any segments to drop. This will be the fix tagged to this issue.

Other justifications to consider this 'hotfix' route:

1. This is a production issue for PlutoTV, so a timely fix is appreciated.
2. Technically an optimization, and prevents risks of regression(s) for existing A/V sync logic relying on EXT-X-MEDIA-SEQUENCE by otherwise modifying other areas of the code.