HLS video is not resuming after network issues

[nicklive]

Description

Hello, I have an issue with video.js+http-streaming, that I can consistently reproduce on basicly all hls streams. Video.js is not resuming live stream after network issues (slow connection and resuming to normal).

Here reduced test case but for reproducing you need to throttle your connection with chrome devtools (please see Steps to reproduce).

Steps to reproduce

1. Open link
2. Wait for loading example and video start
3. Open chrome devtools set throttling for 100 kb/s
4. Wait about 50 seconds (or a bit more)
5. After set throttling to online

Results

Expected

Logically after Steps to reproduce video should resume back to live

Actual

video.js+http-streaming try to load infinity times one segment and aborting it, video is not resuming

Error output

Error output contains a lot of

video.js:142 VIDEOJS: ERROR: DOMException: Failed to set the 'duration' property on 'MediaSource': The 'updating' attribute is true on one or more of this MediaSource's SourceBuffers.
    at HtmlMediaSource.addSeekableRange_ (https://unpkg.com/[email protected]/dist/video.js:49141:44)
    at addSeekableRange (https://unpkg.com/[email protected]/dist/video.js:55039:36)
    at PlaylistLoader.<anonymous> (https://unpkg.com/[email protected]/dist/video.js:55054:15)
    at PlaylistLoader.data.dispatcher (https://unpkg.com/[email protected]/dist/video.js:1818:33)
    at trigger (https://unpkg.com/[email protected]/dist/video.js:1954:27)
    at PlaylistLoader.EventTarget.trigger (https://unpkg.com/[email protected]/dist/video.js:2432:5)
    at PlaylistLoader.haveMetadata (https://unpkg.com/[email protected]/dist/video.js:39151:14)
    at https://unpkg.com/[email protected]/dist/video.js:39089:17
    at Object.callback (https://unpkg.com/[email protected]/dist/video.js:40086:9)
    at cbOnce (https://unpkg.com/[email protected]/dist/video.js:7220:17)

Additional Information

There are 3 segments in samlpe hls playlist, but I tried 30 segments in playlist and problem repeats but after more delay (2 min) in 4 step.

videojs-http-streaming version

what version of videojs-http-streaming does this occur with?
videojs-http-streaming 1.6.0

videojs version

what version of videojs does this occur with?
video.js 7.4.1

Browsers

what browsers are affected? please include browser and version for each
Chrome 71.0

Platforms

Windows 10 64-bit

Other Plugins

none

Other JavaScript

none

[welcome]

👋 Thanks for opening your first issue here! 👋

If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.
To help make it easier for us to investigate your issue, please follow the contributing guidelines.

[lewma]

I get the exact same behavior. My videojs session recursively displays:

VIDEOJS: ERROR: DOMException: Failed to set the 'duration' property on 'MediaSource': The 'updating' attribute is true on one or more of this MediaSource's SourceBuffers.
at HtmlMediaSource.addSeekableRange_ (http://localhost:4300/vendor.js:269446:44)
at addSeekableRange (http://localhost:4300/vendor.js:275344:36)
at PlaylistLoader. (http://localhost:4300/vendor.js:275359:15)
at PlaylistLoader.data.dispatcher (http://localhost:4300/vendor.js:221309:33)
at trigger (http://localhost:4300/vendor.js:221445:27)
at PlaylistLoader.EventTarget.trigger (http://localhost:4300/vendor.js:221923:5)
at PlaylistLoader.haveMetadata (http://localhost:4300/vendor.js:259445:14)
at http://localhost:4300/vendor.js:259375:17
at Object.callback (http://localhost:4300/vendor.js:260390:9)
at cbOnce (http://localhost:4300/vendor.js:226932:17)

[thecotne]

i have same issue

when connection speed drops player can't recover after connection is recovered

[alessandro-bottamedi]

Same issue here, to reproduce simply set "Slow 3G" in network tab in Google Chrome DevTools... after the connection is restored to "Online" the problem persist.
Someone have found a temporary solution?

UPDATE:
the error is not detected by the " .on('error' ... " event. So i have no way to refresh in case this error occurs.

Error Detail:

VM37369 video.js:142 VIDEOJS: ERROR: DOMException: Failed to set the 'duration' property on 'MediaSource': The 'updating' attribute is true on one or more of this MediaSource's SourceBuffers. at HtmlMediaSource.addSeekableRange_ (http://localhost:3000/vendor/videojs/video.js:49956:44) at addSeekableRange (http://localhost:3000/vendor/videojs/video.js:55855:36) at PlaylistLoader.<anonymous> (http://localhost:3000/vendor/videojs/video.js:55870:15) at PlaylistLoader.data.dispatcher (http://localhost:3000/vendor/videojs/video.js:1818:33) at trigger (http://localhost:3000/vendor/videojs/video.js:1954:27) at PlaylistLoader.EventTarget.trigger (http://localhost:3000/vendor/videojs/video.js:2432:5) at PlaylistLoader.haveMetadata (http://localhost:3000/vendor/videojs/video.js:39954:14) at http://localhost:3000/vendor/videojs/video.js:39884:17 at Object.callback (http://localhost:3000/vendor/videojs/video.js:40899:9) at cbOnce (http://localhost:3000/vendor/videojs/video.js:7441:17)

[coolicer]

I got this problem too. how to fix it?

[danrossi]

I'm trying to find a solution to try and play if a hls live stream isn't available. Once it goes to an error , you can't click to play again. Any ideas ?

[danrossi]

This causes a stack issue, as the player tries to autoload instead of after clicking. Can't turn off autoloading

player.on("error", () => {

        	player.pause();
        	player.trigger("ended");
        
        	player.reset();
        
        	player.src(player.currentSrc());

        });

[coolicer]

@danrossi It may not catch on error event

[alessandro-bottamedi]

The error must be catched at the line 50294 (ver 7.5.1):

this.nativeMediaSource_.duration = end;

I modified it in this way:

  try {
    this.nativeMediaSource_.duration = end;
  } catch (e) {
    if (typeof streamCustomError === "function") { 
      streamCustomError(e);
    }
    return this.trigger('error');
  } 

Where streamCustomError(e) is my custom function to handle this specific error....

However I noticed that after about 5 minutes the video streaming starts again correctly.

[danrossi]

An offline stream will go to error but no way to click to try and play again. Setting the src will try and start loading again.

[danrossi]

An example fiddle I found. With a non existent manifest, you cant click to try and load again

https://jsfiddle.net/m3sf8nav/

[coolicer]

@alessandro-bottamedi What did you do in streamCustomError function

[alessandro-bottamedi]

@alessandro-bottamedi What did you do in streamCustomError function

I reset and reload the video streaming after a timeout...

[coolicer]

@alessandro-bottamedi Thank you, I'll try it later.

[json-m]

this could wind up being a billing issue for those using cdns to deliver hls. i discovered this bug watching metrics in my own cdn account after flipping the switch in my player for users that are very distant from my hls relay server to help with buffering.

using a single client to test (2.5Mbps~ video), set browser throttle speed to about 200kbps. after a while it requests the same ts chunk hundreds of times (300+ if i just let it go forever)

balloons up to quite a bit of bandwidth (17x !!)

eventually the bandwidth dips off at the end there as it starts abandoning requests. the player stops abandoning requests after a bit which just starts this cycle over again.

since the player is still trying to dl all of these segments it is requesting, the player is presumably making the flakey connectivity problem severely worse for the end user since they are now trying to download the same segment hundreds of times.

i tested this on the latest firefox and chrome at the time of writing and you can see the videojs version in the screenshot (7.5.4).

[movAX13h]

When the connection drops completely, videojs tries all lower quality settings and keeps the lowest.
When the connection is re-established, it resumes playback at lowest quality and does not return to a better quality stream. Is there a way to circumvent this behaviour? Especially in cases where videojs is used in applications that are not controlled by any user and complete reloads should be avoided, this is critical.

I've also noticed that the waiting event is sometimes followed immediately by a timeupdate event which makes the waiting event almost useless because there's a contradiction that can not be tackled by logic.

Also, re-initialising the same stream in the same div after a call to dispose() almost always leads to long waiting time (~20s) where the poster is already removed but only the progress event fires, no timeupdate event. Only after ~50MB of downloaded data, the video finally gets displayed. When its loaded at the very beginning (fresh page load), it starts almost immediately (<1s).

[pacepace]

Firefox is doing this as well.

Videojs version
video.js 7.4.3 and 7.5.5

Browsers
Firefox 68.0b7

Platforms
Windows 10 64-bit

[vksbansal]

any update?

[arjitsachdeva]

I'm facing the same issue as outlined above - tested in the latest version of http-streaming (v1.11.1) and also on the latest version of video.js (v7.6.5)

[snowdream]

any update?

[bruinxs]

I got this problem too. Any update?

[danrossi]

I've built an offline reconnect feature. Tested with HLS and Wowza.

https://videojs.electroteque.org/offline

[lusase]

Can I prevent this error through plug-ins or other methods?

[flexmodule]

@alessandro-bottamedi Thank you, I'll try it later.
Have you solved it？

[flexmodule]

any update?

[dkirilenko]

any update? I got the same issue

[picheli20]

I've notice that this bug was introduced on version 7.2.1, downgrading to version 7.2.0 solves this problem (at least till someone comes up with more stable solution)

[thecotne]

in [email protected] videojs/http-streaming has been updated from 1.2.1 to 1.2.3 here is merge request https://github.com/videojs/video.js/pull/5368/files

i have checked latest videojs [email protected] with videojs/[email protected] it works

and [email protected] with videojs/[email protected] has this bug

so regression is somewhere here v1.2.1...v1.2.2

there is total of 3 commits that can possibly cause any issue (others are tests or docs modifications)

• 6c68761
• 7c68335
• 960ee79

from this commits one is mux.js update i have checked old mux.js version and it has same bug

from remaining two one is typeofs minification related (less likely to cause any problem)

and second is updates of seeking behavior and i think this commit is a problem 6c68761 (committed by @gesinger and merged by @forbesjo)

[nvuhung]

Hello, any update for this issue?

[DispatchCommit]

@gkatsev Testing with 1.13.3 which I believe includes the merged middleware related PR linked above and still experiencing issues. I haven't been able to fully analyze the cause, but for the first ~10-30 seconds after an HLS livestream is published, if I attempt to load the stream I encounter this error. Haven't fully investigated the circumstances yet though to identify a root issue.

D:\bitwave>npm ls @videojs/http-streaming
[email protected] D:\bitwave
`-- video.js@npm:@bitwave/[email protected]
  `-- @videojs/[email protected]

Attempting to immediately load an HLS stream after it's published causes this error:

VIDEOJS: TypeError: Failed to set the 'currentTime' property on 'HTMLMediaElement': The provided double value is non-finite.
    at Html5.setCurrentTime (video.es.js?f0e2:19314)
    at set (video.es.js?f0e2:9563)
    at Player.eval (video.es.js?f0e2:22964)
    at Player.ready (video.es.js?f0e2:3932)
    at Player.techCall_ (video.es.js?f0e2:22962)
    at Player.currentTime (video.es.js?f0e2:23226)
    at SeekBar.handleMouseMove (video.es.js?f0e2:13239)
    at SeekBar.handleMouseDown (video.es.js?f0e2:12275)
    at SeekBar.handleMouseDown (video.es.js?f0e2:13183)
    at HTMLDivElement.data.dispatcher (video.es.js?f0e2:1899) Video is not ready. (Video.js)

and eventually:

video.es.js?f0e2:97 VIDEOJS: ERROR: DOMException: Failed to set the 'duration' property on 'MediaSource': The 'updating' attribute is true on one or more of this MediaSource's SourceBuffers.
    at HtmlMediaSource.addSeekableRange_ (webpack-internal:///./node_modules/video.js/dist/video.es.js:36594:42)
    at addSeekableRange (webpack-internal:///./node_modules/video.js/dist/video.es.js:42983:34)
    at PlaylistLoader.eval (webpack-internal:///./node_modules/video.js/dist/video.es.js:42998:13)
    at PlaylistLoader.data.dispatcher (webpack-internal:///./node_modules/video.js/dist/video.es.js:1939:31)
    at trigger (webpack-internal:///./node_modules/video.js/dist/video.es.js:2075:25)
    at PlaylistLoader.EventTarget.trigger (webpack-internal:///./node_modules/video.js/dist/video.es.js:2478:3)
    at PlaylistLoader.haveMetadata (webpack-internal:///./node_modules/video.js/dist/video.es.js:27487:12)
    at eval (webpack-internal:///./node_modules/video.js/dist/video.es.js:27414:15)
    at Object.eval [as callback] (webpack-internal:///./node_modules/video.js/dist/video.es.js:28472:7)
    at cbOnce (webpack-internal:///./node_modules/@videojs/xhr/index.js:95:21)

As well as an hls-video-underflow event: hls-video-underflow: {type: "usage", name: "hls-video-underflow", target: video#streamplayer_html5_api.vjs-tech, ...

Once I get a chance to debug this further I'll open a new issue with any findings.

Update: Stream loads fine but exhibits issues with seekbar while #EXT-X-MEDIA-SEQUENCE:0 and playlist size is increasing (and also with #EXT-X-DISCONTINUITY), but once entire m3u8 playlist has been generated, and #EXT-X-MEDIA-SEQUENCE begins to increment, the player fails to load new segments.

This seems to only occur when m3u8 playlist is first being generated and stream utilizes the DVR functionality. I would expect video.js (and/or http-streaming) to detect that new segments are being added to the end of playlist and calculate dvr length based on amount of segments in the playlist and the target duration (and maybe using the EXTINF: timing data), but instead it seems like it fails to calculate.

[DispatchCommit]

Reverting to http-streaming 1.12.2 for video.js's dependancy resolves my issue, though the VIDEOJS: ERROR: DOMException: Failed to set the 'duration' property on 'MediaSource': The 'updating' attribute is true on one or more of this MediaSource's SourceBuffers. error still appears in the console.

It's definitely related to attempting to load a stream that hasn't fully populated it's manifest though. Refreshing the page once the manifest has all the segments required for it's DVR functionality it runs fine, but attempting to load the stream prior to the manifest being fully populated results in video.js re-requesting .ts segments at an increasing rate until it stalls out it's available bandwidth.

[gkatsev]

Have a sample of how your manifest looks like during that transitionary period? Also, we have a mux.js update pending in the 1.x branch with some fixes that we need to make.

Also, can you try it out on https://videojs-http-streaming.netlify.app/? It's what we hope to release really soon, it's a big update with lots of fixes, changes, and refactors.

[DispatchCommit]

sample of how your manifest looks like during that transitionary period

During transition the playlist will appear like this:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-TARGETDURATION:2
#EXT-X-DISCONTINUITY
#EXTINF:2.000,
1588854648283.ts

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-TARGETDURATION:2
#EXT-X-DISCONTINUITY
#EXTINF:2.000,
1588854648283.ts
#EXTINF:2.000,
1588854650282.ts

(keeps adding additional .ts segments until DVR is filled)
Then (this is when issues begin):

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-TARGETDURATION:2
#EXTINF:2.000,
1588854650282.ts
#EXTINF:2.000,
1588854652300.ts
#EXTINF:2.000,
1588854654297.ts
#EXTINF:2.000,
1588854656294.ts
#EXTINF:2.000,
1588854658291.ts
#EXTINF:2.000,
1588854660288.ts
#EXTINF:2.000,
1588854662285.ts
#EXTINF:2.000,
1588854664281.ts
#EXTINF:2.000,
1588854666303.ts
#EXTINF:2.000,
1588854668299.ts
#EXTINF:2.000,
1588854670295.ts
#EXTINF:2.000,
1588854672293.ts
#EXTINF:2.000,
1588854674291.ts
#EXTINF:2.000,
1588854676312.ts
#EXTINF:2.000,
1588854678312.ts
#EXTINF:2.000,
1588854680312.ts
#EXTINF:2.000,
1588854682312.ts
#EXTINF:2.000,
1588854684297.ts
#EXTINF:2.000,
1588854686312.ts
#EXTINF:2.000,
1588854688312.ts
#EXTINF:2.000,
1588854690312.ts
#EXTINF:2.000,
1588854692312.ts
#EXTINF:2.000,
1588854694312.ts
#EXTINF:2.000,
1588854696312.ts
#EXTINF:2.000,
1588854698301.ts
#EXTINF:2.000,
1588854700296.ts
#EXTINF:2.000,
1588854702292.ts
#EXTINF:2.000,
1588854704289.ts
#EXTINF:2.000,
1588854706286.ts
#EXTINF:2.000,
1588854708283.ts

Note: #EXT-X-MEDIA-SEQUENCE:0 now increases.
Note: #EXT-X-DISCONTINUITY no longer appears (unless we have dropped frames).

---

can you try it out on https://videojs-http-streaming.netlify.app/

Seems to run well there.

[DispatchCommit]

@gkatsev Also of note is that when the manifest file is first initially populating, the player does not show the live indicator, and it does not have a progress bar. And it does not show up afterwards either, I have to reload the player again to get the live indicator and progress bar to appear.

[tvkit]

Also, can you try it out on https://videojs-http-streaming.netlify.app/? It's what we hope to release really soon, it's a big update with lots of fixes, changes, and refactors.

@gkatsev the DOMException is no longer occurring in our environment and playback is much more reliable!

Occasionally getting network errors that we're hoping to mitigate via the player's error handler. Clicking the load button on the netlify.app immediately resumes playback. Here's the network error that's likely VPN related:

video.core.min.js:19 GET http://xxxxx/zzzzz/chunk12345.aac net::ERR_CONNECTION_RESET

[hassanabidpk]

Hi, Is this merged and available in official release of video.js?
I tried [email protected] but this problem still persists.

[DispatchCommit]

I saw a comment somewhere that this issue may have originated after video.js 7.2.0. I'm on http-streaming 2.0.0-rc2 and a fork of video.js's master repo, and still having this issue, may try to downgrade and compare.

[DispatchCommit]

Confirmed still an issue using all latest versions of http-streaming 2.0.0-rc2 and video.js 7.8.3. Also reproducing on https://videojs-http-streaming.netlify.app/
Streams loaded before manifest have fully populated will cause errors, and live UI will not function.

#378 (comment) seems spot on for my experience.

[Raino]

Any news?

[gkatsev]

The latest VHS 1.x release line should've fixed the issue as far as we know.
The same fix was made in the main branch after 2.0.0-rc.2 was tagged and should be in the 2.0.0 pre-release tag.

In our testing, this should be fixed. Please try latest VHS versions and let us know if you are still experiencing the issue.

[ronneylira]

@gkatsev when using react and npm how do I make sure I'm on the latest version of http-streaming?
as I understood the video.js package already contains http-streaming.

what I am trying to do is:

import videojs from 'video.js';
import '@videojs/http-streaming';

is there a way to make sure I'm on the correct version?

[DispatchCommit]

@ronneylira I use a custom video.js build and then publish that to NPM and in my package.json:

"video.js": "npm:@bitwave/video.js@^7.8.5",

to replace video.js with a custom build.

I'm working on updating my build to the latest RC to test.

[gkatsev]

If you install @videojs/[email protected] locally and import it as above, you should get it.
Though, the latest Video.js (7.8.4) should be using VHS 1.13.2 which includes the fix in the 1.x release line. So, theoretically, you don't need to include a custom VHS version.

[DispatchCommit]

I deployed 7.8.4 to our dev site for testing, and this issue still occurs. I've set the DVR on the playlist to be 5 minutes, and it seems to require about 30 seconds of DVR before the player recognizes the DVR is available.

I'll try updating to 2.0.0 and including like above and see if that behaves any better.

[DispatchCommit]

updated to 7.8.4 and http-streaming 2.0.0 and imported as shown above.

My server waits 15 seconds before sending the notice to clients that a streamer has gone live, and when that occurs, the player fully reloads (resets) and updates the source for the player. I increased that delay to 30 seconds and it still exhibits the same behavior. I'd hate to have to further increase the delay to 1 minute or greater, but even then I'm not positive the DVR would show initially. If I wait 30 seconds after the player reloads, and then trigger a second player, the live UI and DVR show up normally, but I cannot seem to get the DVR and Live UI to appear on the first load / reset.

[DispatchCommit]

Once more than 30 seconds of DVR are available, it appears to load fine though. I can try reloading after 35 seconds to confirm this, but it would seem fairly consistent that 30 seconds is the required DVR time before things work properly.

Edit: didn't want to make another separate comment for this, but I did confirm that waiting more than 30 seconds is required. I set the server to update after 45 seconds, and the stream loaded perfectly this time.
IMO, 30+ seconds is a long delay. I can tolerate this as a workaround for the time being now that I've identified how long of a delay is required, but when I can successfully load a stream 8-10 seconds after it begins broadcasting via HLS, but the DVR will not appear and will not function unless the load occurs AFTER 30 seconds, and requires a full reset to properly appear, this is fairly annoying bug to deal with. I can try to investigate further on my own now that I reasonable belief that a specific 30 second / 30,000 ms offset is required, I'm sure there will be a hardcoded value somewhere setting this threshold or detection.

[Raino]

@DispatchCommit My friend, could you please share your player style file? :D

[DispatchCommit]

@Raino of course! :)
Here's a link to the sass file in our frontend repo:
https://github.com/bitwave-tv/bitwave/blob/dev/assets/style/stream-player.scss
perma-link (in case we change the style at a later date):
https://github.com/bitwave-tv/bitwave/blob/947b0645c407fcf10565d57aba03b73ed07375f6/assets/style/stream-player.scss

[DispatchCommit]

I THINK I FIGURED IT OUT!

videojs/video.js#6409

Use the old liveui for live videos where seekableEnd - seekableStart is less than 30s

const defaults = {
  // Number of seconds of live window (seekableEnd - seekableStart) that
  // a video needs to have before the liveui will be shown.
  trackingThreshold: 30
};

This explains why I'm not seeing the live UI when my stream has less than 30 seconds of data!

Adjusting the threshold value to a more optimistic 5 seconds should ensure we avoid this issue:

const player = videojs('vid', {
  liveTracker: {
    trackingThreshold: 5
  }
});

I need to reduce my server delays back down to 10 seconds to test and confirm this is the cause.

Edit: Setting the threshold to 0 resolved this issue for me!

I'm happy with the behavior now, and I can reduce all my timers to just delay by 15 seconds and have no loading issues.
What a pain in the butt that was to fully identify and resolve.

[asoulliereHT]

I'm experiencing what seems to be this issue. rolling back to 7.2.0 as mentioned above appears to resolve this. any updates on this issue?

[danrossi]

A client just alerted me to my offline feature. Videojs is also now failing to internally retry on client side disconnection. And the interval is not consistent. Either first retry or second retry. It needs a health check on the first retry. I let it retry to a configured interval before starting the offline reconnect sequence, but in the case of client side disconnection, no error event is sent and it fails to retry ! I got work arounds working.

[renepardon]

I've notice that this bug was introduced on version 7.2.1, downgrading to version 7.2.0 solves this problem (at least till someone comes up with more stable solution)

I tried to go back to 7.2.0. Didn't worked for me.

[asoulliereHT]

I've notice that this bug was introduced on version 7.2.1, downgrading to version 7.2.0 solves this problem (at least till someone comes up with more stable solution)

I tried to go back to 7.2.0. Didn't worked for me.

i actually ended up upgrading to the latest and just found that my implementation was a lot of the problem

[gkatsev]

I guess I never circled back here. We've been working on a new ABR algorithm that is based on buffer length, as part of that we also switched to a timer for doing ABR related things. I believe that this will greatly improve it. Please try it out by enabling experimentalBufferBasedABR on VHS.

[shyamvala]

Hi,

Just curious if there is any resolution to this. I am on the 7.9.7 vjs version and 2.8.0 of http-streaming. I am seeing the playback stop after a segment fails to load (in dev console, i am seeing a cancelled request, i am not seeing any dom errors). The playback just stops after and I have waited for over 20mins to just see if it ever comes back but not really.

VJS: 7.9.7
HttpStreaming: 2.8.0
Browser: Opera
controls: true, autoplay: true, html5: { vhs: { overrideNative: true, enableLowInitialPlaylist: true, experimentalBufferBasedABR: true } nativeAudioTracks: false, nativeVideoTracks: false }

Wondering if its a case of just using an older version of the libraries or some additional configuration to turn on.

[mayeaux]

I THINK I FIGURED IT OUT!

videojs/video.js#6409

Use the old liveui for live videos where seekableEnd - seekableStart is less than 30s

const defaults = {
  // Number of seconds of live window (seekableEnd - seekableStart) that
  // a video needs to have before the liveui will be shown.
  trackingThreshold: 30
};

This explains why I'm not seeing the live UI when my stream has less than 30 seconds of data!

Adjusting the threshold value to a more optimistic 5 seconds should ensure we avoid this issue:

const player = videojs('vid', {
  liveTracker: {
    trackingThreshold: 5
  }
});

I need to reduce my server delays back down to 10 seconds to test and confirm this is the cause.

Edit: Setting the threshold to 0 resolved this issue for me!

I'm happy with the behavior now, and I can reduce all my timers to just delay by 15 seconds and have no loading issues. What a pain in the butt that was to fully identify and resolve.

Thanks buddy works for me, well appreciated I would have spent a whole day to figure that out lol