wactuary
2005-08-23, 21:14
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
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