Project

General

Profile

Bug #78

Encoding issues prevents playback for audacious 3.2 and 3.2.1

Added by colleen josephson about 12 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Major
Assignee:
-
Category:
-
Target version:
-
Start date:
February 29, 2012
Due date:
% Done:

0%

Estimated time:
Affects version:

Description

On a gentoo system. The 'chardet' useflag is enabled.

On both 3.2 and 3.2.1, playback is not successful for some files with UTF-8 name, wheras I am able to play these files in 3.1.1
If I start from the terminal, the stderr reports: "Cannot convert filename to system locale: R��yksopp - Senior (2010) [V0]/09 - A Long,Long Way.mp3". (The player itself does not indicate any error, it simply will not play the file)

Emerge preview:
udo USE="chardet -gtk gtk3" emerge -pv =media-sound/audacious-3.2 =media-plugins/audacious-plugins-3.2

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild R ~] media-sound/audacious-3.2 USE="chardet gtk3 nls session -gtk" 0 kB
[ebuild R ~] media-plugins/audacious-plugins-3.2 USE="aac alsa cdda flac gtk3 ipv6 jack lame midi mp3 nls sndfile vorbis -adplug -bs2b -cue -ffmpeg -fluidsynth -gnome -gtk -libnotify -libsamplerate -mms -mtp -oss -pulseaudio -scrobbler -sid -wavpack" 0 kB

Total: 2 packages (2 reinstalls), Size of downloads: 0 kB

  • IMPORTANT: 7 news items need reading for repository 'gentoo'.
  • Use eselect news to read news items.

I assigned this as major priority because it introduces a bug that was not present in previous versions that prevents playback of legitimate files.

History

#1 Updated by John Lindgren about 12 years ago

What is your system locale, and what is the actual UTF-8 filename that cannot be converted?

#2 Updated by colleen josephson about 12 years ago

system locale: en_US.UTF-8
filename: Röyksopp - Senior (2010) [V0]/08 - Coming Home.mp3

Any file in this directory will not play (plus others that have non-US characters)

#3 Updated by John Lindgren about 12 years ago

Please post the output of:

$ ls -d R*yksopp* | hexdump -C
00000000 52 c3 b6 79 6b 73 6f 70 70 20 2d 20 53 65 6e 69 |R..yksopp - Seni|
00000010 6f 72 20 28 32 30 31 30 29 20 5b 56 30 5d 0a |or (2010) [V0].|
0000001f

#4 Updated by colleen josephson about 12 years ago

00000000 52 6f 79 6b 73 6f 70 70 0a 52 c3 b6 79 6b 73 6f |Royksopp.R..ykso|
00000010 70 70 20 2d 20 4a 75 6e 69 6f 72 20 2d 20 56 30 |pp - Junior - V0|
00000020 0a 52 c3 b6 79 6b 73 6f 70 70 20 2d 20 53 65 6e |.R..yksopp - Sen|
00000030 69 6f 72 20 28 32 30 31 30 29 20 5b 56 30 5d 0a |ior (2010) [V0].|
00000040

#5 Updated by John Lindgren about 12 years ago

How are you adding the files in that directory to the playlist? Does it work if you run:

$ audacious R*yksopp*

#6 Updated by colleen josephson about 12 years ago

I usually drag and drop from Thunar.

running 'audacious R*yksopp*' gives the same error

Cannot convert filename from system locale: R��yksopp - Junior - V0
Cannot convert filename from system locale: R��yksopp - Senior (2010) [V0]

#7 Updated by John Lindgren about 12 years ago

I also use en_US.UTF-8, and have the same bytes in the filename on disk, and I'm totally unable to reproduce this. So I'm stumped for the moment.

#8 Updated by John Lindgren almost 12 years ago

  • Status changed from New to Closed

Closing: unreproducible.

#9 Updated by Alessio Treglia about 11 years ago

Could you please re-open this?

A bug reported to Debian BTS confirm this is still reproducible, please have a look at it here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700804

#10 Updated by John Lindgren almost 11 years ago

Not reopening; I still cannot reproduce, and #700804 is a different problem (trying to use an Latin-1 filename on a UTF-8 system).

#11 Updated by Matthew Schultz over 10 years ago

John Lindgren wrote:

Not reopening; I still cannot reproduce, and #700804 is a different problem (trying to use an Latin-1 filename on a UTF-8 system).

I've been having a problem with this bug for a while now and it's still present in 3.2.2. I guess I now know why it's not fixed.

Here's something to digest. No problems playing in mplayer:

mplayer Tool\ -\ Ænema.mp3
MPlayer 1.1-4.6.3 (C) 2000-2012 MPlayer Team

Playing Tool - Ænema.mp3.
libavformat version 54.29.104 (external)
Audio only file format detected.
Clip info:
Title: Ænema
Artist: Tool
Album: Ænema
Year: 1996
Comment:
Track: 13
Genre: Metal
Load subtitles in ./ ==========================================================================
Opening audio decoder: [mpg123] MPEG 1.0/2.0/2.5 layers I, II, III
AUDIO: 44100 Hz, 2 ch, s16le, 192.0 kbit/13.61% (ratio: 24000->176400)
Selected audio codec: [mpg123] afm: mpg123 (MPEG 1.0/2.0/2.5 layers I, II, III) ==========================================================================
AO: [oss] 44100Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...

Nothing but problems with audacious 3.2.2 and doesn't play at all and just skips over the file as if it's not there in the playlist:

Cannot convert filename to system locale: /home/mschultz/music/Tool - Ænema.mp3
Cannot convert filename to system locale: /home/mschultz/music/Tool - Ænema.mp3
Cannot convert filename to system locale: /home/mschultz/music/Tool - Ænema.mp3
Cannot convert filename to system locale: /home/mschultz/music/Tool - Ænema.mp3
Cannot convert filename to system locale: /home/mschultz/music/Tool - Ænema.mp3
Cannot convert filename to system locale: /home/mschultz/music/Tool - Ænema.mp3
Cannot convert filename to system locale: /home/mschultz/music/Tool - Ænema.mp3

emerge -pv audacious audacious-plugins

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild R ] media-sound/audacious-3.2.2-r1 USE="chardet gtk nls session -gtk3" 0 kB
[ebuild R ] media-plugins/audacious-plugins-3.2.2-r1 USE="aac alsa cdda ffmpeg flac gtk ipv6 libnotify mp3 nls oss sdl vorbis -adplug -bs2b -cue -fluidsynth -gnome -gtk3 -jack -lame -libsamplerate -midi -mms -mtp -pulseaudio -scrobbler -sid -sndfile -wavpack" 0 kB

$ locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=en_US.utf8

This is simple enough to reproduce.

1. Set one of your keys on your keyboard as the "compose" key (right alt, right ctrl or something like that).
2. To create compose characters (within the latin character set no less), press and release the compose key (whatever you set it to be in step 1), press and release the "a" key, press and release the "e" key, you should get: æ
3. Rename an mp3 file with that character in it.
4. Add the mp3 file to the audacious playlist (it will add to the playlist but it will give this warning message: Cannot convert filename to system locale)
5. Select the file in the playlist and double click. It will then skip to the next song in the playlist and emit the same error message as before: Cannot convert filename to system locale.

#12 Updated by John Lindgren over 10 years ago

Nope. I still can't reproduce this. Go fix whatever is set up wrong on your system instead of necrobumping an old bug report.

Also available in: Atom PDF