[v3] Await some delay before re-attempting to push a segment following an error #1411
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR updates the way the RxPlayer handles a
QuotaExceededError
error thrown by aSourceBuffer.prototype.appendBuffer
call, to align it better to how we do it in the v4 - which seems more appropriate.The idea is that a browser might throw this QuotaExceededError when too much data has been pushed to the buffer and thus the browser is not able to accept any more segments for now.
In the v3 until now, what the RxPlayer did was trying to remove some data from the buffer - even skipping that part if the buffer was already empty enough - and then re-attempting to push the same segment. If the error repeats, there is a complex chain of events that lead to the buffering of that segment (at least in our last v3 releases), so there's no real issue there. in the end
The idea of this PR is to prevent doing the re-attempt of pushing the same segment directly, mostly for cases where the data-removal step is skipped, by awaiting 200 milliseconds.
This is just to improve our chances that the second push attempts works, as we've seen it fail in rare conditions on some devices.
I also added some code ensuring that we do not retry to push the segment if the corresponding "RepresentationStream" has been cancelled while it was awaiting those 200 milliseconds.