maemo.org Bugzilla – Bug 2521
FM won't open files with known mime type unless the mime type has glob <pattern="*.xxx"/>
Last modified: 2010-01-23 10:57:24 UTC
You need to
before you can comment on or make changes to this bug.
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
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)
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.
"Unable to recognise file type of:
Search for an application to open it?"
EXTRA SOFTWARE INSTALLED:
All kinds of stuff, but shouldn't affect this.
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
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.
Created an attachment (id=686) [details]
hildon-mime-summon with optional mimetype
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
> 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
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
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.