I've resolved my actual problem, but it took me a while to debug, so I thought I would bring it here in case others were affected.
I was having a bear of a time getting rid of duplicate instances of the same song. I rescanned the database, I wiped cache, I deleted the database, but the duplicates kept coming back. I finally tracked the problem to old playlists that were pointing to an alternate path to the same files. I didn't realize that the scan looked for the files referenced in a playlist even if they aren't in the music path defined in slimserver. Here is my setup: My music library is divided into 3 subfolders, "flac", "mp3" and "small_mp3". "mp3" is filled with HQ mp3s and is where most of my music is stored. Recently, I decided to scan new and favorite CDs as flac. I made the "small_mp3" folder as a low quality mirror of the flac directory for convenience with my portable player. I then put a symlink under both flac/ and small_mp3/ to point to the /mp3 directory. This way I can point to either /flac or /small_mp3 and see 100% of my music in the best available format for the device. So any file in /mp3 could be reached through 3 methods. /mp3/file.mp3 or /flac/mp3/file.mp3 or /small_mp3/mp3/file.mp3. Originally I had only the /mp3 directory, so my old playlists pointed at /mp3. When I changed my library structure, I wiped the cache and thought all was good. Eventually, I started seeing a duplicate track here and there. It was a minor annoyance that just wouldn't go away. When I updated the old playlists, I could then wipe-cache and the dups disappeared. Possible way SlimServer could have helped me: Highlight tracks that are not in the official library path (but do exist). A) Possibly with a comment in the Track Information screen that points out how slimserver was aware of the file. I kept beating my head against the wall because I could see extra instances had a path through /mp3 instead of /flac/mp3 and I couldn't figure out why slimserver was jumping to a different branch of my file tree. B) Recognize that 2 different paths to the same file are somehow unique. I don't know if this is possible through the OS, but filesize, timestamp and tag data should be pretty unique when taken together. BTW: 6.1 and now the 8/20/05 nightly of 6.2 have been rock solid on my Debian/Sarge, wireless and occasionally wired, SB2 for months now. Skip free, crash free, integrated with MMM, running without intervention. Thanks!!! Apologies for the length. Chris -- wactuary _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/beta
