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

Preload keep playing the first track that was played with it #264

Closed
SkinyMonkey opened this issue Oct 31, 2017 · 10 comments
Closed

Preload keep playing the first track that was played with it #264

SkinyMonkey opened this issue Oct 31, 2017 · 10 comments

Comments

@SkinyMonkey
Copy link
Contributor

In the demo/App.js file I created a playlist with urls from the different providers.
2 from youtube, 2 from soundcloud and 2 from vimeo.
Like this:

const LINKS = [
  'https://www.youtube.com/watch?v=oUFJJNQGwhk'
 ,'https://www.youtube.com/watch?v=jNgP6d9HraI'
 ,'https://soundcloud.com/miami-nights-1984/accelerated'
 ,'https://soundcloud.com/tycho/tycho-awake'
 ,'https://vimeo.com/90509568'
 ,'https://vimeo.com/169599296'
]

Along with buttons to switch to the next or previous url.

The 2 first videos play fine.
But as soon as it switch to the third one, the provider change and the youtube preload plays the first video in the background. Without any control possible over it.

If I check into the React tree ai can see that the silent video url is a prop of the preload player.
But if I check the element tree directly, the youtube iframe points to the first video of the playlist.

I tried to debug this but could not track down the problem.

I pushed my code to my fork github repo if you have time to check it:

https://github.com/SkinyMonkey/react-player/tree/bug-playlist-problem

@SkinyMonkey SkinyMonkey changed the title Preload plays keep playing the first track that was played with it Preload keep playing the first track that was played with it Oct 31, 2017
@cookpete
Copy link
Owner

The youtube iframe should be playing the blank video but hidden away. Is this not happening? I have checked out your branch and it seems to work correctly. Or, are you saying that the youtube blank video should only play on first load, if the video you are playing is not youtube?

I guess the preload players only ever need to render/play on the first load of ReactPlayer, when the browser is likely to be in focus, but..

I wonder if the preload effect still works if a player is "primed", but then unmounts and remounts later? If not then we will need a solution that keeps the players "alive" whilst other media is playing (like you describe is happening now), but possibly that doesn't involve playing the whole blank video again.

@SkinyMonkey
Copy link
Contributor Author

SkinyMonkey commented Oct 31, 2017

Ok let's detail what i meant.

This is the behaviour I get step by step on my branch.

0 - I load the page.
1 - It plays the first video automatically, the preloads for soundcloud and dailymotion play the silent links
2 - I click next, the youtube videos plays, the preloads for soundcloud and dailymotion are still ok
3 - i click next again, the soundcloud video plays the right URL, the youtube loader plays the first video at the same time, the dailymotion one seem ok

If i check the url props in react at this moment I get the right URL for youtube, the silent one but if i check the src in the iframe element the youtube frame is still pointing to the first video.

I can reproduce each time on my branch. No exception.

I got the same behaviour in another app i'm working on so there's definitly something going on.

@SkinyMonkey
Copy link
Contributor Author

Here is a youtube video demonstrating the problem:

https://www.youtube.com/watch?v=MvU5jGrzUqo&feature=youtu.be

@SkinyMonkey
Copy link
Contributor Author

Ok, I found a workaround.

What I think the problem is :
The src of the embed in the iframe does not change.

If you don't initialize react player with null or a silent video as url props and start by a youtube video the youtube iframe will get stuck to the first video it played and read it again when the player is used as a 'preload player'.

The solution I found :

What I did in my App : instead of instantiating the react player when the playlist is filled with something I always create it and simply hide it.
That way the first time it instantiate the players with the silent videos as first values and everything works fine.

@cookpete
Copy link
Owner

cookpete commented Nov 1, 2017

I understand the problem now. For some reason the youtube player is not reverting to the preload video correctly, and plays whatever it played last, even though this.player.cueVideoById() is being called with the correct preload URL.

The iframe URL not changing is a red herring: That is expected behaviour when switching from using new YT.Player() to instatiate the player, to this.player.cueVideoById() to load an existing player with a new video.

@SkinyMonkey
Copy link
Contributor Author

Ok, the iframe src not changing is a bit counterintuitive but it makes sense since we reuse the same player.

Tell me if you need more informations.
I found an other issue that might be linked to this one.

@cookpete
Copy link
Owner

cookpete commented Nov 8, 2017

After some more investigation I think I know the problem.

