This is not happening here. I just tested it and it loads the track just find and starts playing. Can you give me more details about your computer specs... what window manager and you using with ubuntu ? Unity?
Only happens with mp3 or flac ? what about ogg, mp4, wma files ?
If guayadeque is already started what happens ?

Thanks for your help

For me its working without setting anything special.

same report as here :
http://guayadeque.org/index.php?p=/discussion/685/auto-play-feature#Item_21

maybe they should be merged.

same problem as Tar for me

where canI see the revision number please (About shows only 0.3.5-)

I have seen that the build for i386 has failed. My machine is a i386. So may be the svn have been not installed. I've made the update from ppa:anonbeat/guayadeque, and the About still shows 0.3.5-. And the problem remains the same.
Am I wrong ?

it works !
thanx so much

Thanks for your help

just jumped from Svn 1849 to current (1854) to check...
and sadly it's even worse now, something else must be broken, you can't even load files by adding them with simple right-click from filemanager (tested with pcmanfm / spacefm), even if the player is already running, they simply stopped showing up in current playlist. drag & drop still works but that's all.

edit : guayadeque launched from terminal tells me the files it tries to load with right-click...don't exist (?!)
for instance

----------
14:30:18: Loading 0 0 => 4 'file:///media/SD%20&%20ZIQ/ziq/arrivages%20en%20vrac/Va-%20Ostinato/Ostinato%2021%20-%202008/04%20William%20S.%20Burroughs.mp3'
14:30:18: Error: File doesnt exist 'file:///media/SD%20&%20ZIQ/ziq/arrivages%20en%20vrac/Va-%20Ostinato/Ostinato%2021%20-%202008/04%20William%20S.%20Burroughs.mp3'
---------

same with all files

Can you try with revision 1855 and let me know how it works please ?

Thanks for your help

just compiled 1855. results are curious ^^
ie opening from filemanager works as intended (starting guayadeque, adding files in playlist and autostart)...sometimes

but depending on folders or god knows what else (didn't find a pattern yet to explain the behaviour), some other times it just crashes guayadeque/makes it close (if it's already open) or it "half opens it" (if it's not running), ie guayadeque is started but window doesn't show up and the only place you'll see it is in the task manager... weird...
or maybe I should reboot after compilation, à la windows ^^
will do more tests after sleep, 3 AM, enough for today :)

with 1856 :
Non Ansi characters I guess it doesn't like them at all (ie guayadeque still treats those files as "file doesn't exist")
for instance it refuses to load anything coming from my :
"Ákos Rózmann" folder
but if I rename it
"Akos Rozmann" (without accents) it works...

it somehow acts as if utf-8 support works only if files are loaded from the player, not externally.

edit : tried with french accents ("Progalambiqué" folder), same result, refuses to load.
just copy-paste those folder names with accents and put random mp3 in it, so you can check future revisions with it, you just have to try to open the folder itself from your file manager ^^

1857-1858 : no change for accented filenames if launched from filemanagers :

23:18:19: Error: File doesnt exist 'file:///media/SD%20&%20ZIQ/ziq/electro-acoustique%20-%20Spectral/%C3%81kos%20R%C3%B3zmann'

. as I said, I both tried with 1857 (2 days ago) and 1858 (this morning)

. zero problem here to load those Ákos Rózmann files (or any other with accents) in audacious from pcmanfm or directly from player.

.That being said, I just installed nautilus, and it indeed works from nautilus to guayadeque, so maybe I'll just knock on pcmanfm/spacefm developper's door instead ^^

Yeah I heard you & I believe you, but my experience is quite different on that point : I have 1+ TB of music (not counting offline/burnt/cloud stuff) with countless utf-8 so-called "weird" files from all countries (from nordic accents to japanese kanji etc), and I never had problems to load them with audacious from pcmanfm (actually using 1.0 with xubuntu 12.04), be it this morning , last week, or months ago ^^

