PDA

View Full Version : Issue with Old Playlists - problem?



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

kdf
2005-08-23, 21:34
On 23-Aug-05, at 9:14 PM, wactuary wrote:

>
> Possible way SlimServer could have helped me:
>
i've pointed to this post from bug 1462, as I believe it might be
applicable.

http://bugs.slimdevices.com/show_bug.cgi?id=1462

Feel free to add more to the discussion, or add your email addy to the
cc list if you wish to be informed of any updates on that bug report.

-kdf