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.

Files: 
CommentFileSizeAuthor
mimetype.patch613 bytesarthurf
PASSED: [[SimpleTest]]: [MySQL] 33,055 pass(es).
[ View ]

Comments

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

This directly matches the information at http://en.wikipedia.org/wiki/M4V.

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

RTBC pending testbot review

Issue tags:+needs backport to D7

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!

mimetype.patch queued for re-testing.

Status:Needs review» Reviewed & tested by the community

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

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

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

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..?

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

<?php
/**
* Implements hook_file_mimetype_mapping_alter().
*/
function file_entity_file_mimetype_mapping_alter(&$mapping) {
 
// Fix the mime type mapping for ogg.
  // @todo Remove when http://drupal.org/node/1239376 is fixed in core.
 
$new_mappings['ogg'] = 'audio/ogg';
 
// Add support for m4v.
  // @todo Remove when http://drupal.org/node/1290486 is fixed in core.
 
$new_mappings['m4v'] = 'video/x-m4v';
 
// Add support for mka and mkv.
  // @todo Remove when http://drupal.org/node/1293140 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;
  }
}
?>

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?

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

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 http://api.drupal.org/api/drupal/modules--system--system.api.php/functio... to give a better example of how to implement this hook without creating collisions.

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