Is there a way to blacklist poorly performing fragments when buffering m3u8 streams you don’t control?

[MechanicalMink]

Consider a poorly constructed m3u8 stream hosted on a foreign server. Some specific fragments of some specific levels just will not load, either due to CORS issues or timeouts, and there is absolutely nothing we can do about that serverside. Upon encountering one of these fragments during buffering, HLS.js will throw a NetworkError and the stream controller will move from "IDLE" into the "STOPPED" condition.

If I just call hls.startload(-1) in the handler, it will keep trying to buffer the broken fragment in a loop. If I try to provide it with a timestamp or frag sn beyond the broken frag, it will still get stuck trying to buffer the same broken frag in a loop. The only way I can currently seem to get past the broken fragment is to wait for the playhead to stall at it, skip the playhead past it, and then the buffer will start filling again.

Is there a way I can blacklist a given frag sn in the network error handler such that I can stop retrying to buffer it when I call hls.startload()? Specifically, can I do this on the client side?

[robwalch]

Mark bad fragments with a gap (v1.5+).

[MechanicalMink]

Hey, thanks for the tip. Now, say we have buffered past this point successfully after marking this fragment as a gap, but I now have that fragment's data in a blob and I want to add it to the buffer. I've tried removing the gap tag and then calling hls.streamController.loadFragment(frag, hls.streamController.getLevelDetails(), frag.start), but the playhead still stalls at the beginning of the patched hole.

The flip side of that is that if I don't mark the frag as a gap in the first place, and I instead just let the stream controller sit and constantly try to load the bad fragment until I swap the frag url for a good blob url, it buffers and plays through just fine. How can I get this behavior to happen when I retroactively patch the hole?