I'm adding embedded videos to nodes via Embedded Media Field (emfield), but I get an error with DailyMotion in a specific instance. Other Media providers (YouTube and Vimeo specifically, work fine).

If I preview my node before saving, I am unable to actually save the node with the embedded media due to an error..

PDOException: SQLSTATE[23000]:
Integrity constraint violation: 1062 Duplicate entry 'dailymotion://video_id/x1571hb' for key 'uri': INSERT INTO {file_managed} (uid, filename, uri, filemime, filesize, status, timestamp, type) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => x1571hb [:db_insert_placeholder_2] => dailymotion://video_id/x1571hb [:db_insert_placeholder_3] => video/dailymotion [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => 1 [:db_insert_placeholder_6] => 1380751246 [:db_insert_placeholder_7] => video ) in drupal_write_record() (line 7139 of /site/includes/common.inc).

It looks like Media:DailyMotion is saving the file object in getFileObject() without passing anything to the optional $use_existing parameter. It looks like this parameter in file_uri_to_object in Media module is false by default, so it's trying to add the same file again instead of using the existing object.

Anyhow, changing this:

  public function getFileObject() {
    $uri = $this->parse($this->embedCode);
    return file_uri_to_object($uri);
  }

To this:

  public function getFileObject() {
    $uri = $this->parse($this->embedCode);
    return file_uri_to_object($uri, TRUE);
  }

fixed things for me.

Proposed patch w/ changes noted above attached.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kristomo’s picture

Status: Active » Needs review
marvil07’s picture

Status: Needs review » Closed (works as designed)

I could not really reproduce the problem.

In the other side, the change does not really change current behavior, since default value for second parameter is TRUE.

If you know how to reproduce the problem, please reopen the issue with more details.

BTW the mentioned error sounds like one core bug that was solved on a point release.