Bug 268741 - Amarok doesn't play files with a # (hash-sign) in the path anymore.
Summary: Amarok doesn't play files with a # (hash-sign) in the path anymore.
Status: RESOLVED DUPLICATE of bug 198008
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: 2.4.0
Platform: openSUSE Linux
: NOR normal
Target Milestone: 2.4.1
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-17 12:56 UTC by Schelte Bron
Modified: 2011-03-19 16:09 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.