The order of the players in this array seems to be causing the problem. It seems to only happen when the player is switched with another player in the array of players. The array is keyed using the displayName of each player (so components aren't unmounted/remounted) but it still seems to affect the YT iframe.

The YouTube iframe does not do the weird reload error if another player is simply prepending to the array (like if you are preloading YT, SC and Vimeo and then load a Vidme URL). It only happens when you switch from a youtube URL (whilst preloading SC and Vimeo) to a SC or Vimeo URL.

Probably easier with an example:

// Simplified player array, `-p` means preloading

// Load youtube URL, preload SC and Vimeo:
['yt', 'sc-p', 'vim-p']

// Then load SC URL
['sc', 'yt-p', 'vim-p'] // yt and sc switch, yt breaks

But it works when you prepend to the array:

// Load youtube URL, preload SC and Vimeo:
['yt', 'sc-p', 'vim-p']

// Then load vidme URL
['vid', 'yt-p', 'sc-p', 'vim-p'] // Nothing switches, yt works

A possible fix: sort the player array by key so it is never shuffled (weird but it seems to work)

// Load youtube URL, preload SC and Vimeo:
['yt', 'sc-p', 'vim-p']

// Then load SC URL (but keep the order)
['yt-p', 'sc', 'vim-p'] // Nothing switches, yt works

See c769a7a from the fix-preload-bug branch for an example of a possible fix. If it works I'm happy to use it and update the logic but I would love to know why this is happening.

Probably related to this:

<iframe>s reload whenever they are reattached to the DOM. So it might not be reasonable to expect this to work. Consider two frames that need to trade places. One has to get removed from the DOM and reattached, no matter what you do. Hoping to get away with lucky re-renderings is a recipe for fragile code.

From facebook/react#858 (comment)

@cookpete
Copy link
Owner

cookpete commented Nov 8, 2017

@SkinyMonkey See if you get any errors with react-player@1.0.0-beta.4

@SkinyMonkey
Copy link
Contributor Author

It seems to work beautifully now!

If there is further problem i'll try to investigate this too.

I think the issue you point in facebook/react#858 is a very reasonable explanation though.

Thank a lot for investigating this! :)

@cookpete
Copy link
Owner

cookpete commented Nov 9, 2017

See if you get any errors with react-player@1.0.0-beta.4

Note that I have (stupidly) just unpublished 1.0.0-beta.4 to try and correct a tagging problem. I have emailed support to try and republish it. I will publish a 1.0.0-beta.5 at some point soon anyway. But it's good to know that this fixes the problem.

david-hub024 pushed a commit to david-hub024/React_VideoPlayer that referenced this issue Dec 23, 2018
…players

Fixes cookpete/react-player#264 and should fix cookpete/react-player#265

Preload players were behaving strangely when iframes were removed and replaced in the DOM, even if the players weren't being unmounted/remounted by React

Sorting the players array by key will prevent any iframes from being unnecessarily removed/replaced in the DOM
david-hub024 pushed a commit to david-hub024/React_VideoPlayer that referenced this issue May 23, 2020
…players

Fixes cookpete/react-player#264 and should fix cookpete/react-player#265

Preload players were behaving strangely when iframes were removed and replaced in the DOM, even if the players weren't being unmounted/remounted by React

Sorting the players array by key will prevent any iframes from being unnecessarily removed/replaced in the DOM
albanqoku added a commit to albanqoku/react-player that referenced this issue Feb 24, 2021
…players

Fixes cookpete/react-player#264 and should fix cookpete/react-player#265

Preload players were behaving strangely when iframes were removed and replaced in the DOM, even if the players weren't being unmounted/remounted by React

Sorting the players array by key will prevent any iframes from being unnecessarily removed/replaced in the DOM
Webmaster1116 added a commit to Webmaster1116/video-player that referenced this issue May 20, 2021
…players

Fixes cookpete/react-player#264 and should fix cookpete/react-player#265

Preload players were behaving strangely when iframes were removed and replaced in the DOM, even if the players weren't being unmounted/remounted by React

Sorting the players array by key will prevent any iframes from being unnecessarily removed/replaced in the DOM
webmiraclepro added a commit to webmiraclepro/video-player that referenced this issue Sep 9, 2022
…players

Fixes cookpete/react-player#264 and should fix cookpete/react-player#265

Preload players were behaving strangely when iframes were removed and replaced in the DOM, even if the players weren't being unmounted/remounted by React

Sorting the players array by key will prevent any iframes from being unnecessarily removed/replaced in the DOM
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

2 participants