PDA

View Full Version : Hash (#) signs in music library directory names



2eleven
2007-01-24, 14:38
Hi Folks,

I came accross this when I upgraded from 6.2.2 to 6.5.1 recently.
I'm wondering if anyone has filed a bug, and if not, what the proper way to go about filing one is.

If you have a '#' in a directory name within your library (like Big Star "#1 Record" or "Reggae Compilation #3") slimserver >= 6.5.0 pukes when attempting to play a song from that directory. Filenames are ok with the '#' - "Funk #49", for example, plays fine.

I have a lot of directories like this, and I'd rather not start renaming classic album titles because of a slimserver bug, so I've backed down to 6.3.1 which works like a charm.

I run slimserver on a linux system. Here's the log:

2007-01-23 14:35:04.9320 ERROR: openSong: [file:///u1/Audio/flac/B-Stock/Rock,%2
0Pop/Cure,%20The/Live%20Recordings/9999-99-99,%20B-Stock/1995-06-25,%20Somerset,
%20England/Westwood%20One%20%2396-21/Disc%201/01%20-%20Want,%20Fascination%20Str
eet.flac] Unrecognized type flc!

2007-01-23 14:35:04.9325 Backtrace:

frame 0: Slim::Player::Source::errorOpening (/opt/SlimServer_v6.5.1/Slim/Play
er/Source.pm line 1718)
frame 1: Slim::Player::Source::openSong (/opt/SlimServer_v6.5.1/Slim/Player/S
ource.pm line 380)
frame 2: Slim::Player::Source::playmode (/opt/SlimServer_v6.5.1/Slim/Player/S
ource.pm line 972)
frame 3: Slim::Player::Source::jumpto (/opt/SlimServer_v6.5.1/Slim/Control/Co
mmands.pm line 1103)
frame 4: Slim::Control::Commands::playlistXtracksCommand (/opt/SlimServer_v6.
5.1/Slim/Control/Request.pm line 1483)
frame 5: (eval) (/opt/SlimServer_v6.5.1/Slim/Control/Request.pm line 1483)
frame 6: Slim::Control::Request::execute (/opt/SlimServer_v6.5.1/Slim/Control
/Request.pm line 772)
frame 7: Slim::Control::Request::executeRequest (/opt/SlimServer_v6.5.1/Slim/
Web/HTTP.pm line 686)
frame 8: Slim::Web::HTTP::processURL (/opt/SlimServer_v6.5.1/Slim/Web/HTTP.pm
line 536)
frame 9: Slim::Web::HTTP::processHTTP (/opt/SlimServer_v6.5.1/Slim/Networking
/Select.pm line 238)
frame 10: (eval) (/opt/SlimServer_v6.5.1/Slim/Networking/Select.pm line 238)
frame 11: Slim::Networking::Select::select (/opt/SlimServer/slimserver.pl lin
e 492)
frame 12: main::idle (/opt/SlimServer/slimserver.pl line 445)
frame 13: main::main (/opt/SlimServer/slimserver.pl line 1071)


Searching the forums, this fellow found the problem a while back and worked around it by renaming his directories:

http://forums.slimdevices.com/showthread.php?t=28988

I'm a little more stubborn. ;-)

Thanks,

John

ceejay
2007-01-24, 14:44
go to buzilla at bugs.slimdevices.com - you'll need to create an ID for yourself to create the bug report, though you can search first without an ID.

Ceejay

kdf
2007-01-24, 15:03
http://bugs.slimdevices.com/show_bug.cgi?id=4652

2eleven
2007-01-24, 15:08
Thanks - done.

John

ulvi
2007-01-24, 15:09
> If you have a '#' in a directory name within your library
> (like Big Star "#1 Record" or "Reggae Compilation #3")
> slimserver >= 6.5.0 pukes when attempting to play a song from
> that directory. Filenames are ok with the '#' - "Funk #49",
> for example, plays fine.

I have lots of directories with '#" in them; so I just
checked. Everything works fine for me (all my files
are MP3, in case that matters).

SlimServer Version: 6.5.1 - 11206 - Windows XP - EN - cp1252
Server IP address: 192.168.1.4
Perl Version: 5.8.8 MSWin32-x86-multi-thread
MySQL Version: 5.0.22-community-nt


Ulvi

2eleven
2007-01-24, 15:10
Looking at bug 4652, I don't think these are the same issue. Similar though...

2eleven
2007-01-24, 15:19
Interesting Ulvi - my files are all flac. I wonder if that's part of the formula. I'd love to find a workaround if I can.

For me, it's consistently reproducible in 6.5.0 & 6.5.1. Further, 6.3.1 and 6.2.2 both work fine. Seems this might have come in with the mysql stuff, but perhaps it doesn't affect all file types.

John

SteveEast
2007-01-24, 15:32
Another difference is that ulvi is using XP.

Steve.

2eleven
2007-01-24, 15:34
I don't think it's linux specific. This guy was using XP as well and found the same problem:

http://forums.slimdevices.com/showthread.php?t=28988

John

ddewey
2007-01-24, 15:41
Quoting ulvi (ulvi.2kxqmn1169676601 (AT) no-mx (DOT) forums.slimdevices.com):

>
> > If you have a '#' in a directory name within your library
> > (like Big Star "#1 Record" or "Reggae Compilation #3")
> > slimserver >= 6.5.0 pukes when attempting to play a song from
> > that directory. Filenames are ok with the '#' - "Funk #49",
> > for example, plays fine.
>
> I have lots of directories with '#" in them; so I just
> checked. Everything works fine for me (all my files
> are MP3, in case that matters).

Same here, and I have Big Star's "#1 Record" also and it works fine (and
gets a lot of play).
Running 6.5.1 on Fedora Core 3, mp3 files and not flac (yet). Sounds like
mp3 v flac may be the actual problem here.

--
http://www.last.fm/user/ddewey

SteveEast
2007-01-24, 15:44
The example in that bug only had a hash in the filename, but you only see it with hashes in a directory name. Oh well, whatever, it's certainly a bug.

Steve.

2eleven
2007-01-24, 15:54
Oh - right you are. I guess I can't confirm that the problem I'm seeing also happens on windows.

Craig, James (IT)
2007-01-25, 02:41
http://bugs.slimdevices.com/show_bug.cgi?id=4652

This bug (mine) is when sending requests from an external app though - I
found the 'problem' files played fine when using SlimServer itself...


James
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.

SteveEast
2007-01-25, 06:48
2eleven, I think you need to file your own bug.

Steve.

2eleven
2007-01-25, 10:07
I did. :-)