Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 60468

Summary:	8-bit Latin1 characters not supported in playlist
Product:	[Fedora] Fedora	Reporter:	Tethys <sta040>
Component:	xmms	Assignee:	Paul F. Johnson <paul>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4	CC:	aleksey, hdegoede, s.adam, teg
Target Milestone:	---	Keywords:	i18n
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-01-03 00:00:04 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tethys 2002-02-28 00:10:17 UTC

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 19:29:03 UTC

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 12:30:44 UTC

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-29 04:20:06 UTC

*** Bug 65767 has been marked as a duplicate of this bug. ***

Comment 4 Colin Walters 2004-09-27 19:19:18 UTC

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-11 00:56:37 UTC

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 18:46:20 UTC

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 18:52:35 UTC

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 20:43:20 UTC

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 20:52:00 UTC

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 20:58:56 UTC

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 21:12:21 UTC

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 23:33:59 UTC

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-03 00:00:04 UTC

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-03 01:22:55 UTC

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-02 00:36:10 UTC

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-02 00:40:26 UTC

Sorry for the noise - mistyped the bug number while submitting the update.

Meant to type been bug #604682.