Bugzilla – Bug 114669
xmms cannot deal with latin1 characters in filenames
Last modified: 2006-03-06 15:14:19 UTC
I have quite a bit of mp3 files and xmms playlists with latin1 chars in their name. xmms is not able to play those. For instance, this one Alan Stivell - AuDelà des Mots.xmms and it contains path names like /mpeg/Alan Stivell - AuDelà des Mots/track1.mp3 where à is 0340. xmms refuses to load the playlist until I rename it to something that has no latin1 characters in it. But still it refuses to load the mp3 files themselves. LC_CTYPE is en_US.UTF-8. If I change this to en_US.iso8859-1, xmms is able to open the files. I think a string is a string is a string, and xmms should stop trying to mess with the encoding. Converting the string is okay for input/output, but strings taken from the file system should be taken literally.
You have files named in latin, and filelists in latin1, while running on UTF8 locale? On my system, xmms reads and plays at least, although it doesn't show the file correctly. Could you attach the filelist file?
> You have files named in latin, and filelists in latin1, while running on > UTF8 locale? Exactly. I would assume this is not uncommon - files accumulate over the years, and it's somewhat futile to rename everything just in order to be compatible with the latest encoding change :)
Created attachment 48431 [details] Various playlist files as a tar.gz
Won't it work if you rename the fielist file to .m3u extension?
No, sorry. No workie. I can live with this for now; don't waste too much time on this as long as you have other bugs :-)
I tested with my machine and it's ok with latin1 file names. Only shown with corrupt letters. Then perhaps it's a problem of ID3 tag, rather than the file names. (Unfortunately, id3 tag has no encoding attribute) Anyway, make an alias "xmms env LANG=en_US.ISO8859-1 xmms" :)
BTW, there was already beta4 for a long time...
The problem is that xmms supports only ID3v1, which has no encoding attribute. ID3v2, which supports encoding, is not used in xmms. Gentoo uses some unofficial patches to behave better. I can look at it and try to integrate. Please note, that ID3v1 tags are usually interpreted in local country Windows encoding of MP3 creator or MP3 player manufacturer, which is very vague definition.
OK, Stanislav, I toss you this one. Resolve to LATER if you want :) (BTW, the same problem with BMP?)
I will try encoding patches. But please do not expect complete fix. xmms is very far from this state - GTK1 is not UNICODE-aware, ID3v1 is not encoding-aware, and filename re-encoding may be a problem, too.
Okay, I understand that. If you say xmms just will never do this properly without a major rewrite I can accept that. So don't feel compelled to spend a lot of time on this.
Hello. I have found this bug and I see this statement confusing: >The problem is that xmms supports only ID3v1, which has no encoding attribute. >ID3v2, which supports encoding, is not used in xmms. Because I have a friend that uses Debian and has the same version of XMMS player installed (compared to the one from SUSE 10.0) and he is able to edit ID3v1 and ID3v2 files. Why isn't this enabled in SUSE? I will attach a small screenshot of the interface. Sorry if this info is not desired to be here.
Created attachment 56557 [details] XMMS interface of the multiple ID3 version editing capabilities. Could be this integrated in SUSE? Is this the correct bug to ask for it or should I open a new one? Thanks.
I can look at patches used by Debian and take some of them.
> I can look at patches used by Debian and take some of them. That could be great, Stanislav! BTW, if the multi-ID3tag interface is going to be integrated, perhaps it is interesting to change the summary of this bug to include words like "ID3", "ID3v1", "ID3v2", "Debian", ... so as to make it easier to find.
fixed