Rollback hls.js to 0.14

[thornbill]

Changes
This rollsback hls.js to 0.14 and prevents dependabot from opening PRs for major version upgrades due to this upstream issue: video-dev/hls.js#4367

Issues
Fixes #3158

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[ccheng32]

Hi @thornbill thanks for the fix. Have you verified that hls.js v0.14.7 fixes #3158?

AFAIK I encountered the problem on an unmodified jellyfin server running v10.7.7, which seems to serve hls.js v0.14.17 for the web frontend. (link)

[ccheng32]

Some more updates from my testing. I acutally tried out some more browsers and found out that Chrome and Firefox have this issue, while Safari on MacOS does not have this issue at all. I suspect this line may be the culprit:

jellyfin-web/src/plugins/htmlVideoPlayer/plugin.js

Line 394 in 0831207

if ((browser.chrome || browser.edgeChromium || browser.firefox) && playbackManager.getMaxStreamingBitrate(this) >= 25000000) {

[ThibaultNocchi]

Safari does handle HLS natively, and I think the client takes profit of it. @thornbill could confirm, but I guess it's why there's no problem with Safari.

Also the line you've found hasn't been touched since 10.7.7, so if it worked back then and not now it's not due to that. Could you please retry with 10.7.7? :)

From experience, with HLS.js >= 1 it happens really quickly in any playback. Maybe it happened back then, but we'd have heard about it if such a bug was present in production.

[thornbill]

I did not see any errors in Firefox, but I didn't test it too thoroughly either. 😅