From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221 Description of problem: If a track name has any characters with the high bit set, that character won't be displayed in the playlist. Given that much of the music that I like is obscure Scandinavian and German heavy metal, it has more than its fair share of accented characters in track names. I initially though this might be related to bug 39112, but I think the symptoms are sufficiently different that they're probably not related. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Play a track with a track name that contains a character between 0x80 and 0xff Actual Results: The offending character is simply omitted from the track display Expected Results: The character should be displayed as expected Additional info: I've only verified this when playing ogg files. Maybe mp3s and other formats handle things differently.
Is this in the filename or in the id strings? Note that vorbis ID tags are unicode, IIRC.
I can confirm this on mp3 ID3 (which version? Not sure) tags. If the tag is edited with XMMS, then it sometimes displays correctly. Haven't actually hunted this more since it's not a big issue for me, but I thought I'd drop the comment.
*** Bug 65767 has been marked as a duplicate of this bug. ***
Sounds like the original submitter is talking about filenames, which is similar to this upstream bug: http://bugs.xmms.org/show_bug.cgi?id=1372 Need more info from submitter.
No, I'm talking about track name metadata embedded within the ogg file itself. I suspect the flaw actually lies with oggenc, rather than xmms, in that it's including the accented characters literally in their latin1 form, rather than converting them to utf-8. Thus when xmms tries to decode them as utf8, it gets an invalid character.
Nope, I'm wrong. oggenc is storing them in the ogg file as utf-8, which is correct. It's just xmms that doesn't seem to be utf-8 aware.
is this an issue on fedora? In which case it should be moved to extras where xmms currently sits or upstream.
Sigh. Yes, it's with FC4. It seems the standard RH response these days is "wait until we no longer ship that product, then mark the bug as WONTFIX". I appreciate that's not the official policy, but it just seems to happen to all of my bugs, and it's *very* frustrating. OK, so how do I move it to extras? Is there a separate bugzilla for that somewhere?
OK, a bit of googling shows this to now have been fixed, requiring only some config changes to xmms to get it to work with utf-8 metadata. WFM now.
cool, upstream is usually a good place to report bugs like this. There is no hard and fast rule on when a bug is distro specific or more a general issue but usually upstream will have more resources being that they are more focused on the apps in question. I'm going to switch this to extras so the current xmms maintainer can get the fix if they haven't already done so on the devel branch. Can you post the link to where you found the fix. Thanks.
The fix is already in the version in extras. All I needed to do was check the crypticly named "use fontsets" box in XMMS preferences.
Very very old bug, since the version in Extras contains the fix, can this bug be closed now? Or maybe we should change this option to be on by default?
FC4 is not supported anymore. Please try the FC5 version (or above). It it fails, feel free to re-open this bug.
Huh? How on earth is WONTFIX the correct resolution to this? Since I've already mentioned that it works fine in the latest version in Extras, surely CURRENTRELEASE is more appropriate?
fwbackups-1.43.3-0.9.rc5.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/fwbackups-1.43.3-0.9.rc5.fc13
Sorry for the noise - mistyped the bug number while submitting the update. Meant to type been bug #604682.