Restart loading in recoverMediaError when autoStartLoad is disabled
#7693
Conversation
github-project-automation
bot
moved this to Top priorities
in HLS.js Release Planning and Backlog
|
CC @gjanblaszczyk @zalishchuk @christriants. Please review. |
|
@robwalch I'm unsure if this will resolve the issue, as error.MP4 |
|
If I understand the issue correctly, the problem is that in iOS 26+ Safari cold starts and cache resets, Dummycode: if (mediaSource.readyState !== 'open') {
if (mediaSource.readyState === 'ended' && !this.hasBufferedData) {
this.hls.recoverMediaError();
}
return;
}Not 100% sure this is the right fix, though. It feels a bit like treating the symptom rather than the root cause. Also, it's not clear if there are edge cases where MediaSource legitimately isn't When reviewing the debug logs, we see a "Media source opened" message, but there’s no sign of a "Media source ended" before the error. Instead, it jumps directly to Logs |
|
Did you report a bug to Safari? The root cause is MediaSource in Safari, not HLS.js, as this issue does not occur in other browsers. Please test the fix. Verification or results with logs based on these changes would help make sure we’re hitting the mark. This PR is not the place to provide logs of behavior before the changes being submitted. That information belongs in the original issue to aid in diagnosis and solutioning. |
|
There are a number of append errors, some are stream issues where this change and #7683 should not be expected to work, that should be re-evaluated. As part of this change or a follow-up, I'd like to emit MediaSource closure while attached as a new type of error event, so that recovery is handled by the error-controller.
|
|
I'm still investigating the actual cause of the issue. Just before calling I haven't filed a Safari bug yet because I want to be certain it's not an issue with HLS.js. I created a simple demo without HLS.js and couldn't reproduce the strange |
|
Thanks for looking into this in more detail @zalishchuk. I also tried reproducing the issue using demo/basic-usage.html (with a modified |
Yes, this issue can be consistently reproduced using the default configuration with a basic HLS.js setup. Whether the start load is enabled or disabled doesn't really affect the issue itself.
After you reload or open new tabs with the same page, it behaves normally. It looks like the issue only affects the "first" Media Source instance for your Safari "session", but I am still not sure. A ready state But... As I mentioned, the fact that I can't reproduce that with a simple MMS raw setup is weird. |
|
Thought I'd share what I found. The problemOn iOS26, when Safari is cold started (force-closed from app switcher and reopened), the first ManagedMediaSource instance fails on What I testedI built a minimal repro page and ran a bunch of tests on cold start:
That last test was the smoking gun. It's not about needing a separate "warmup" MMS - the same instance works fine after one append cycle completes. Safari 26's MMS subsystem just needs one Root cause (based on my testing)Simultaneous Possible fixes
I'm leaning toward option 1 for now since it's isolated and doesn't mess with the append queue logic, but wanted to get your thoughts. The warmup function is pretty minimal - about 40 lines, creates an MMS, appends a 20-byte ftyp box, waits for updateend, cleans up. Happy to share the repro page if you want to poke at it yourself. Let me know what you think. |
|
The current fix looks good to me. Tested this on iOS 26.2 Safari (cold open). Providing logs. We're still seeing the append errors, but I believe that issue is with Safari.
@robwalch +1 to this idea. I would be happy to take this on, if you feel it would be better as a follow-up. |
|
@zalishchuk, please share the repro page and file an issue with Safari, using that as the minimal example. |
|
@christriants thanks. Changed to error handling are not needed for this fix. The “MediaSource readyState: ended" error goes through a different path since the source is not closed and the append error unavoidable without modifying valid append sequencing. For this issue, recoverMediaError was already being called onErrorOut, it just wasn't restoring the loading state, as described above. |
|
I plan to merge this PR with only minor changes ( In terms of working around the append sequence leading to the Safari bug, I don't think we should make changes that would defer appends and increase start time. Looking into combining init segment and media appends might as an alternative without performance penalties could be interesting. So would making adjustments to force the first append to be video before audio. |
|
@robwalch Found a clean fix for the iOS 26 ManagedMediaSource cold-start bug. The issue: the first MMS after a Safari cold start fails on simultaneous appendBuffer calls (readyState lies: shows "open" but is internally "ended"). Second MMS always works fine. The fix: just let it fail and recover. In if (
this.appendSource &&
this.mediaSource?.readyState === 'ended' &&
!this.hasRecoveredFromColdStart
) {
this.hasRecoveredFromColdStart = true;
this.hls.recoverMediaError();
return;
}We could also add a check to see whether this occurred during initial buffering to improve detection precision. Another option: make this a new error type (e.g., Simple, no startup latency, uses existing recovery mechanism. Users might notice a brief stall during a cold start, but it's barely noticeable. |
|
Created a standalone repo for the iOS 26 MMS bug: Live demo: https://zalishchuk.github.io/ios-26-mms-bug/ It auto-runs on page load and detects whether it's a cold start or a reload. Four tests showing exactly what triggers the bug (simultaneous appends) and what doesn't (sequential, single SB, warmup). Should be useful for the WebKit bug report. |
This PR will...
Restart loading in
recoverMediaErrorwhenautoStartLoadis disabled.Why is this Pull Request needed?
Because otherwise,
detachMediawill stop all loading, andattachMediawill not restart it whenautoStartLoadis set tofalse.The problem when testing the fix in #7683 (call
recoverMediaErrorwhen MediaSource of attached media element is closed) for the steps in #7687 is that withautoStartLoad: false, loading is not automatically restarted. This change ensures that loading is restarted whenhls.startedistrue(meaninghls.stopLoad()was never called).Resolves issues:
Fixes #7687
Checklist