When using "Convert video on save"

The following error occurs and no video content can be created.
I'm not sure if this is caused by the latest version of Video module or latest version of Drupal. I know it worked before.

PDOException: SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction: UPDATE {video_queue} SET entity_type=:db_update_placeholder_0, entity_id=:db_update_placeholder_1, status=:db_update_placeholder_2, dimensions=:db_update_placeholder_3, duration=:db_update_placeholder_4, started=:db_update_placeholder_5, completed=:db_update_placeholder_6, statusupdated=:db_update_placeholder_7, data=:db_update_placeholder_8 WHERE (fid = :db_condition_placeholder_0) ; Array ( [:db_update_placeholder_0] => node [:db_update_placeholder_1] => 36382 [:db_update_placeholder_2] => 5 [:db_update_placeholder_3] => 640x360 [:db_update_placeholder_4] => 0 [:db_update_placeholder_5] => 1499183238 [:db_update_placeholder_6] => 0 [:db_update_placeholder_7] => 1499183238 [:db_update_placeholder_8] => a:3:{s:10:"field_name";s:11:"field_video";s:8:"langcode";s:3:"und";s:5:"delta";i:0;} [:db_condition_placeholder_0] => 63952 ) in drupal_write_record() (Zeile 7383 von /xxx/includes/common.inc).

Using cron to convert the videos works so far (using zencoder for conversion)

CommentFileSizeAuthor
#10 video-general_error_1205_db_lock-2892164-10.patch1.5 KBjeni_dc
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

slowflyer created an issue. See original summary.

voughndutch’s picture

voughndutch CreditAttribution: voughndutch commented

I confirm I am having this issue as well

hermes_costell’s picture

hermes_costell CreditAttribution: hermes_costell as a volunteer commented

I have narrowed the issue down to the db_close(array('target' => 'default')); statement in includes/Transcoder.inc on line 198. When this is commented out the transcoding completes and everything seems fine.

With the db_close() statement left in, it results in a locked out situation in the database (in my particular setup, anyways). The query thread calling the db_close() appears to still have a lock of some kind on the tables which the following queries need to access, causing mysql to time out and then ROLLBACK the queries which would have saved the node.

This took quite a bit of looking at the mysql query log and cross-referencing with 

SHOW FULL PROCESSLIST;
show engine innodb status;

which was a nice learning experience :).

I'm going to try the transcoding of a Very Large Video File to see what happens.

hermes_costell’s picture

hermes_costell CreditAttribution: hermes_costell as a volunteer commented

In a testing environment I'm working with a >100MB video file and it's transcoding successfully. There are of course a zillion caveats (what processors, etc) but at least I'm seeing a rather long transaction finishing successfully with that db_close(array('target' => 'default')); line commented out, whose stated purpose was to fix issues which arose due to long transcoding jobs.

Note: using the FFMpeg transcoder, in a local Windoze environment, testing out the "transcode on save" functionality. Transcoding via cron and Drush had always worked in my case.

mrydzik@commoditywx.com’s picture

mrydzik@commoditywx.com CreditAttribution: mrydzik@commoditywx.com commented

We've also encountered this issue. #3 fixed the issue for our use case. We use the external Zencoder API.

bredlen’s picture

bredlen CreditAttribution: bredlen commented

I can also confirm this issue, with #3 fixing it using Zencoder API

arosboro’s picture

arosboro CreditAttribution: arosboro at DropForge Labs commented

This fixes the error using the Elastic Transcoder api as well. So any remote transcoding job will work when commenting this line.

jyraya’s picture

jyraya CreditAttribution: jyraya at European Commission and European Union Institutions, Agencies and Bodies commented

I also encountered this issue locally and commenting out the line as mentioned in #3, fixed the issue.

Someone knows in which conditions the db_close() line becomes necessary?

trickyricky26’s picture

trickyricky26 CreditAttribution: trickyricky26 commented

So many thanks!!! Commenting the line out saved my sanity.

jeni_dc’s picture

jeni_dc CreditAttribution: jeni_dc commented
Version: 7.x-2.13 » 7.x-2.x-dev
Status: Active » Needs review
FileSize
video-general_error_1205_db_lock-2892164-10.patch1.5 KB

I'm still seeing this happening in 7.x-2.14 using the Zencoder transcoder and removing that line does fix it. I'm not sure if that'll break anything else, but I wanted to get a fix in for this so here's a patch to do so.

From the comments this isn't a problem with the FFmpeg transcoder, but is with other encoders like Zencoder and Elastic Transcoder. So instead of removing that line completely the patch will only run the db_close() if the FFmpeg transcoder is used.

Patch is against 7.x-2.x-dev from 13 Mar 2019.

poker10’s picture

poker10 CreditAttribution: poker10 at ActivIT s.r.o. commented
Related issues: +#1915602: SQL Server has gone away uncaught exception

Adding related issue: #1915602: SQL Server has gone away uncaught exception . The db_close() call was added in that issue. So the options are either to rollback that change, or do a change as proposed by patch #10. I am curious if anyone else can confirm that the problem is only with external transcoders and the db_close() can still be used for FFmpeg? Or does anyone experienced the bug described in the IS on FFmpeg transcoder?