Bug 268741

Summary:	Amarok doesn't play files with a # (hash-sign) in the path anymore.
Product:	[Applications] amarok	Reporter:	Schelte Bron <bug+kde>
Component:	general	Assignee:	Amarok Developers <amarok-bugs-dist>
Status:	RESOLVED DUPLICATE
Severity:	normal
Priority:	NOR
Version:	2.4.0
Target Milestone:	2.4.1
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Schelte Bron 2011-03-17 12:56:04 UTC

Version:           2.4.0 (using KDE 4.6.0) 
OS:                Linux

I have some mp3 files in directories called "Greatest hits #1" and "Greatest hits #2". These used to play fine with Amarok 2.3.0, but Amarok 2.4.0 just skips over them.

Reproducible: Always

Steps to Reproduce:
Try to play some music from a directory with a # in the name.

Actual Results:  
Amarok plays a different song instead (with random tracks mode on).

Expected Results:  
Selected song plays.

The song plays fine after renaming the directory to "Greatest hits vol 1".

Comment 1 Myriam Schweingruber 2011-03-19 12:25:32 UTC

Which Phonon backend are you using? Also please make sure you only use UTF-8 in your locale and id3 tags

Comment 2 Schelte Bron 2011-03-19 13:04:56 UTC

I seem to be using the GStreamer 4.4.4 backend. I have no idea if I was using GStreamer or Xine with Amarok 2.3.0.

Triggered by your question I switched to the Xine 4.4.4 backend and then there is no problem playing the songs.

The file names and ID3 tags only contain pure ASCII.

Comment 3 Myriam Schweingruber 2011-03-19 15:44:17 UTC

This has nothing to do with ASCII characters, but eventually with the encoding set in use on your system. Please make sure you use UTF-8.

Anyway, this is a duplicate and already solved in the new phonon-gstreamer-backend. Please check with your distribution for packages.

*** This bug has been marked as a duplicate of bug 198008 ***

Comment 4 Schelte Bron 2011-03-19 16:09:46 UTC

I have a hard time believing this is a duplicate of bug #198008. That bug report mentions non-ASCII characters on non-UTF-8 systems and it is supposed to be fixed in GStreamer backend version 4.4.4. I have problems on 4.4.4 with a regular ASCII character while my locale is set to UTF-8.

However, switching to the Xine backend is an acceptable work-around for me.