maemo.org Bugzilla – Full Text Bug Listing
|Summary:||FM won't open files with known mime type unless the mime type has glob <pattern="*.xxx"/>|
|Product:||[Maemo Official Applications] Utilities||Reporter:||Tuomas Kulve <tuomas>|
|Component:||File manager||Assignee:||unassigned <nobody>|
|Status:||CLOSED INVALID||QA Contact:||file-manager-bugs|
|Priority:||Low||CC:||andre_klapper, damienlmoore, eero.tamminen, felipe.contreras, murrayc, tuomas|
Simple tool to launch file with proper application using mime type.
hildon-mime-summon with optional mimetype
Source code for the hildon-mime-summon.
STEPS TO REPRODUCE THE PROBLEM: Open File Manager Verify that the details dialog shows audio/x-mp3 for a MP3 file. Double click the MP3 file (i.e. select+click), verify that the Media player is started. Close Media Player Remove <glob pattern="*.mp3"/> from /usr/share/mime/packages/mediaplayer-ui.xml Run "update-mime-database /usr/share/mime/" Verify that the FM details dialog shows audio/mpeg for a MP3 file. Double click the MP3 file (i.e. select+click) EXPECTED OUTCOME: Since the Media Player claims to be able to open audio/mpeg (as well as audio/x-mp3) the FM should open the file in the Media Player. ACTUAL OUTCOME: "Unable to recognise file type of: Here_is_the_story.mp3 Search for an application to open it?" REPRODUCIBILITY: always EXTRA SOFTWARE INSTALLED: All kinds of stuff, but shouldn't affect this. OTHER COMMENTS: The FM does recognise the mime type base on the magics in the mime type, it does select the proper icon for the file (i.e. gnome-mime-audio-x-mp3.png or gnome-mime-audio-x-mpeg.png) and the exact same mime type is in the application's desktop file (in this case the Media Player's). But it doesn't start the application if the glob is missing from the mime file. The bug probably belongs to some mime library and not to File Manager as hildon_mime_open_file() function from the libhildonmime0 -package does the same.
I used a little self-written hildon-mime-summon tool to verify the last part of this. I'll attach it, if somebody wants to test it too.
Created an attachment (id=659) [details] Simple tool to launch file with proper application using mime type. Usage: hildon-mime-summon file:///home/user/MyDocs/.sounds/Here_is_the_story.mp3
Created an attachment (id=686) [details] hildon-mime-summon with optional mimetype Usage: hildon-mime-summon audio/x-mp3 file:///home/user/MyDocs/.sounds/Here_is_the_story.mp3 Even though the hildon_mime_open_file() fails, the launching works with the hildon_mime_open_file_with_mime_type() where the mimetype is given. Maybe the FM should use hildon_mime_open_file_with_mime_type() instead of hildon_mime_open_file() when it already knows the mime type? MP is opened on the first execution of the hildon-mime-summon2, but for some reason the file is not added to the playlist. When the hildon-mime-summon2 is called again, then the MP starts playing the file. Is this a bug in the MP? E.g. Image Viewer shows a jpeg with the first execution.
Created an attachment (id=687) [details] Source code for the hildon-mime-summon. I attached the source code here too even though it's pretty simple.
(In reply to comment #3) > MP is opened on the first execution of the hildon-mime-summon2, but for some > reason the file is not added to the playlist. When the hildon-mime-summon2 is > called again, then the MP starts playing the file. Is this a bug in the MP? > E.g. Image Viewer shows a jpeg with the first execution. > I've noticed that, when I use file manager to open compatible mimetypes of my applications, I receive an application_top message, then a mime_open message. So perhaps two calls are required in the implementation of hildon_mime_open_file()?
> I've noticed that, when I use file manager to open compatible mimetypes of my > applications, I receive an application_top message, then a mime_open message. > So perhaps two calls are required in the implementation of > hildon_mime_open_file()? I don't think that's documented, could you file a doc bug about it? First I thought that the mime open message should imply to an application that it should top itself, but then I though that this function could actually be used to ask apps to do things without topping, for example to play music. So, I guess there should be (a separate function with) an additional parameter for whether an application should top itself, or separate top message needs to be sent. Former API could be used also to tell that if D-BUS needed to start the application, it should _not_ come to the foreground, but stay on the bg even after loading the file.
In Fremantle mp3 files have the mime type "audio/mpeg": ~ $ gnomevfs-info musicfile.mp3 | grep MIME MIME type : audio/mpeg
Tuomas, so I remove the glob pattern and then run your tool like described in comment 3 to set the mime type (that I had just removed) for an mp3 file? (In reply to comment #6) > I don't think that's documented, could you file a doc bug about it? Damien, did you file a bug about this? What is the number?
From my part this can be closed as invalid. There's still issues on Fremantle relating to this. There are four mimetypes with *.ogg globs and the mime handlers seem to just pick the first one and doesn't care about the magick that would specify the actual mime type. E.g. gnomevfs-info has a -s command line option that: -s, --slow-mime force slow MIME type detection where available (sniffing, algorithmic detection, etc) But even with -s it still doesn't the get the mime type if the glob is removed from the mime types. I didn't try with GIO as I don't know if there are similar tools for it as well. The reason why I suggest this being resolved as invalid is that using the magic always would probably be too slow anyway. And it would be hard to know when to use the slow method and when just to check the file extension. This bug report is too old for me to have interest to recheck if the FM on Diablo really got the mimetype without the glob or if I forgot something while testing it. The other complaint of mine (about needing to call the function twice) was just an user-error which was cleared up in an other bug report.
(In reply to comment #9) > From my part this can be closed as invalid. > The reason why I suggest this being resolved as invalid is that using the magic > always would probably be too slow anyway. Sounds reasonible. Thanks for elaborating.
Verifying and closing as invalid.