The thumbnail generation for private videos on Vimeo does not load the images because the thumbnail is loaded via Simple API instead of the Advanced API that loads the images via oEmbed.
As quoted from vimeo for the same issue in Media:Vimeo in http://drupal.org/node/1587686:

The Simple API is for public data only. If your videos are private, you will need to use the Advanced API. If your video is set to hide from vimeo.com, but is embeddable, you may also be able to use oEmbed.

Attached is a patch that use the Advanced API for image loading.

Comments

Status:Active» Reviewed & tested by the community

Code makes sense and running into the problem it works so I set it to rtbc

Status:Reviewed & tested by the community» Needs work

This does result in the thumbnails being correctly generated. However, its throwing this error in various places involving the field.

Strict warning: Only variables should be passed by reference in template_preprocess_video_embed_field_embed_code() (line 355 of /.../sites/all/modules/video_embed_field/video_embed_field.module).

Status:Needs work» Active

Hi mrwiner,
I' not able to reproduce the error. Can you give me some hints to check it?

I can try to, but there doesn't seem to be a really solid way for me to reproduce it.

When I just went to the site, it popped up on the home page. I'm assuming because right now it's the default front page with a feed of content, and the content displayed in that feed contains video embed fields.

It also pops up for me when I visit the edit form for a node with a populated video embed field, as well as in the form for a view that utilizes the thumbnails. For the most parts it seems like the error is thrown once, and then doesn't display unless content is re-saved. So if I save a node that has a thumbnail and go to edit it, the error doesn't show until after I save it again, at which point the error shows again on the edit page. Re-saving did not cause the homepage error to show again, so I don't know how often it refreshes on there. Not sure when it decides to pop up on the view edit page.

Nothing seems to be affected by the error besides the fact that it's there, though.

I don't know if this is directly related with the patch, but following this http://drupal.stackexchange.com/questions/6322/strict-warning-only-variables-should-be-passed-by-reference-in-include maybe changing how the call to drupal_render can help. In vimeo_embed_field.module line 355, replace

    $variables['embed_code'] = drupal_render(call_user_func($handler['function'], $variables['url'], $variables['style_settings']));

with
    $embed = call_user_func($handler['function'], $variables['url'], $variables['style_settings']);
    $variables['embed_code'] = drupal_render($embed);

Again, I'm not able to make the warning appear in the views or administration pages, so I'm guessing a bit here.

Status:Active» Reviewed & tested by the community

Yup, changing that line that seems to have done the trick. Not sure how to create patches though, so that's on you. :)

EDIT: Woops, accidentally changed the status. I guess it's pre-emptive, but if a patch with the change is submitted then the status will be accurate.

Too late, this issue is already fixed on 7.x-2.x-dev :). Check https://drupal.org/node/1913720

Status:Reviewed & tested by the community» Needs review
StatusFileSize
new1.13 KB

@dpliscoff: Tested your patch and it works great. I've updated the patch since it wasn't applying cleanly for me, and gave you attribution. Setting back to needs review for a final check on this patch. This is against 7.x-2.x HEAD. Thanks!

Updated patch that removes some whitespace.

Status:Needs review» Reviewed & tested by the community

@vinmassaro Thanks. Tested your patch on 7.x-2.x-dev and works ok. Back to RTBC.

Private videos can sometimes have urls where there are multiple other codes and variables. This addresses this issue. Seems to be working fine on my end.

Version:7.x-2.0-beta5» 7.x-2.x-dev

The current stock 7.x-2.x-dev branch doesn't fix the issue.

The patch in #9 applies cleanly agains the current 7.x-2.x-dev version and fixes the issue.
Let's get this committed?

(The patch in #11 didn't apply cleanly)

Issue summary:View changes

Thanks for this thread...it was super helpful for me. Patch #9 won't apply to beta7, but of course can be applied manually, which worked great.

Is it likely this will get committed on a future release?