Preload keep playing the first track that was played with it

[SkinyMonkey]

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

[cookpete]

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]

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]

Here is a youtube video demonstrating the problem:

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

[SkinyMonkey]

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]

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]

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]

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]

@SkinyMonkey See if you get any errors with [email protected]

[SkinyMonkey]

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]

See if you get any errors with [email protected]

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.