View Full Version : endless scan and database issues

2005-11-18, 01:13
I have seen this mentioned before and usually the response is that it is to do with compilation or various artist issues/settings. But thats not true here. I have scanned my (large) music folder from scratch multiple times and still find that as of official 6.2.1 I still get a single album by a single band arbitrarily duplicated (so two entries on the albums list) with some songs (maybe 1-6) in one and some songs in the other. I have: switched musicmagic on off, used/ not used the lazy search plugin and I have even done a completely new install on slimserver on a separate machine - same thing. May be relevent that i have a lot of album art that does not show up as well - kind of tries to show it for a second then gives up

The two configurations
Computer 1: OSX TIger, Use i tunes, musicmagic, lazy search
Computer 2: WIndows XP, dont use i tunes, no musicmagic, no lazy search

the actual music is stored on a terastation connected to the network - there are over 14000 songs

same thing on both

apologies if this is a recognised bug but i saw some threads around the subject which just kind of petered out with no answer beyond the "use your compilation settings" which definitely doesnt apply here

2005-11-18, 02:12
Have you checked the ID3 tags? I've found before (especially if the ID3 have been gathered from Freedb etc) that the entries are not always consistently spelled.

2005-11-18, 05:09
thats not it because these are all albums that have previously behaved fine in earlier versions of slimserver - id guess back around two three weeks ago

2005-11-18, 06:48
I've experienced this as well intermittently, and have never been able to get to the bottom of it.

Dan Sully
2005-11-18, 10:52
* jhurley shaped the electrons to say...

>I've experienced this as well intermittently, and have never been able
>to get to the bottom of it.

Remove the LazySearch plugin - there's a bug with it.



<iNoah> you know, most free operating systems come preinstalled with their own high horse.

2005-11-18, 15:37
as you can see from the head of this thread - it also happens on the machine that doesnt have lasy search

2005-11-18, 15:44
Quoting gandt <gandt.1yps0n (AT) no-mx (DOT) forums.slimdevices.com>:

> as you can see from the head of this thread - it also happens on the
> machine that doesnt have lasy search
for those of us who access this from something other than the slim devices
website, that's not so easy to see.

try turning on d_import and looking at the log. that will at least poitn to
which of the scans is running on. then try d_info, d_scan, d_parse, d_artwork
to see what is going on with the scans. (d_musicmagic, d_moodlogic, d_itunes
are useful for each of those respective scans)


Brian Ritchie
2005-11-18, 16:10
Another thing to consider is whether you have playlists that use different paths to the same track.

I had some duplication in 6.1.1; I tracked it down to a playlist that, though stored on the server, had been created on another machine, so the paths in the playlist all used the server's network address. (Most of my playlists either use relative paths, or absolute local paths.) When I changed these to local paths, the duplications disappeared (well, all but one - see below).

I assumed that this was happening because I had different paths in different playlists; it's possible (but less credible) that just using network paths alone in playlists was enough to cause it.

There was one track in one playlist that didn't use a network path, but that was duplicated. I couldn't tell why that track was duplicated but no others in the playlist, and in the end I simply removed it! Now I wonder if it might have been a clash between absolute and relative paths, though it's unlikely that only one file in my collection would be affected if that were true.

I've not restored the network paths to see if this also happens in 6.2.1.