Caching mechanism isn't working

[DanWilkerson]

The caching mechanism, though well intended, isn't working as hoped. This seems to occur whenever we create a new YT.Player, which #36 should address.

[rmeekers]

I have issues with this as well (I think). Some of our web pages have several links to YouTube video's on it. When you click on one of the links, a lightbox becomes visible with the YouTube iFrame.

Every x clicks, I receive an error in the console:

Which refers to this code:

If I add some debugging info, it looks like the API is not yet ready at the moment this function executes.

Any idea how this can be fixed?

[DanWilkerson]

I'm not 100% sure on the cause, but it's reproducible anytime two different scripts call YT.Player and pass in the same element. If you check your source, I'd bet you'll find another call to YT.Player somewhere in there.

I'm working on a fix at the moment that will try and detect if the element has already been associated with a Player object, and if so, to piggyback on to that. YouTube's iframe api keeps track of iframes by their ID or 'widget' + n, where n is a count of players. Hopefully that will rectify your issue, too.

[rmeekers]

From a functional view it's quite random.
We use the YT.Player to trigger the play functionality of the video so that it starts playing as soon as the lightbox with the iFrame has loaded.
It's a single iFrame that we update once a visitor selects another video to play on the same page.

[DanWilkerson]

Right; I have a fix in the latest release - just pushed it up, but Github appears to be down at the moment. Once it's up, try that version. It now will detect if a YT Player has been registered on that element, and if so, simply attach it's events to it. Can't say it will work the opposite way, but it's still an improvement!

Unfortunately, their API doesn't have any kind of checking mechanism in place.

[DanWilkerson]

Take a look at the latest release (8.1.0) and try that. Should fix your issues, and if not, please let me know.