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.

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

Fix for Youtube 'More Videos' overlay reappearing #587

Closed
thunderkid opened this issue Mar 5, 2019 · 3 comments
Closed

Fix for Youtube 'More Videos' overlay reappearing #587

thunderkid opened this issue Mar 5, 2019 · 3 comments

Comments

@thunderkid
Copy link

Consider the demo page https://cookpete.com/react-player/. Now imagine a version of this with a larger video player, eg 60em x 40em. (You need a slightly larger player than the one in the current demo to see this problem since youtube apparently doesn't preemptively show the more-videos overlay unless your player is above a certain size.)

In this larger demo, if you switch to a youtube video, you immediately get the more-videos overlay. You can dismiss it by clicking the 'x'. Switch back and forth between the two youtube videos, starting and stopping them as you wish, and the more-videos overlay won't reappear.
But if you now switch to a Vimeo video, and then back to a youtube video, then the more-videos overlay will reappear. This can be very annoying if your app has a mixed list of videos and the user needs to keep dismissing the same overlay.

I've found a solution to this: If you use

config={{
    youtube: {
        preload: true,
    },
    vimeo: {
        preload: true
    },
}}

then you have to dismiss the overlay only once. Apparently since a youtube player then stays loaded at all times, youtube doesn't feel the need to re-annoy you.

This use of preload is not mentioned in the docs. Are there downsides to this approach, or should it be described there? If so, I could provide a few lines in a PR.

@rijk
Copy link
Contributor

rijk commented Mar 11, 2019

Unfortunately there is no way to hide this anymore (Youtube changed their player):

Note: This parameter is changing on or after September 25, 2018.
After the change, you will not be able to disable related videos. Instead, if the rel parameter is set to 0, related videos will come from the same channel as the video that was just played.

The preload thing is a cool workaround though, at least for your situation.

@thunderkid
Copy link
Author

Right, it's always going to appear at least once, but there's no reason to have it coming back after that.

The preload thing is a bit of a hack as it seems to affect some other stuff too (eg you can't have youtube controls if you choose preload.) I was wondering whether there should be a separate keepAlive option for at least youtube and possibly other players too. Would there be any interest in a PR for this or is it just me?

@cookpete
Copy link
Owner

I can't reproduce this, but it sounds like preload is doing the job, although not the job it was intended to do. The fact that the controls prop doesn't work is an unfortunate side effect of how the YouTube player works – players will have controls either true or false for the lifetime of the player (regardless of the prop changing), and the preload players do not have the controls props passed to them, so they default to false (and so will never show controls).

I'll add a fix that passes the controls prop through to preload players, which will hopefully solve this problem as long as you are passing controls={true} from the very first mount.

albanqoku added a commit to albanqoku/react-player that referenced this issue Feb 24, 2021
Webmaster1116 added a commit to Webmaster1116/video-player that referenced this issue May 20, 2021
webmiraclepro added a commit to webmiraclepro/video-player that referenced this issue Sep 9, 2022
philip-luther added a commit to philip-luther/react-player that referenced this issue Nov 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants