Bug 60468 - 8-bit Latin1 characters not supported in playlist
8-bit Latin1 characters not supported in playlist
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xmms (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Paul F. Johnson
Fedora Extras Quality Assurance
: i18n
: 65767 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-02-27 19:10 EST by Tethys
Modified: 2010-07-01 20:40 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-02 19:00:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tethys 2002-02-27 19:10:17 EST
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.
Comment 1 Bill Nottingham 2002-03-04 14:29:03 EST
Is this in the filename or in the id strings? Note that vorbis ID tags are
unicode, IIRC.
Comment 2 Harri Haataja 2002-03-31 07:30:44 EST
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.
Comment 3 Bill Nottingham 2004-01-28 23:20:06 EST
*** Bug 65767 has been marked as a duplicate of this bug. ***
Comment 4 Colin Walters 2004-09-27 15:19:18 EDT
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.
Comment 5 Tethys 2004-10-10 20:56:37 EDT
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.
Comment 6 Tethys 2005-11-08 13:46:20 EST
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.
Comment 7 John (J5) Palmieri 2005-11-08 13:52:35 EST
is this an issue on fedora?  In which case it should be moved to extras where
xmms currently sits or upstream.
Comment 8 Tethys 2005-11-08 15:43:20 EST
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?
Comment 9 Tethys 2005-11-08 15:52:00 EST
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.
Comment 10 John (J5) Palmieri 2005-11-08 15:58:56 EST
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.
Comment 11 Tethys 2005-11-08 16:12:21 EST
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.
Comment 12 Hans de Goede 2006-11-16 18:33:59 EST
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?
Comment 13 Paul F. Johnson 2007-01-02 19:00:04 EST
FC4 is not supported anymore. Please try the FC5 version (or above). It it
fails, feel free to re-open this bug.
Comment 14 Tethys 2007-01-02 20:22:55 EST
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?
Comment 15 Fedora Update System 2010-07-01 20:36:10 EDT
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
Comment 16 Stewart Adam 2010-07-01 20:40:26 EDT
Sorry for the noise - mistyped the bug number while submitting the update.

Meant to type been bug #604682.

Note You need to log in before you can comment on or make changes to this bug.