Reset loading start on worker setup error

[robwalch]

This PR will...

Fixes #5617

Why is this Pull Request needed?

When worker setup errors, stream-controller nextLoadPosition is not reset, leading to the player skipping any segments loaded while attempting worker setup. This leads to initial segment appends being performed out of order, after the skipped segments are reloaded, which can produce gaps.

Are there any points in the code the reviewer needs to double check?

Resolves issues:

Fixes #5617

[kevleyski]

Just a thought, the param with that nested nullish passed into resetStartWhenNotLoaded could be logic in that function instead that determines this

Also (not entirely sure as JS can be somewhat magical under the hood) where there are repeated string === comparisons would a numerical enum not be more efficient?

[robwalch]

Hi @kevleyski,

Just a thought, the param with that nested nullish passed into resetStartWhenNotLoaded could be logic in that function instead that determines this

That's a good point, and would remove some of the repetition added in this change. I hadn't thought of changing the level parameter to what would essentially be a suggestion; call it levelThatErrored and ignore it if there was a different level index loaded more recently.

Ultimately, the goal is that if we're in a live stream (we get that from loaded playlist details), then we update the start position in case playlist updates would result in new start position. As it stands is far from perfect and does not account for cases where the previous startPosition wasn't even aiming for the edge. File an issue, with a path to break this, and we can revisit. Hopefully most embeds for live aren't running broken worker setups, or timing out on initial segment requests that were starting earlier in a DVR-like event stream.

[robwalch]

Also (not entirely sure as JS can be somewhat magical under the hood) where there are repeated string === comparisons would a numerical enum not be more efficient?

Can you give me an example?

I find the mental cost while debugging (time lost remembering the difference between video error 3 or 4?) outweighs any runtime efficiency for the cases I can think of. Typescript enums, especially ones with API consts that we can't minify, don't buy much, and aren't something we can change once made public. Willing to discus and hope we can improve.