Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
musarano opened this issue Jun 30, 2019 · 35 comments
Closed

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

musarano opened this issue Jun 30, 2019 · 35 comments
Labels
outdated Things closed automatically by stalebot

Comments

@musarano
Copy link

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 Missing license? #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
Copy link

welcome bot commented Jun 30, 2019

👋 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
Copy link
Author

musarano commented Jul 2, 2019

Hi ! Knock knock ... ;)

@gkatsev
Copy link
Member

gkatsev commented Jul 8, 2019

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
Copy link
Author

musarano commented Jul 8, 2019 via email

@gkatsev
Copy link
Member

gkatsev commented Jul 8, 2019

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
Copy link
Author

musarano commented Jul 8, 2019 via email

@gkatsev
Copy link
Member

gkatsev commented Jul 8, 2019

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
Copy link
Author

musarano commented Jul 8, 2019 via email

@musarano
Copy link
Author

musarano commented Jul 9, 2019 via email

@musarano
Copy link
Author

musarano commented Jul 12, 2019 via email

@gkatsev
Copy link
Member

gkatsev commented Jul 22, 2019

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

@musarano
Copy link
Author

musarano commented Jul 22, 2019 via email

@gkatsev gkatsev mentioned this issue Jul 26, 2019
Closed
@stale
Copy link

stale bot commented Sep 20, 2019

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.

@stale stale bot added the outdated Things closed automatically by stalebot label Sep 20, 2019
@musarano
Copy link
Author

musarano commented Sep 20, 2019 via email

@stale stale bot removed the outdated Things closed automatically by stalebot label Sep 20, 2019
@musarano
Copy link
Author

musarano commented Sep 23, 2019 via email

@musarano
Copy link
Author

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
Copy link

what is the solution to this problem?

@musarano
Copy link
Author

musarano commented Dec 4, 2019

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
Copy link

himalreddy commented Dec 5, 2019 •
edited
Loading

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
Copy link

stale bot commented Feb 3, 2020

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.

@stale stale bot added the outdated Things closed automatically by stalebot label Feb 3, 2020
@musarano
Copy link
Author

musarano commented Feb 3, 2020 via email

@stale stale bot removed the outdated Things closed automatically by stalebot label Feb 3, 2020
@musarano
Copy link
Author

musarano commented Feb 3, 2020 via email

@musarano
Copy link
Author

musarano commented Feb 3, 2020 via email

@stale
Copy link

stale bot commented Apr 3, 2020

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.

@stale stale bot added the outdated Things closed automatically by stalebot label Apr 3, 2020
@musarano
Copy link
Author

musarano commented Apr 3, 2020 via email

@stale stale bot removed the outdated Things closed automatically by stalebot label Apr 3, 2020
@Ddog800
Copy link

Ddog800 commented May 26, 2020

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
Copy link
Author

musarano commented May 26, 2020 via email

@Ddog800
Copy link

Ddog800 commented May 27, 2020 •
edited
Loading

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
Copy link
Author

musarano commented May 27, 2020 via email

@stale
Copy link

stale bot commented Jul 29, 2020

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.

@stale stale bot added the outdated Things closed automatically by stalebot label Jul 29, 2020
@Nyceane
Copy link

Nyceane commented Aug 1, 2020

hmm, this does not work with videojs 7+ as we can't load hlsjs anymore

@stale stale bot removed the outdated Things closed automatically by stalebot label Aug 1, 2020
@dioramayuanito
Copy link

dioramayuanito commented Aug 1, 2020 •
edited
Loading

https://www.detik.com/transmedia

detikVideo uses:

videojs v7.6.6
videojs-hlsjs-plugin v1.0.5 (hls.js v0.8.9)
wowza streaming engine v4.7.7
https://cdn.detik.net.id/detikVideo/lib/videojs-hlsjs-plugin.v1.0.5.js

it works well

we can get videojs-hlsjs-plugin from
https://www.jsdelivr.com/package/npm/videojs-hlsjs-plugin
or
https://github.com/streamroot/videojs-hlsjs-plugin (latest)

@dioramayuanito
Copy link

latest https://cdn.streamroot.io/videojs-hlsjs-plugin/1/stable/videojs-hlsjs-plugin.js (hls.js v0.13.2)

@gkatsev
Copy link
Member

gkatsev commented Aug 5, 2020

hmm, this does not work with videojs 7+ as we can't load hlsjs anymore

There shouldn't be anything stopping you from using hlsjs if you want.

@stale
Copy link

stale bot commented Oct 4, 2020

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.

@stale stale bot added the outdated Things closed automatically by stalebot label Oct 4, 2020
@stale stale bot closed this as completed Oct 12, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 25, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
outdated Things closed automatically by stalebot
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@dioramayuanito @Nyceane @gkatsev @musarano @Ddog800 @himalreddy