On code 8.3.1, until the last few days, video import brought in both the videos and their thumbnails. However, for the last 2 days or so, it still brings the videos, still copies the thumbnails and poster files to sites/default/files/brightcove/videos/images/thumbnails (resp. posters), but there is no thumbnail association in the video entities: in the brightcove_videos table, the video_*, poster_* and thumbnail_* columns are all empty.

I wonder if it could be related to the recently committed fix for #2867884: Member Function error when trying to view /admin/content/brightcove_video which also touched files.

CommentFileSizeAuthor
#18 brightcove-can_no_longer_get-2873478-13.patch1.54 KBitdevshri
#16 brightcove-can_no_longer_get-2873478-12.patch1.39 KBrelim
#14 brightcove-can_no_longer_get-2873478-11.patch775 bytesfilipeabreu
#10 brightcove-can_no_longer_get-2873478-10.patch872 bytesmarknatividad
#9 brightcove-can_no_longer_get-2873478-9.patch872 bytespingwin4eg
#8 brightcove-can_no_longer_get-2873478-8.patch873 bytesdaniel.nitsche
#7 brightcove-can_no_longer_get-2873478-7.patch2.39 KBpingwin4eg
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fgm created an issue. See original summary.

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm commented

Further diagnostic: this appears to be present if the thumbnail files and fids are already present in the system: the import tries to recreate them with identical names, but fails, at which point instead of adopting the existing file, it just ignores both the old and new files.

jan.mashat’s picture

jan.mashat CreditAttribution: jan.mashat at Pronovix for BrightCove commented
Status: Active » Postponed (maintainer needs more info)

We haven't been able to reproduce this issue:

I've tried to delete the image references from the video entity manually, cleared the caches, and re-synced everything, the images re-appeared. Also, they get updated with the normal flow as well

Are you using the latest code from 8.x-1.x-dev and have you run drush updb?

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm at OSInet commented
Priority: Major » Normal
Status: Postponed (maintainer needs more info) » Active

Yes and here are the steps. Core 8.3.1, latest Brightcove module dev version. Install site. Enable Brightcove. Create an unused file with the exact name of a file in a previous version of an imported video (this happens by migrating files). Run Brightcove full sync. The videos are imported. The files are not, and the base Brightcove_videos table contains NULL for every thumbnail and poster. 

Workaround: delete the files and their entries in filed managed. The next import recreates them. 

With this workaround available, the problem is no longer major at all.

pingwin4eg’s picture

pingwin4eg
Location Zaporizhia 🇺🇦
CreditAttribution: pingwin4eg as a volunteer commented

Got a similar issue - posters and thumbnails are not updated when new image files have the same filenames as old ones.

But I don't actually understand @fgm's point about NULLs in the brightcove_video table. On initial entity creation it has images as it should. Images are simply not being updated for me.

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm at OSInet commented

@pingwin4eg : one specific twist in the situation I described 5 months ago is this: " Create an unused file with the exact name of a file in a previous version of an imported video (this happens by migrating files)", which is not exactly a frequent scenario.

pingwin4eg’s picture

pingwin4eg
Location Zaporizhia 🇺🇦
CreditAttribution: pingwin4eg as a volunteer commented
Status: Active » Needs work
FileSize
brightcove-can_no_longer_get-2873478-7.patch2.39 KB

I've just been experimenting a little, and couldn't figure out any simple way to check whether an image was changed or not.

For example, when I captured a frame to be a poster and a thumbnail, I couldn't get their filemtime()s (they are === FALSE).

So I've made this patch for a workaround with file deletion described above. This is not an actual solution, of course.

daniel.nitsche’s picture

daniel.nitsche CreditAttribution: daniel.nitsche as a volunteer commented
FileSize
brightcove-can_no_longer_get-2873478-8.patch873 bytes

There doesn't seem to be a id or timestamp on images from the brightcove API, but I did think of a potentially simple-ish way to check as an alternative to the patch in #7: using hashes.

The attached patch ignores the filename and instead compares the md5 hash of the local file, and the brightcove file. The only downside to this is it needs to make an additional request to the brightcove API to download and md5 the image.

I'm still doing some testing, but it's working so far.

pingwin4eg’s picture

pingwin4eg
Location Zaporizhia 🇺🇦
CreditAttribution: pingwin4eg as a volunteer commented
FileSize
brightcove-can_no_longer_get-2873478-9.patch872 bytes

Rerolling against current 8.x-1.x.

marknatividad’s picture

marknatividad CreditAttribution: marknatividad as a volunteer and commented
FileSize
brightcove-can_no_longer_get-2873478-10.patch872 bytes

Re-rolling against current 8.x-2.x.

  • yce committed 249d2d2 on 8.x-2.x 
    Issue #2873478 by pingwin4eg, marknatividad, daniel.nitsche: Can no...
yce’s picture

yce CreditAttribution: yce at Pronovix for BrightCove commented

Hi,

Thank you for the patch!

yce’s picture

yce CreditAttribution: yce at Pronovix for BrightCove commented
Status: Needs work » Fixed
filipeabreu’s picture

filipeabreu
Location Campinas/SP
CreditAttribution: filipeabreu commented
FileSize
brightcove-can_no_longer_get-2873478-11.patch775 bytes

Attaching my own patch.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

relim’s picture

relim CreditAttribution: relim commented
FileSize
brightcove-can_no_longer_get-2873478-12.patch1.39 KB

Re-rolling against current 3.x.

itdevshri’s picture

itdevshri CreditAttribution: itdevshri commented
itdevshri’s picture

itdevshri CreditAttribution: itdevshri at Srijan | A Material+ Company commented
FileSize
brightcove-can_no_longer_get-2873478-13.patch1.54 KB

\Drupal::service('file_system')->realPath($file_uri) return false when the images are served from remote location such as S3. This is resulting in errors when passed in the md5_file method. Added, support if current file URI in case the realPath method returns FALSE.

pingwin4eg’s picture

pingwin4eg
Location Zaporizhia 🇺🇦
CreditAttribution: pingwin4eg as a volunteer commented

filipe82sp, relim, itdevshri
The initial issue was fixed and closed. Please update the module on your side.

If you're strongly disagree with the provided solution, please provide your arguments.

Otherwise, if you still have something to add or see another problem, then please start a new issue - https://www.drupal.org/node/add/project-issue/brightcove.

P.S.: Please read on how to make your contribution the most valuable - https://www.drupal.org/association/blog/a-drupal-contribution-guide-gues...