I guess I can install some desktop videograbbing stuff if you need proof, so you'll see me doing it live ;) but anyway, pretty useless as it won't change the matter. at least I know I have an alternative with nautilus so I'll make one more keyboard shortcut for a secondary filemanager ^^

nothing incomplete, as already stated, this was a folder (but it's of course the exact same thing with a single file)... so here are the capture proofs :

step 1 : going to concerned folder with pcmanfm
http://image.noelshack.com/fichiers/2012/51/1356011563-proof1.jpg

step 2 : choose open with audacious
http://image.noelshack.com/fichiers/2012/51/1356011577-proof2.jpg

resulting step 3 : all files load/play in audacious without problem.
http://image.noelshack.com/fichiers/2012/51/1356011577-proof3.jpg

while in guayadeque everything is ignored since the main folder accents "block" it. and it's the very same for EVERYTHING with regular/standard accents, nothing special and certainly NOT special characters involved from my part. just standard accents used by nearly half of the world countries...

recap :

.nautilus -> guayadeque : WORK, including files with french/swedish/whatever accents.

. pcmanfm -> audacious : WORK, including files with french/swedish/whatever accents.
DO NOT CONFUSE with special characters that can be used in bash for variables etc, no one in his sane mind uses them for filenames especially if he wants to share them (we all have windows friends that would be in deep sh*t ^^ ), although unix sure allows it. that NEVER was my point.

. pcmanfm -> guayadeque : FAIL (existing/regular files with accents "don't exist")

following are semi-wild guesses, I'm no coder ^^

ok, so basically, pcmanfm and guayadeque are using wxwidgets not so compatibles versions ? (2.8 vs 3.0 ?)

http://docs.wxwidgets.org/trunk/overview_unicode.html

is this section of any interest ? (especially the last part) :

""""""""
Unicode and the Outside World
Even though wxWidgets always uses Unicode internally, not all the other libraries and programs do and even those that do use Unicode may use a different encoding of it. So you need to be able to convert the data to various representations and the wxString methods wxString::ToAscii(), wxString::ToUTF8() (or its synonym wxString::utf8_str()), wxString::mb_str(), wxString::c_str() and wxString::wc_str() can be used for this.

The first of them should be only used for the string containing 7-bit ASCII characters only, anything else will be replaced by some substitution character. wxString::mb_str() converts the string to the encoding used by the current locale and so can return an empty string if the string contains characters not representable in it as explained in Data Loss due To Unicode Conversion Errors. The same applies to wxString::c_str() if its result is used as a narrow string. Finally, wxString::ToUTF8() and wxString::wc_str() functions never fail and always return a pointer to char string containing the UTF-8 representation of the string or wchar_t string.

wxString also provides two convenience functions: wxString::From8BitData() and wxString::To8BitData(). They can be used to create a wxString from arbitrary binary data without supposing that it is in current locale encoding, and then get it back, again, without any conversion or, rather, undoing the conversion used by wxString::From8BitData(). Because of this you should only use wxString::From8BitData() for the strings created using wxString::To8BitData(). Also notice that in spite of the availability of these functions, wxString is not the ideal class for storing arbitrary binary data as they can take up to 4 times more space than needed (when using wchar_t internal representation on the systems where size of wide characters is 4 bytes) and you should consider using wxMemoryBuffer instead.

Final word of caution: most of these functions may return either directly the pointer to internal string buffer or a temporary wxCharBuffer or wxWCharBuffer object. Such objects are implicitly convertible to char and wchar_t pointers, respectively, and so the result of, for example, wxString::ToUTF8() can always be passed directly to a function taking const char*. However code such as

const char *p = s.ToUTF8();
...
puts(p); // or call any other function taking const char *
does not work because the temporary buffer returned by wxString::ToUTF8() is destroyed and p is left pointing nowhere. To correct this you should use

const wxScopedCharBuffer p(s.ToUTF8());
puts(p);
which does work.

Similarly, wxWX2WCbuf can be used for the return type of wxString::wc_str(). But, once again, none of these cryptic types is really needed if you just pass the return value of any of the functions mentioned in this section to another function directly.
""""""""""