Defer playlist reload while network is offline

[dloftus]

What version of HLS.js are you using?

1.6.15

What browser (including version) are you using?

Chrome version 149.0.7827.53 (Official Build) (arm64)

What OS (including version) are you using?

Mac OS 15.7.2

Test stream

https://test-streams.mux.dev/x36xhzz/x36xhzz.m3u8

Configuration

{
 autoStartLoad: false,
 liveSyncDurationCount: 3,
 maxBufferLength: defaults.maxBufferLength,
 maxMaxBufferLength:  defaults.maxMaxBufferLength,
 manifestLoadingMaxRetry: HlsjsRobustness.MANIFEST_RETRY_ATTEMPTS,
 manifestLoadingRetryDelay: HlsjsRobustness.MANIFEST_RETRY_DELAY,
 levelLoadingRetryDelay: HlsjsRobustness.LEVEL_RETRY_DELAY,
 fragLoadingRetryDelay: HlsjsRobustness.FRAGMENT_RETRY_DELAY,
 capLevelToPlayerSize: true,
 pLoader: this.createLoader(this, RequestObjectType.MANIFEST),
 fLoader: this.createLoader(this, RequestObjectType.SEGMENT),
 loader: this.createLoader(this, RequestObjectType.OTHER),
}

Additional player setup steps

When testing behavior following loss of network connection during playback, we observe:

• For live streams, a fatal network error always occurs.
• For VOD streams, depending on presentation size and rendition details, one sees either:
  • A fatal network error, OR
  • Non-fatal errors only

The discrepancy between the 2 VOD streams arises when the player size (presenation size) is less than or equal to the lowest rendition on the ladder. This and the live/VOD discrepancy both appear to stem from the following underlying behavior in hlsjs:

1. When a frag load error occurs and network.onLine is false (i.e., device is offline), retry is deferred indefinitely until online status flips back to true.

2. When a playlist load error occurs, and device is offline, retries are not deferred, and once retries are exhausted, a fatal error is emitted.

So for live streams, where manifest requests are continual, a fatal error is always seen, but for VOD, it is conditional.

For example, 2 VOD streams are both played at 640x360; stream A has a ladder that extends down to 320x180, stream B's lowest rendition is 640x360. When the device goes offline, stream A will attempt to switch down to 320x180, and a fatal error ensues. Stream B will not make any switch, and only non-fatal errors will emerge as the buffer eventually plays out.
(Logs attached show this scenario)

Question

Should behavior be adjusted that no fatal errors emerge while "offline = true", or should fatal errors always emerge when network goes offline (perhaps keyed off buffer occupancy rather than load error)?

Checklist

• The issue observed is not already reported by searching on Github under https://github.com/video-dev/hls.js/issues
• The issue occurs in the stable client (latest release) on https://hlsjs.video-dev.org/demo and not just on my page
• The issue occurs in the latest client (main branch) on https://hlsjs-dev.video-dev.org/demo and not just on my page
• The stream has correct Access-Control-Allow-Origin headers (CORS)
• There are no network errors such as 404s in the browser console when trying to play the stream

Steps to reproduce

1. Play the test stream at a size of either 640x360, or at 320 x180
2. Turn off Wif-Fi or otherwise kill net connection
3. For both streams, examine the errors that emerge

Expected behaviour

Quesitonable. Should it be that that no fatal errors emerge while "offline = true", or should fatal errors always emerge when network goes offline (but perhaps keyed off buffer occupancy rather than load error)?

What actually happened?

The 320 stream has nowhere to switch to, and will hang with no fatal error; the 640 stream will attempt to downshift and draw an error.

Console output

logs exceed char limit

Chrome media internals output

[robwalch]

We could make the non-fatal retry behavior more consistent for segment and playlist network errors with offline status. Fatal errors should still be expected on stall or before playback such as when loading a manifest - the idea being that a user should never be expected to wait indefinitely while offline.

If you want content to start or restart once a connection is reestablished, you should build that functionality in your app.

[robwalch]

Can you share examples of the error events in each case that you consider disparaging? We can treat this as a bug with those specifics. Othersie, this will remain as an enhancement request.

Indicating whether this was found in testing using the network tools panel, toggling Wifi, or some other real-life simulation of offline connectivity would also be helpful.

[dloftus]

logs.zip

Logs show the example outlined (Stream A vs Stream B) above

[robwalch]

The expected behavior for playlist errors should match that of fragments added with #7476: retries should be suspended indefinitely while offline. It would then be up to the app to decide if the session should be ended errors occur while offline. Such errors would not only be limited to loading errors, but also subsequent stalling.

• For context offline retry deferral for segments was added in v1.6.11 with Defer segment requests when network connection is lost #7476

If we make that change, then in the following example, the first levelLoadError response.code=0 navigator.onLine=false lines would be given a retry period of Infinity, and trigger once navigator.onLine status is restored.

error-controller.ts:getLevelSwitchAction [level-switch] details=levelLoadError FOUND alternate level 0 (from 1) -> SendAlternateToPenaltyBox(flags=None). Switching renditions will trigger a media-playlist load for level 0.
base-playlist-controller.ts:checkRetry [playlist-error] details=levelLoadError response.code=0 navigator.onLine=true retryCount=0/2 retry=true. NOTE: the playlist/level loader has NO offline infinite-wait grace (unlike the fragment loader).
error-controller.ts:getLevelSwitchAction [level-switch] details=levelLoadError NO alternate level available -> SendAlternateToPenaltyBox(flags=MoveAllAlternatesMatchingHost), unresolved. Frag loader will PARK if offline; otherwise onErrorOut marks this FATAL.
base-playlist-controller.ts:checkRetry [playlist-error] details=levelLoadError response.code=0 navigator.onLine=true retryCount=0/2 retry=true. NOTE: the playlist/level loader has NO offline infinite-wait grace (unlike the fragment loader).
base-playlist-controller.ts:checkRetry [playlist-error] details=levelLoadError response.code=0 navigator.onLine=false retryCount=1/2 retry=true. NOTE: the playlist/level loader has NO offline infinite-wait grace (unlike the fragment loader).
error-controller.ts:getLevelSwitchAction [level-switch] details=levelLoadError NO alternate level available -> SendAlternateToPenaltyBox(flags=MoveAllAlternatesMatchingHost), unresolved. Frag loader will PARK if offline; otherwise onErrorOut marks this FATAL.
base-playlist-controller.ts:checkRetry [playlist-error] details=levelLoadError response.code=0 navigator.onLine=false retryCount=2/2 retry=true. NOTE: the playlist/level loader has NO offline infinite-wait grace (unlike the fragment loader).
base-playlist-controller.ts:checkRetry [playlist-error] -> playlist retries EXHAUSTED (2/2) for details=levelLoadError: checkRetry returns false (unresolved) -> escalates to FATAL.
error-controller.ts:onErrorOut [FATAL] Escalating to FATAL: details=levelLoadError type=networkError response.code=0 action=SendAlternateToPenaltyBox UNRESOLVED. hls.stopLoad() will follow. (This is the cessation of playback.)