|
Bugzilla – Full Text Bug Listing |
| Summary: | xmms cannot deal with latin1 characters in filenames | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Olaf Kirch <okir> |
| Component: | Sound | Assignee: | Marian Jancar <mjancar> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Minor | ||
| Priority: | P5 - None | CC: | sbrabec |
| Version: | Beta 3 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Development | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
Various playlist files as a tar.gz
XMMS interface of the multiple ID3 version editing capabilities. |
||
|
Description
Olaf Kirch
2005-09-01 10:18:00 UTC
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 |