Tags are different things to different people. They are metadata but on SqueezeCentre are used as database identifiers. However since it is possible to tag two files identically eg the FLAC and MP3 versions of the same file the only guarantee of uniqueness has to be the fully qualified filename as it is impossible to have two files with the same fully qualified filename in the same name space. (Excluding journalling file systems.)
I am puzzled by the fact that some of your playlists seem to de-reference network share names into local names. I really can't see that being a function of the operating system or rather not being part at the level in which SC and other applications operate. Doing so apparantly randomly is even more unlikely. I am not saying you are wrong I'm saying something else is causing it. SC obtains the file location of every file by walking the directory tree from the initial point that you specified. It will follow symbolic links, hard links, mounted file systems, pointers etc. However, it should still be seeing them all still within the same file namespace. Whilst this could lead to the same file being in two different places you shouldn't be able to get x:\yxz and \\namespace\x\yxz SC also scans a number of other text based files for track references. Playlists in various formats and Cue sheets (Cue sheets reference the position of a track within a larger file.) If any of these use a different namespace then this would inject that different namespace into the scan. SC I believe checks for the existance of the file before it puts it into the database, not least because it wants the metadata. Therefore if it can see the same file in both namespaces it will see it as two files. Cue sheets are unlikely to exhibit the namespace behaviour as they are usually written in the context of the current directory. The initiator of the problem is therefore likely to be playlists or any other text file containing track filenames in the directory structure. You mention running some other music management tools and pointing them at the network share namespace. However, they have a habit of adding where you point them to a search list that often includes the whole computer. Running this on the machine which also hosts the network namespace could result in the tool seeing the files twice. How they look for duplicates, decide which to keep if they do see duplicates or otherwise handle it is down to them but it is feasible that they could write into a playlist both namespaces. Whilst that could explain why you get duplicated files it wouldn't explain why the duplication seems to be random. However, SC does do some database optimisation. Whilst I have no idea what is contained in the optimisation I can envisage a process that seeks to remove duplication within the database and at some point retrieves both file references for the same track and keeps only the first. Unless (and even with) an index involved the order in which two identical records are returned (within the seach criteria) is random (under the control of the database) sometimes it could return the x:\ first and other times the \\namespace\ first. This could explain the changing results. The fact that removing all playlists appears to make things OK suggests that the playlist generation is the problem. -- Zaragon ------------------------------------------------------------------------ Zaragon's Profile: http://forums.slimdevices.com/member.php?userid=14577 View this thread: http://forums.slimdevices.com/showthread.php?t=60755 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/discuss
