🇭🇺Hungary @yce

I don't see the benefit why it would be good to render the video player inside the ckeditor, so I would say it is works as designed.

You can also override the template of the video from your theme if needed and create custom displays to customize how it should be rendered.

Hi,

The theming of the displays should be the task of who integrates the module into a project.

The default templates are representing the official embed code from the Brightcove studio and as such should be good enough to get started. I would rather not deviate from that.

The templates can be overridden by a custom theme.

This is a feature request.

Probably the Video entity storage needs to be extended to find/load references from the remote repository.

Feel free to provide a patch/MR with a proposed solution.

Seems like a feature request. It works as designed.

The original goal was to prevent overwhelming Drupal by introducing a semaphore to hold off multiple simultaneous requests from Brightcove as even uploading a single video could cause desynchronization/inconsistency without a semaphore.
If I remember correctly the notification subscription support was introduced later in the module, and the mass create/delete was not considered as an issue at the time.

Although moving from away from semaphore to using queue to process the notifications could slow down the sync even more as every queue item needs to be processed in order to achieve full synchronization.

The queue system is already overwhelmed with the entity sync.

Currently there is no plan to support limited API access, the module requires full API access.

This is more like a feature request.

As of today, the IEF seems to be working with the Video entity.

Requested features:

1. Add default encoding profile field for the Brightcove API Client config entity.
   Add option to the Video forms to use the default encoding profile.
2. Allow restricting specific encoding profiles per API Client. (role based?)

Please provide a patch/MR with the proposed changes.

@bsains Thanks for checking, based on your comment I'm closing this ticket.

Okay, so the description field gets updated properly to have the length of 500.
I have tested the update path using MySQL 5.7.44, PHP 8.2.25, Drupal 10.3.

Regarding the error message I've found that the entity definition needs to be (re-)installed, seems to solve the issue.

I've pushed the fix to the latest dev.

The specification says it's a non-nullable string: https://apis.support.brightcove.com/cms/references/reference.html#tag/Cu...

However, the API responds with an integer and based on the error message it can be null.

I've pushed a simpler fix to dev, casting NULL to int results in a 0 value.

Hi @imran1217,

Can you please elaborate on the 2nd step?

I've tried to add the video to ckeditor using the media module, but I only see the video's title, the player does not load at all.

However the script shouldn't run in the ckeditor anyway (on the node edit form), I would rather display the preview or thumbnail image in the editor instead, much safer. It may require some customization though.

Okay, can you please provide how to reproduce the issue?

Also, can you provide the used database type/version, php and Drupal versions?

Are you sure that this update ran successfully?

On a local dev environment, I was able to upgrade to 3.2.1 from 3.2.0.
I can see the increased size of the column in the database which after the sync run successfully.

Hi,

There is an update hook for that: brightcove_update_8114().
Updating from 3.2.0 to 3.2.1 and running database updates should increase the description field's to 500.

Is it still an issue with Drupal 10.2 (or above) and Brightcove 3.2.0?

As part of another issue I've just tested s3fs and I did not notice any errors now.

Hi,

I've looked into the issue, by setting up and using a local MinIO server (s3 compatible storage) and configured s3fs to push the files there.
Based on my test, saving the image to the s3 storage was done in 2ms for a newly uploaded video.

As I see the issue is with either the s3 storage, or the s3fs contrib module.
The Brightcove module is just using the 'file.repository' service to write the image data, in other words it propagates the task to core/s3fs.

Thanks, pushed to dev 3.2.x-dev.

yce → created an issue.

Hi,

I would still try to calculate the hash for the file in case of remote paths.

Seems like passing the file URI as-is to the md5_file() function works.
I've also added a condition to make sure that the file exist before the hash calculation is attempted.

Please let me know if it works for you as well.

Hiding incorrect patch as the stream_copy_to_stream() requires resource for the first two arguments, not filename strings.
https://www.php.net/manual/en/function.stream-copy-to-stream.php

yce → created an issue.

Luke.Leber → credited yce → .

Hi,

It is fixed in the latest dev (3.1.x, 3.2.x).

I'm going to mark this ticket as fixed. A new 3.2.0 release is available that has the Drupal 10 compatibility.

You are right, I was just checking the current version that defaults to NULL if accessCheck() not called explicitly that's why I assumed it was "falsey" by default.

FTR, it is TRUE since 8.0.x by default, behavior changed from 9.2.0 where it defaults to NULL and requires the accessCheck() to called explicitly.

I'm going to change it back.

Hi @heddn,

Thanks for the patch, I've reviewed it, looks okay so I've pushed to dev.
I've also changed the access checks to false, just to keep the original functionality.

yce → created an issue.

yce → created an issue.