Bugzilla – Bug 362
.shn filenames truncated at dots
Last modified: 2011-03-16 04:35:07 UTC
All 6 tracks of this show are shown as "w" in the slimserver UI: ./w.haynes2001-07-03.shnf/w.haynes2001-07-03d1t01.shn ./w.haynes2001-07-03.shnf/w.haynes2001-07-03d1t02.shn ./w.haynes2001-07-03.shnf/w.haynes2001-07-03d1t03.shn ./w.haynes2001-07-03.shnf/w.haynes2001-07-03d1t04.shn ./w.haynes2001-07-03.shnf/w.haynes2001-07-03d1t05.shn ./w.haynes2001-07-03.shnf/w.haynes2001-07-03d1t06.shn Similarly, all 26 tracks of this show are shown as "ph1993-03-27": ./ph19930327/ph1993-03-27.shnf/ph1993-03-27.d1t1.shn ./ph19930327/ph1993-03-27.shnf/ph1993-03-27.d1t10.shn ./ph19930327/ph1993-03-27.shnf/ph1993-03-27.d1t2.shn ./ph19930327/ph1993-03-27.shnf/ph1993-03-27.d1t3.shn ...etc The filename appears to be being truncated at the first dot, as opposed to just removing the extension.
If tag information is not found, the server will try to guess the tags. Settings for this are located in server settings, additional server settings, formatting. You see a 'w' because it is probably giving you the artist info.
With newer nightlies, now slimserver won't even play these files; if they are in the playlist the server will just skip over them. I've set the web interface to TRACKNUM. TITLE - ARTIST - ALBUM and it still only shows "w". Can you point me towards debugging options or pieces of code to look at? This may be related in some way to another bug, which is that the music library rescan more or less forgets everything except what's playing - if I do an explicit scan everything is ok, but after a while the server ends up saying 1 artist, 354 songs, 1 album - then if I browse by artist, it shows "unknown artist", then "unknown album", then a single song from the current playlist. I'm fairly sure that this didn't happen before I added the .flac and .shn files to the library.
Oops. I need to switch files; turns out the w.haynes files were corrupted. I have another set of these; ph19930327/ph1993-03-27.shnf/ph1993-03-27.d1t1.shn ph19930327/ph1993-03-27.shnf/ph1993-03-27.d1t10.shn ph19930327/ph1993-03-27.shnf/ph1993-03-27.d1t2.shn ph19930327/ph1993-03-27.shnf/ph1993-03-27.d1t3.shn ph19930327/ph1993-03-27.shnf/ph1993-03-27.d1t4.shn ph19930327/ph1993-03-27.shnf/ph1993-03-27.d1t5.shn ph19930327/ph1993-03-27.shnf/ph1993-03-27.d1t6.shn slimserver does play these, so ignore the part about them not playing -- but only shows 'ph1993-03-27' for each track even when showing artist, album, title.
This again depends on what the Guessed tags are matching. You may not be matching on any pattern that would give you more information. d_info is the debugging switch to use, and you may want to set your music folder to the direcotry of thses files specifically. It will cut down the size of the log as there is a great deal of d_info text for every song that you scan. To see the output of a full rescan, click wipe cache in server settings-additional-performance.
bug 569 mentions wav files, but it turns out that the cause is the same. marking this a dupe. If the patch passes review, you can heck out tomorrow's build and it should be fine. *** This bug has been marked as a duplicate of 569 ***
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.