Stop Buffering revisited

[talentville]

I am using videojs with my own homespun playlist, but because there is no way to stop buffering via vjs, when I start to play one video then click on another video to play that one, the system can get hung up, or at least become very slow as the original video, which is still buffering, is hogging the browser resources (or so I believe).

When I switch videos, I am actually pausing then disposing of the old video (with pause() then destroy()), creating a new video tag dynamically to ensure everything is in its initial state for the new video, and I am using the preload="none" tag to avoid autoloading if a user does not actually start playing that video, but the background buffering can be a real issue if a user watches a few seconds of one video then switches to another.

I do not know if there is a way with videojs to completely stop both the video and all buffering once it has begun (and I did read in a previous issue thread that the browser may not be notified to stop buffering), but this issue can become critical with any page that has a playlist of videos that a user can click on to play.

Is this an issue for which there is a solution, and if not what might be the best way to get this done?

[mmcc]

I'm not sure I follow your problem exactly. As stated in the other issue, HTML5 video doesn't provide a way to stop buffering of a video short of changing the src to an empty string (or a new video).

So, with your current implementation, are you saying after a user switches videos the old one continues to buffer? If you're disposing the video element entirely, that should not be the case. If you switch sources on the same video element, that will also stop buffering on the previous element.

My suggestion is to keep an eye on #1050. I've already got everything working in my fork, I just need to get tests finished up. Essentially that fork is a simple fix that resets a player when switch sources, which sounds like it would make your life a good deal easier.

Anyway, closing this one so we can center conversation around the previously mentioned issue.