Uncaught DOMException: Failed to read the 'buffered' property from 'SourceBuffer'

[simonemazzoni]

Environment

• 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
• The issue observed is not already reported by searching on Github under https://github.com/dailymotion/hls.js/issues
• The issue occurs in the latest reference client on http://dailymotion.github.io/hls.js/demo and not just on my page

• Link to playable M3U8 file:
• Hls.js version: 0.6.21
• Browser name/version: Chrome 56.0.2924.87 (Official Build) (64-bit)
• OS name/version: macOS Sierra

Sometimes when I try to invoke the recoverMediaError() function to recover a FATAL media error (e.g. fragLoopLoadingError) I got this error

Uncaught DOMException: Failed to read the 'buffered' property from 'SourceBuffer': This SourceBuffer has been removed from the parent media source.

I checked the source code and it looks like the problem is here

Does this rings any bell?

Thanks,
Simone

[mangui]

Hi @simonemazzoni
is it happening on streams with alternate audio tracks ?
could you provide debug logs ?

[simonemazzoni]

Hi @mangui,
what do you mean with "alternate audio tracks"?
I have to make another test with hls.js debug set to true. I will send it to you as soon as is ready.

[simonemazzoni]

I can't reproduce the behaviour anymore.
Actually I don't know exactly why, but I will keep this monitored.

I'll let you know if it happens again.

[drichards]

@mangui we've been seeing this one as well on streams that don't have alternate audio tracks. Unfortunately I haven't been able to reproduce so I don't have debug logs. Here's the stack trace though, it seems to consistently originate from the AudioStreamController from all the traces I looked at, not the corresponding path in the StreamController.

From what I can tell, it appears to be an issue where the tick event interval gets called after the source buffer has been removed, but before the controller's destroy method gets called.

InvalidStateError: Failed to read the 'buffered' property from 'SourceBuffer': This SourceBuffer has been removed from the parent media source. at bufferInfo(./node_modules/hls.js-twitter/dist/hls.js:6620:1) at doTick(./node_modules/hls.js-twitter/dist/hls.js:11070:1) at t.tick(./node_modules/hls.js-twitter/dist/hls.js:11018:1)

[mangui]

Hi @drichards
the sourcebuffer has definitely been removed from the parent MediaSource, but i can't figure how.

in theory sourcebuffers could only be removed on :

• BUFFER_RESET (triggered at start, or when switching streams)
• MEDIA_DETACHING Media Source is detached from media element

MEDIA_DETACHING seems to be handled as expected : sourcebuffer references are cleaned, and audio stream controller should switch to STOPPED state

i identified potential flaws in BUFFER_RESET (but only if you keep using the same hls instance to play all your streams)
i will push a fix for that but that might not address your pb.

I am bit reluctant in adding a try/catch in bufferInfo() for the moment.

if you could provide more insights on the workflow that could help (when does that exception happen : middle of playback, at video start, ... when switching videos)

thanks in advance

[drichards]

Hi @mangui pretty much all the instance I could see in our logs happened when we called hls.destroy(). It seems to me like the MEDIA_DETACHING handling in BufferController is happening prior to the handling in AudioStreamController, and then between those two the tick interval fires. However, I don't really see where that could happen since that whole chain is synchronous as far as I can tell.

[mangui]

hi @drichards
by any chance are you reusing an hls instance after calling hls.destroy() ?

[mangui]

the only async thing is the setTimeout() in tick()

I think the only defensive option is to add a try/catch in BufferHelper.bufferInfo()

[mangui]

should be fixed in next release

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[xwlcn]

I found if use aac 5.1 has the same problem.