VideoJS fills WOWZA server Application/Channel with thousands of ghosts connections prior to start...

[musarano]

Description

Briefly describe the issue. We do live streaming for different kind of sources and not all of them are 24/7. We started with VideoJS player.. and 12hrs later, we had the urgency and need to take it down and go back to the former player. I will explain in next section steps to reproduce.

Steps to reproduce

Explain in detail the exact steps necessary to reproduce the issue.

1. We try 7.5.4 - 7.6.0 versions
2. Open the page containing a player that points to an URL that is not yet active, and player hasnt started, either manually or autoplay way.
3. A stream that was playing a working URL, gets disconnected from the far-end( encoder )

Results

for:

1. Exactly same behavior (even some prev. versions)
2. This produces this infinite (while idle) console msg and fill wowza connections limit: VIDEOJS: WARN: Problem encountered with the current HLS playlist. Trying again since it is the final playlist.
3. Same results a #2, only that sometimes the retrying gets Blacklisted and never ever retries again, unless manual reload.

Expected

2-3. Expected to be able to catch the error or event, so we can add a custom msg or some way to deal with it. Or at least a way we can increase the timeperiod() the system re-tries to connect to it. But after a week, its been futile. Please describe what you expected to see. 2-3. A mechanism to implement 2-3 Above (expected)

Actual

If you open a page containing a player that points to an URL that is not yet active, and player hasnt started, either manually or autoplay way, AND If a stream that was playing a working URL, gets disconnected from the far-end( encoder ), Videojs player, will continue to infinite and about every 2-3 secs. will create another fake or ghost connection to the application under wowza server, causing a fast and eventually a stall of the channel for new connections to it.

Error output

If there are any errors at all, please include them here. It seems imposible to change behavior of videojs or a way to handle this kind of situations?

Additional Information

Please include any additional information necessary here. Including the following:

versions

videojs

what version of videojs does this occur with? 7.5.x - 7.6.0

browsers

Chrome, IE, Mozilla, havent test others.

OSes

Try it Windowses.

plugins

are any videojs plugins being used on the page? If so, please list them below. Yes, and none. Same results. videojs alone, HLS, nuevolab (with and without)

[welcome[bot]]

👋 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.

[musarano]

Hi ! Knock knock ... ;)

[gkatsev]

This is the expected behavior. We continue retrying a live playlist indefinitely because we cannot know that it won't return some time in the future. Ideally, an end tag list is returned in the manifest when the live playlist is being stopped. You can listen to the retryplaylist on the tech (example) to handle this case where if it retry the playlist too many times to just shut down the player.

[musarano]

Thank You for replaying back.. -really appreciated. I do also, love the way of continuing re-trying until.. But the issue seems to be to quickly attempts in a 5+secs. period. Is it a way, from the source that an internal variable or something could be modified to at least increase the time to next attempt or to decrease the attempts by secs instead? Or can i do something HERE, like a loop or timeperiod(),delay(),wait() routine, that could hold the videojs from next attempt to retry?

PS: My issue is more addressed for when there wowza channel is not streaming, Or the far end encoder had a problem (internet down over there, or power or disconnection there) There: States as far end encoder or broadcaster.

Thank You in advanced.

  player.tech().on('retryplaylist', () => {
    console.log('retryplaylist');
     *(and do something HERE)*
  });

On Mon, 8 Jul 2019 at 16:32, Gary Katsevman notifications@github.com wrote:

This is the expected behavior. We continue retrying a live playlist indefinitely because we cannot know that it won't return some time in the future. Ideally, an end tag list is returned in the manifest when the live playlist is being stopped. You can listen to the retryplaylist on the tech (example https://github.com/videojs/video.js/issues/5435#issuecomment-471998039) to handle this case where if it retry the playlist too many times to just shut down the player.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/videojs/video.js/issues/6081?email_source=notifications&email_token=ABMFGW7PG6EMRDXPUXK3BOTP6OI6BA5CNFSM4H4LYTJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZODTQY#issuecomment-509360579, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMFGW6QSIWAC7O56HEU2FLP6OI6BANCNFSM4H4LYTJQ .

[gkatsev]

The time that is used to re-request the manifest is dictated by the target duration of the playlist. It may make sense to make some kind of incremental back-off if we're still getting 404s for a long time, but we have no plans to do that just yet.

[musarano]

Outstanding!

Thank You really, & very much Gary. Thanks for taking of your time to replay, Keep the great work going!

Have a nice day!

Dalton J

