Opening file from nautilus with a space in the filename or in the path results in a message error from mplayer. Probably an upstream problem (founded in ubuntu too - http://ubuntuforums.org/showthread.php?t=620200). Solved this replacing 'Exec=gmplayer %U' to 'Exec=gmplayer %F' in the mplayer.desktop file (and restarting nautilus)
The fix is obviously incorrect... http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html
well... not exactly Passing more files to mplayer fill the playlist, so the "upper case" is right, anyway probably the real problem form mplayer is in parsing URL string (not happened some times ago). As temporary workaround i tested now that using %F works nicely
mplayer needs %U obviously for streams; %F is no solution here.
i agree that mplayer need %U for streams, but what others applications use the command line specified in mplayer.desktop for launch streams video? (really i don't know, it's not ironic) Starting from my ignorance (i know it's not a good starting point...) i believe it's a more common usage launch mplayer passing a local file param (hoping that stream-oriented application can start mplayer with the full URI)
Exec=gmplayer %F is the only solution I've seen that will fix this annoying issue that probably inconveniences the majority of our users. beandog agreed and gave me the go-ahead to fix it... if anyone can find a solution that works globally, now is the time to speak up! :)
no others solutions, but if someone can find if this is a mplayer regression in parsing uri (maybe this issue is appeared quite changing the exec param...) i think it will be a good starting point (to send obviously upstream if not already known)
Was wondering what other distributions do.. or is their mplayer too old..
Reassigning to media-video, this is not a Gnome or Nautilus issue, breaks also Thunar and I'm suprised if not others..
(In reply to comment #7) > Was wondering what other distributions do.. or is their mplayer too old.. Ubuntu 8.04 alpha has the same bug as of today.
(In reply to comment #5) > Exec=gmplayer %F is the only solution I've seen that will fix this annoying > issue that probably inconveniences the majority of our users. beandog agreed > and gave me the go-ahead to fix it... if anyone can find a solution that works > globally, now is the time to speak up! :) Well, seriously crippling streaming functionality because someone uses stupid filenames is no solution and pretty much a regression.
(In reply to comment #10) > > Well, seriously crippling streaming functionality because someone uses stupid > filenames is no solution and pretty much a regression. > I didn't know that space indicate stupid file name. You also forgot that mplayer used to work with that kind of names, so regression is present now too.
i have the same problem with Thunar and mplayer (latest stable version) when i do right click on a media file and press Open With Mplayer i get the error, but when i drag n drop a file (from thunar) there is no error. the solution that i see here is somebody to write a patch, that parse special charecters like spaces and - and other... this patch must be accepted form the Mplayer project manager. you know that if you want to open a file from a command line you have to write: mplayer File\ name.mp3 (\ before space). the parser must do this. or there is a parser but there is an error and someone have to fix it... well, i never worked with large source codes so i cant do this...
The problem, as far as I understand it, is that gtk+ urlencodes the spaces and other special characters because of the %U in mplayer.desktop. In itself this is correct, but if it is a local file, mplayer seems not to parse the urlencoding. Using %F fixes this for local files. Can somebody test that change and see if it still works correctly with streams? On the other hand, gmplayer is pretty ancient and outdated, and users would do better to use one of the modern frontends (smplayer, gnome-mplayer, kmplayer).
well, i am using mplayer, and i have the same bug. maybe the prolem is in the core. the solution that is in my mind, is to make mplayer smarter ;) if you are opening a local file (such as right click, open with) automaticly should open it with %F, but when a stream file is opening it should be used %U. the question is "how to understand what type is opening?"
Well... %U, %F and similar are freedesktop standard of .desktop entry files. These file define calling convention useful for file-manager. Specifing %U in the mplayer desktop file permit to a file manager to invoke mplayer transparently using an URI, very useful when browsing samba shares with nautilus or to open streaming files. It's a good idea use a URI but to get all works we needs that: 1. the "caller" calls the program with a well-formed URI in the command line 2. the "called" programs (mplayer here) handle the argument passed.
gmplayer is deprecated and there's no .desktop installed without it use smplayer or gnome-mplayer
*** Bug 309289 has been marked as a duplicate of this bug. ***
