file.mimetypes does not have an entry for video/x-m4v m4v which prevents these video files' mime type from being properly detected.

Attached patch adds this entry to our listing.

mimetype.patch613 bytesarthurf
PASSED: [[SimpleTest]]: [MySQL] 33,055 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


Dave Reid’s picture

Version: 7.8 » 7.x-dev
Status: Active » Needs review

This directly matches the information at

Dave Reid’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +Media Sprint 2011

RTBC pending testbot review

Dave Reid’s picture

Issue tags: +needs backport to D7
Devin Carlson’s picture

Version: 7.x-dev » 8.x-dev
Status: Reviewed & tested by the community » Needs review

I just stumbled upon this issue while reviewing some of the great work being done on the media module; it looks like the version was set to 7.x-dev by mistake?
I'm moving this to 8.x and changing the status to needs review. I'll change it back to RTBC after the testbot runs.

I conditionally apologize if I'm wrong about this!

Devin Carlson’s picture

mimetype.patch queued for re-testing.

Devin Carlson’s picture

Status: Needs review » Reviewed & tested by the community
Dave Reid’s picture

Confirming this is ready against both 8.x and 7.x.

catch’s picture

Version: 8.x-dev » 7.x-dev

Committed to 8.x, moving to 7.x for webchick to look at.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Committed and pushed to 7.x. Thanks!

Though one question. Is it possible a contributed module has already used ID 348 for something else..?

Dave Reid’s picture

They should be adding their entries properly. If not, then it's a bug in that module:

 * Implements hook_file_mimetype_mapping_alter().
function file_entity_file_mimetype_mapping_alter(&$mapping) {
  // Fix the mime type mapping for ogg.
  // @todo Remove when is fixed in core.
  $new_mappings['ogg'] = 'audio/ogg';

  // Add support for m4v.
  // @todo Remove when is fixed in core.
  $new_mappings['m4v'] = 'video/x-m4v';

  // Add support for mka and mkv.
  // @todo Remove when is fixed in core.
  $new_mappings['mka'] = 'audio/x-matroska';
  $new_mappings['mkv'] = 'video/x-matroska';

  foreach ($new_mappings as $extension => $mime_type) {
    if (!in_array($mime_type, $mapping['mimetypes'])) {
      // If the mime type does not already exist, add it.
      $mapping['mimetypes'][] = $mime_type;

    // Get the index of the mime type and assign the extension to that key.
    $index = array_search($mime_type, $mapping['mimetypes']);
    $mapping['extensions'][$extension] = $index;
webchick’s picture

Right, I understand that. But $mapping['mimetypes'][] = $mime_type; in an array $mapping['mimetypes'] with 348 items already in it would give you an ID of 348... no? Or does it not matter, since the code always refers to $mapping['extensions'][$extension] instead?

Dave Reid’s picture

No, the id of $mime_type in this case would be 349. The key is using it properly.

arthurf’s picture

Webchick- from your question in #9, I'm guessing that we could have a function which does basically what file_entity_file_mimetype_mapping_alter() is doing so that modules implementing the alter hook do not risk hard coding the keys. Possibly an extension/mimetype register hook.

More simply we could modify the text of to give a better example of how to implement this hook without creating collisions.

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