On Mon, 8 Jul 2019 at 18:22, Gary Katsevman notifications@github.com wrote:

The time that is used to re-request the manifest is dictated by the target duration of the playlist. It may make sense to make some kind of incremental back-off if we're still getting 404s for a long time, but we have no plans to do that just yet.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/videojs/video.js/issues/6081?email_source=notifications&email_token=ABMFGWZF3TLARNUJVHDQMW3P6OVX3A5CNFSM4H4LYTJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZOMN2Y#issuecomment-509396715, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMFGW7YSXS6TEWYQVW27BDP6OVX3ANCNFSM4H4LYTJQ .

[gkatsev]

You're welcome!

What you could try is when you get into retryplaylist, stop the player and set up a timer to re-create/re-set the source on the player.

[musarano]

Thank You for the idea Gary,

Im trying the code:

  player.tech().on('retryplaylist', () => {
    console.log('Got Ya!');
  });

-In my case, my worry thing is that, im trying to connect to a non online/operative IDLE wowza channel, and the retryplaylist is seems never respond to this scenario. The console never reports the "Got Ya!"

Perhaps this would need another approach for this particular cases ?

Dalton J

On Mon, 8 Jul 2019 at 18:38, Gary Katsevman notifications@github.com wrote:

You're welcome!

What you could try is when you get into retryplaylist, stop the player and set up a timer to re-create/re-set the source on the player.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/videojs/video.js/issues/6081?email_source=notifications&email_token=ABMFGW4DEHVKTWA4J2BL6QDP6OXWHA5CNFSM4H4LYTJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZONWLY#issuecomment-509401903, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMFGW4PBYARTWYD76XJRMTP6OXWHANCNFSM4H4LYTJQ .

[musarano]

Hi and maybe the last time i bother you perhaps :)

I finally found why the code above wasn't working.. But, still the attempts are to many, and/or too fast, and the false connections are still increasing more than 100 per minute, or so.

The conditioned code gets fulfilled,and i tried to hold it for about 15-30 secs. but it seems that i wont be able to hold the retries in a secure way.. The warn: ... comes back again, and overpass that code ( the flag keeps appearing, but the execution code, only shows after 5-6 Warn: notices, but for the time you reach a minute, the connections are very high, not as much but still )

I will try your suggestion now.... and if you dont mind, keep you posted.

Thank You

On Mon, 8 Jul 2019 at 18:44, Dalton Acosta daltonacosta@gmail.com wrote:

Thank You for the idea Gary,

Im trying the code:

  player.tech().on('retryplaylist', () => {
    console.log('Got Ya!');
  });

-In my case, my worry thing is that, im trying to connect to a non online/operative IDLE wowza channel, and the retryplaylist is seems never respond to this scenario. The console never reports the "Got Ya!"

Perhaps this would need another approach for this particular cases ?

Dalton J

On Mon, 8 Jul 2019 at 18:38, Gary Katsevman notifications@github.com wrote:

You're welcome!

What you could try is when you get into retryplaylist, stop the player and set up a timer to re-create/re-set the source on the player.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/videojs/video.js/issues/6081?email_source=notifications&email_token=ABMFGW4DEHVKTWA4J2BL6QDP6OXWHA5CNFSM4H4LYTJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZONWLY#issuecomment-509401903, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMFGW4PBYARTWYD76XJRMTP6OXWHANCNFSM4H4LYTJQ .

[musarano]

Hi Gary,

I been trying several options and combinations, it seems that i cannot stop or hold, the connections made to the wowza server anyway Seems like, internally, the calls to the video src, is keep trying, regarding the setTimeout of 15,30,60,120secs. The wowza channel keeps increasing at the same rate as it wasnt any timer. I also tried to blank the document variable for src or source, and havent achieve this either. Any ideas, or other suggestion or the proper way example code to achieve it, will be really useful for a lot of us here...

It is the only reason stopping us from upload this player yet.

Hope this helps.

Thank You

On Mon, 8 Jul 2019 at 23:31, Dalton Acosta daltonacosta@gmail.com wrote:

Hi and maybe the last time i bother you perhaps :)

I finally found why the code above wasn't working.. But, still the attempts are to many, and/or too fast, and the false connections are still increasing more than 100 per minute, or so.

The conditioned code gets fulfilled,and i tried to hold it for about 15-30 secs. but it seems that i wont be able to hold the retries in a secure way.. The warn: ... comes back again, and overpass that code ( the flag keeps appearing, but the execution code, only shows after 5-6 Warn: notices, but for the time you reach a minute, the connections are very high, not as much but still )

