Red Hat Bugzilla – Bug 60468
8-bit Latin1 characters not supported in playlist
Last modified: 2010-07-01 20:40:26 EDT
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):
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
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
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:
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.
Sorry for the noise - mistyped the bug number while submitting the update.
Meant to type been bug #604682.