Thumbnails showing support video

Thumbnails can be accessed via a certain URL, so really no need to use the API to access them. This patch should do the trick.

I am also experiencing this. The patch doesn't seem to work either - these are the type of URL it is now returning: http://i.ytimg.com/vi/UKY3scPIMd8/sddefault.jpg

I can confirm that the patch is not working... :(
Will keep an eye here for updates - thanks!

@mstrelan is right, there's a way to access previews via URL and since the new v3 API requires the use of private key, this may be the best route. However there maybe be other reasons to rely on the API which I'm not aware of.

Anyway, in the meantime, here's another patch which solved the problem for me (it's done against the current release).

If you created videos recently and want to get ride of the bogus preview files, you'll have to delete them manually from your sites/files/youtube (or similar) folder in order to force the module to recreate them, otherwise the patch will work only for new nodes.

Patch from #4 works like a charm. Thanks @Proteo!

Dont forget to refresh the image cache and delete the "/sites/default/files/youtube" broken thumbnails.
Or run drush image-flush youtube via SSH or your Local Drush environment.

If you have a lot of videos and dont want to re-create all thumbnails just delete the latest files ordering them by date. Thats what i did.

Glad it worked. Actually, the patch is intedended as an "emergency measure", not to be added to the code base. I'd like to hear the thoughts from guschilds (the maintainer) about using the API vs using a plain URL. I have the feeling that relying on a hardcoded URL may be "flimsy" in the long run, but I really don't know.

If sticking to the URL makes sense, we need to check what's the best URL to use (there's something like a "canonical" URL??). After submitting the patch, I learned that people around the net are using a few different URLs all of which seems to be working now, but that doesn't mean they always will work.

Thanks for patch #4 Proteo, worked a treat.

My youtube thumbnails started showing support thumbnails. Can someone tell me the best way to resolve this. There were some doubts raised in #6.

FWIW the media_youtube module uses the direct URL method.

I'd like to confirm that patch from #4 works. Thank you, @Proteo!

For those who don't see changes after patching -- you should also "Refresh existing thumbnail image files" on page /admin/config/media/youtube .
If you are using thumbnails with styles, then imagestyleflush module will be very helpful.

ps: will be great to add ability to upload custom thumbnail for video to suffer such issue in the future.

Thanks to everyone who has contributed to this issue!

Proteo's solution in #4 is exactly what I'd have done. As for his concerns in #6, I don't honestly know if there are any advantages to using the API rather than hitting the image path directly. The module was already using the API to fetch the image path when I inherited the codebase. I added the direct image path approach when grabbing the high res image because it wasn't available through the API. I'm willing to bet that the API is theoretically more reliable, but I'm not sure that I've ever run into the direct URL not returning a proper thumbnail for a video. I'm also willing to bet that any increase in reliability the API brings is not worth requiring everyone that uses the module to register an API key. I think it'd be best to avoid that as long as possible.

Developers: Go ahead and use the patch in #4, as it will likely be what is committed. Follow the directions in the previous comments to clear the support video images that were downloaded before you applied the patch.

Proteo (thank you!): my one question about your patch is why you've switched the image path base to i1.ytimg.com? img.youtube.com seems to still work and I'm hesitant to change it unless there is a known reason. I haven't researched this in a while. As far as I know, the URLs constructed in youtube_build_remote_image_path() are still the most commonly used. Have you seen evidence for otherwise?

Once we've determined the answer to that question I'll commit the result and, due to the priority of the issue, will probably create a 7.x-1.6 release. It may just require widespread use to determine whether or not this is the right long term solution.

You're welcome Gus. About the URL: there's no reason to change the URL. I used i1.ytimg.com just because I saw it in some examples in the net and it worked: After submitting the patch I also noticed that the current one works just fine and is more widely used.

So, I think that settles this thing! I'm attaching a proper patch done against the current 7.x-1.x branch, in case you need it. Best regards.

Sorry, the previous patch file was empty for some reason. Attaching another one.

Hi @Proteo - are you sure the final patch submitted on #15 is complete? It appears to be missing the function call to build the remote image url - or am I reading this wrong - and you're using the previous url (probably I'm reading this wrong). Thanks for the patch.

I'd like to confirm that patch from #15 works.
Thank you @Proteo

@blue_waters yes the patch in #15 is complete. All it does is to remove the code which makes the Youtube API call, no other changes needed since the currently used URL works fine.

Thanks Proteo, I can also confirm that patch #15 works. (just don't forget to clear your image-caches...)

Patch from #15 works, but it eliminate v2 lines.

If Google continue deprecating v2 things, this module can be patched to use v3 api key?

@SoportePRO: so far, there's no evidence that the API offer any advantages (see the comments in #12), and v3 makes the use of a private key mandatory (which is not a problem per se, but it is inconvenient for many).

Does this patch need a review still?

This fix has been committed and is included in the 7.x-1.6 release. If support video thumbnails persist after updating the module, please be sure to flush your download YouTube thumbnails as mentioned earlier in this thread.

I've also committed the same fix to the 8.x-1.x branch.

Thanks for everyones help with patches and reviews!