I will try your suggestion now.... and if you dont mind, keep you posted.

Thank You

On Mon, 8 Jul 2019 at 18:44, Dalton Acosta daltonacosta@gmail.com wrote:

Thank You for the idea Gary,

Im trying the code:

  player.tech().on('retryplaylist', () => {
    console.log('Got Ya!');
  });

-In my case, my worry thing is that, im trying to connect to a non online/operative IDLE wowza channel, and the retryplaylist is seems never respond to this scenario. The console never reports the "Got Ya!"

Perhaps this would need another approach for this particular cases ?

Dalton J

On Mon, 8 Jul 2019 at 18:38, Gary Katsevman notifications@github.com wrote:

You're welcome!

What you could try is when you get into retryplaylist, stop the player and set up a timer to re-create/re-set the source on the player.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/videojs/video.js/issues/6081?email_source=notifications&email_token=ABMFGW4DEHVKTWA4J2BL6QDP6OXWHA5CNFSM4H4LYTJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZONWLY#issuecomment-509401903, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMFGW4PBYARTWYD76XJRMTP6OXWHANCNFSM4H4LYTJQ .

[gkatsev]

Do you have a live example you can share? Otherwise, it's kind of hard to help at this point.

[musarano]

Hi Gary.

If you can use (without publishing preferable) this mount in your player or so, and let me know around which time you will test it, i can show you how much the connections increment on server side. (in Flowplayer using HLS, i can create a timeperiod of around any given seconds or minutes delay to avoid this situation) please check this: http://www.eleden.net/fmm2/embd.php?broadcast=liveghope

For VideoJS:

url: https://www.eleden.com/liveghope/ngrp:livestream_all/playlist.m3u8 ( No streaming currently, where the issue arise to wowza )

• vs*

url: https://www.eleden.com/livegntv/ngrp:livestream_all/playlist.m3u8 ( Possible streaming now )

Hope this helps.

On Mon, 22 Jul 2019 at 13:46, Gary Katsevman notifications@github.com wrote:

Do you have a live example you can share? Otherwise, it's kind of hard to help at this point.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/videojs/video.js/issues/6081?email_source=notifications&email_token=ABMFGWYSM6CYWQE5J7P37IDQAXW7DA5CNFSM4H4LYTJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2QUBRQ#issuecomment-513884358, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMFGW4O4V76GIIIJWFEGETQAXW7DANCNFSM4H4LYTJQ .

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[musarano]

Hi.. as i told, im patiently waiting for the modification or fix, but always checking the latest builds daily.

Thank you

On Fri, Sep 20, 2019, 4:40 PM stale[bot] notifications@github.com wrote:

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/videojs/video.js/issues/6081?email_source=notifications&email_token=ABMFGW4IYG4JUBHSY76QI4TQKUYKZA5CNFSM4H4LYTJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7H2ETI#issuecomment-533701197, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMFGW4IHUFGC5DVZGRWLPDQKUYKZANCNFSM4H4LYTJQ .

[musarano]

Hi.

Still waiting for this to happens... cannot deploy the player unless safe under not normal circumstances when wowza app, isnt available or suddenly disconnects from encoder side etc..

Hope this helps.

On Fri, 20 Sep 2019 at 17:31, Dalton Acosta daltonacosta@gmail.com wrote:

Hi.. as i told, im patiently waiting for the modification or fix, but always checking the latest builds daily.

Thank you

On Fri, Sep 20, 2019, 4:40 PM stale[bot] notifications@github.com wrote:

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/videojs/video.js/issues/6081?email_source=notifications&email_token=ABMFGW4IYG4JUBHSY76QI4TQKUYKZA5CNFSM4H4LYTJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7H2ETI#issuecomment-533701197, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMFGW4IHUFGC5DVZGRWLPDQKUYKZANCNFSM4H4LYTJQ .

[musarano]

I will add that even, when the player hasnt been started, the count or counter at wowza offline application, going nuts in ascending like crazy, like a new connection count by each 2 - 3 secs, by player. Stalling at the end the application and sometimes the wowza server when many users are in same situation.

Thank You

[himalreddy]

what is the solution to this problem?

[musarano]

Still waiting for information or a fix solution for the issue... im still running with FP7 while this can be fixed. Just waiting for a way, to at least, we can instruct videojs to wait certain time, before next re-try to connect to the livetream/media/server, etc..

Hope this gets addressed..

[himalreddy]

