Bugzilla – Bug 3221
All library tracks duplicated if a music folder is specified AND MusicMagic is used
Last modified: 2006-03-31 08:59:49 UTC
If a music folder is specified AND 'Use MusicMagic' is enabled, SlimServer scans the music folder (& subfolers) and adds all tracks to the databse, even though they are already in MusicMagic's database. This results in duplicate tracks. In prior versions, enabling 'Use MusicMagic' meant that SlimServer did not scan the music folder and add the tracks. This was helpful as it was still possible to 'browse by folder', even though the library was built from MusicMagic data. Can we return to the behaviour from 6.21?
Slimserver has ALWAYS been designed to scan all sources given, and merge them.
I should also mention that they should not be duplicated, but instead merged. Are you using a shared drive, and are MusicIP and Slimserver referring to the location in different ways (mapped drive vs unc path)? Are your files using any accented characters in the path names? Since both sources use a url, containing the full path to each file as a unique identifier, these urls must match in order to merge the data. What version of MusicMagic are you currently using?
(In reply to comment #2) > I should also mention that they should not be duplicated, but instead merged. > Are you using a shared drive, and are MusicIP and Slimserver referring to the > location in different ways (mapped drive vs unc path)? > > > Are your files using any accented characters in the path names? > > Since both sources use a url, containing the full path to each file as a unique > identifier, these urls must match in order to merge the data. > > What version of MusicMagic are you currently using? > OK, I accept that this is functioning as intended - but now I need ot work out why upgrading my hardware to an Intel based Mac, and upgrading my software to new versions of SlimServer & MusicIP have introduced this problem. Running SlimServer 6.5b1 and MusicIP 1.5.1 on a Mac Mini Intel. Didn't think I was specifying the location differently in SlimServer than in MusicIP, but it's possible. In SlimServer I use /volumes/Share/flac, whilst in MusicIP I simply navigate to the FLAC folder on the Share drive which is mounted. Could it be sensitive to the case in which I type the Music Folder path? Is there a way to find out what SlimServer is seeing as the path from MusicIP so that I can simply replicate it?
if you go into server settings->debugging, check d_musicmagic and d_scan. click change. now, if you look at the top block of text, there is a link at the end which opens a new browser window for the log. (there is also a text file on the mac, slimserver.log, but I can't recall where that is located on OSX) go into server settings and trigger a rescan for new and changed, or wipe library and rescan. if you refresh the log, you will see entries for the music folder scan and for the musicmagic import. case sensitivity is one possible problem. It will certainly matter when the OS itself is case-sensitive. If you have trouble deciphering the log, feel free to attach a second of it to this report and I'll point out anything helpful.
OK, seems that *SlimServer* is case sensitive when merging directories, as the only difference between the MusicIP library and the specified SlimServer Music Folder was that I'd used lower case in SlimServer. OS X itself presumably isn't case sensitive for directories - since both upper & mixed case paths resulted in the same music files finding their way into the library. Is there a reason for SlimServer to be case sensitive?
yes. as you know, slimserver is cross-platform. some platforms are case sensitive, so it is more precise to get all the music and track for all cases. However, there are places where case should not be so picky and there are many bug/enhancements already filed. Some users have used case in ways to match the way an artist uses it, so it is a complex problem to simply decide to canonicalise case. The decision is a design one, and falls outside of the scope of this particular report. Since the duplicates issue appears to be resolved, I'm marking this as fixed. Any case-sensitivity design change requests can be made in the form of a new bug, marked as an enhancement (in severity), or added as a vote to the already existing bugs. Please re-open if you continue to find duplicates under your current state.
Yes, because most things are case sensitive. Obviously the work around here is to make sure the case for both are the same. There's a way to resolve a path to a canonical case on Windows. I'm not sure about OS X.