Hi, I found a solution to this issue. You can use https://github.com/streamroot/videojs-hlsjs-plugin plugin on the top of videojs, it will handle both requesting multiple keys from the Wowza server and requesting playlist/segments when video not available at the server side.

I hope this will solve our issues...

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[musarano]

Hi !

Thank You!

But, I had tried on several occasions, but still not able to download or open this URL

Hope this helps :)

On Thu, 5 Dec 2019 at 02:00, himalreddy notifications@github.com wrote:

Hi, I found a solution to this issue. You can use https://cdn.streamroot.io/videojs-hlsjs-plugin/1/stable/videojs-hlsjs-plugin.js http://url plugin on the top of videojs, it will handle both requesting multiple keys from the Wowza server and requesting playlist/segments.

I hope this will solve our issues...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/videojs/video.js/issues/6081?email_source=notifications&email_token=ABMFGW4AGZVQF44G54M23ELQXCKJFA5CNFSM4H4LYTJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF7TA4Q#issuecomment-561983602, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMFGW7XM5FRDEVDVSXMUGTQXCKJFANCNFSM4H4LYTJQ .

[musarano]

Hi !

Well, we are just still holding for news about the implementation fix or workaround of it. I personally still have videojs on hold meanwhile..

Hope this helps

Thank You

On Mon, 3 Feb 2020 at 05:59, stale[bot] notifications@github.com wrote:

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/videojs/video.js/issues/6081?email_source=notifications&email_token=ABMFGW5LS3WPLFW6M6QU2CTRA7THDA5CNFSM4H4LYTJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKTGRTY#issuecomment-581331151, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMFGW2ARTN3LYLQMSR7GK3RA7THDANCNFSM4H4LYTJQ .

[musarano]

Hi,

If you refer to this one: https://github.com/SRGSSR/videojs-hlsjs

It keeps doing the same... Perhaps im trying a wrong version.

On Thu, 5 Dec 2019 at 02:00, himalreddy notifications@github.com wrote:

Hi, I found a solution to this issue. You can use https://cdn.streamroot.io/videojs-hlsjs-plugin/1/stable/videojs-hlsjs-plugin.js http://url plugin on the top of videojs, it will handle both requesting multiple keys from the Wowza server and requesting playlist/segments.

I hope this will solve our issues...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/videojs/video.js/issues/6081?email_source=notifications&email_token=ABMFGW4AGZVQF44G54M23ELQXCKJFA5CNFSM4H4LYTJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF7TA4Q#issuecomment-561983602, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMFGW7XM5FRDEVDVSXMUGTQXCKJFANCNFSM4H4LYTJQ .

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[musarano]

Thank you. It seems never get into the fix. Still unable to use videoJS as I wish, since this is a very bad bug for liveatreaming with wowza, where at the end, make wowza unstable or to hang., There is tooo many of hundreds or thousands of fake connections to it. Since there is no way to delay the next try to reconnect to wowza, instead it does it every 2 or 3 secs without stopping.

Is sad that this never get Into care enough.

On Fri, Apr 3, 2020, 8:59 AM stale[bot] notifications@github.com wrote:

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/videojs/video.js/issues/6081#issuecomment-608419173, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMFGW7NSQXK4RWF72RRJMTRKXMTDANCNFSM4H4LYTJQ .

[Ddog800]

I'm glad I just came across this. I'm literally in the process of replacing the Wowza player (which is being discontinued) with video.js and have spent over a week testing and implementing this. I was trying to figure out how to detect the loss of the stream for the sake of simply overlaying a friendly message for our users, but I didn't realize it would be flooding our backend Wowza server with these attempts. Now that I'm monitoring the JS console, I see the repeated attempts. That could have caused us major problems once we went live with the new player.

I guess I'll to ahead and take a stab at trying to figure something out on the player side. I will reply back with the results of my testing.

[musarano]

Awesome ! Hope you can find a way !

Good luck with this !

On Tue, May 26, 2020, 2:53 PM Daniel Guidry notifications@github.com wrote:

I'm glad I just came across this. I'm literally in the process of replacing the Wowza player (which is being discontinued) with video.js and have spent over a week testing and implementing this. I was trying to figure out how to detect the loss of the stream for the sake of simply overlaying a friendly message for our users, but I didn't realize it would be flooding our backend Wowza server with these attempts. Now that I'm monitoring the JS console, I see the repeated attempts. That could have caused us major problems once we went live with the new player.

I guess I'll to ahead and take a stab at trying to figure something out on the player side. I will reply back with the results of my testing.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/videojs/video.js/issues/6081#issuecomment-634211683, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMFGW7P5RD4XHJC6XVOKITRTQF25ANCNFSM4H4LYTJQ .

[Ddog800]

OK, I've been testing this since I last commented and it seems to be working well. I don't know exactly how you're implementing the player in your code, so I'll just demonstrate below how I'm doing it in mine and hopefully that will put you on the right track.

The code snippet that @gkatsev originally referenced for handling the 'retryplaylist' event, which is what is thrown once the player continues looking for the next chunk of the stream and gets a 404, seems to work well. In my testing, I am handling the event and then resetting the player using the player reset() method. I'm not 100% sure what all reset() does (it's not well documented and I haven't exactly dug through the video.js code), but from what I can tell in my testing, it appears to leave the player the state in which it was initialized (i.e. same options are in place) but it definitely resets the player.src to null.

Once the source is null, then the player will no longer attempt to keep connecting. At that point, you can do whatever else you want like display a modal saying the stream has ended or do an ajax call or whatever you like.

The event listener can be set up and handled when you initialize the player. Here's a simplified version of my code so you can see what I'm doing:

<video id="videoPlayer" class="video-js vjs-big-play-centered vjs-fluid vjs-live">
  <p class="vjs-no-js">
    To view this video please enable JavaScript, and consider upgrading to a
    web browser that
    <a href="https://videojs.com/html5-video-support/" target="_blank">
      supports HTML5 video
    </a>
  </p>
</video>

<script>
  var options = {
    // set up all your options
    // .....
  };

  videojs('videoPlayer', options, function() {
    // Do any other initialization stuff you need

    // Set up event handler for 'retryplaylist' event
    this.tech().on('retryplaylist', () => {
      // Reset the player, which sets the source to null
      this.reset();
      console.log('Player reset after retryplaylist event fired'); // Logging to console while testing this
      // Pausing player to stop the spinning busy indicator
      this.pause(); 
      console.log('Paused player'); // Logging to console while testing this
      // Do whatever you might need. I'll probably throw up a modal saying the stream has ended
    });
</script>

So this is pretty much it. I've tested it against my a stream from our Wowza server and it seems to be working well. Once this.reset() is called, the console throws up an error about source being null (as expected) and then it stops trying attempting to retry. A few times I've noticed it would try one more time after that, but I think that just has to do with the timing of when the event fires and when reset() is called which is probably based on the length of your chunks sent by the Wowza server and some timeout somewhere, stuff like that. Otherwise, it pretty much halts activity from the player.

At that point you can do whatever you want that makes sense for your user experience.

I hope this helps, and please let me know if you have any more questions about any of this!

[musarano]

This is awesome Daniel !!

I promise you, that i will jump into this ASAP, from now, since im beginning to make an algorithm of all changes i will need to make with our selves and all sides of customers ones. APPS, URLs at pages, encodings, decodings, external ref. pages, and among that, our own APPS, current Flowplayer 7.x self customized, etc etc. move server software to other server machines, and begin the pain in the neck transition and migration, and at the same time creating each one of the customers and streaming resources for them one time.. After this, i will definitely jump into the videoJS research and achievements you have found with your tests!

I will definitely do so, even i will try to find some time to do so before all that :)

Really appreciated your help and consideration fully explaining all this :) definitely i will get back to you !

Again, a BIG THANK YOU !

-DJA

On Wed, 27 May 2020 at 15:20, Daniel Guidry notifications@github.com wrote:

OK, I've been testing this since I last commented and it seems to be working well. I don't know exactly how you're implementing the player in your code, so I'll just demonstrate below how I'm doing it in mine and hopefully that will put you on the right track.

The code snippet that @gkatsev https://github.com/gkatsev originally referenced for handling the 'retryplaylist' event, which is what is thrown once the player continues looking for the next chunk of the stream and gets a 404, seems to work well. In my testing, I am handling the event and then resetting the player using the player reset() method. I'm not 100% sure what all reset() does (it's not well documented and I haven't exactly dug through the video.js code), but from what I can tell in my testing, it appears to leave the player the state in which it was initialized (i.e. same options are in place) but it definitely resets the player.src to null.

Once the source is null, then the player will no longer attempt to keep connecting. At that point, you can do whatever else you want like display a modal saying the stream has ended or do an ajax call or whatever you like.

The event listener can be set up and handled when you initialize the player. Here's a simplified version of my code so you can see what I'm doing:

Githubissues.

Githubissues is a development platform for aggregating issues.