1) What do you have set for:
Server settings->behaviour,Composer, Band and Orchestra in Artists

2) do you have these tags populated?
I don't seem to be able to reproduce this myself, but don't use the above tags.  

3) Do you have a rough idea of when this behaviour might have started to appear?

Under behavior > Composer, Band and Orchestra in Artists I have band/Orchestra checked. I usually don't have that checked, though. I don't know why it is checked now. I don't use those fields, except for one album where I was experimenting with band while trying to figure out the "Album Artist" stuff. I first noticed this yesterday.

are you using the LazySearch plugin?  If so, it appears that there are some notes regarding multiple artists appearing.  The current workaround appears to be that a full wipe and rescan is required.  Does this case apply to you?

Yes, That must be it. 

This is a lazysearch bug, it sounds like. 

While I'm quite prepared to think it's my fault (as the author of the lazysearch plugin), I don't see that behaviour on my system (Linux/6.5b1 trunk/mostly-FLAC library and, of course lazyysearch!), and I have the server set to rescan every night.

I don't see duplicate artists in either the player's browse artists function or the web interface browse artists function.

I've not tried 6.2.1, though, so maybe there's something different going on in that branch. Dean, do you know if there was a change in the area of recognising existing artists on import in that branch? If it matches on the 'SEARCH' version of artist then I can definitely believe the problem, but that's not what I would have expected and, as I say, I don't see that in 6.5b1.

I'll give the 6.2.1 branch a try at home tonight.

I've been trying to reproduce this and think I've got somewhere.

Can you confirm that you have some playlists defined? Either playlists in SlimServer, or playlists in MusicMagic (if you can create them in MusicMagic - I don't have it so can't tell).

Thanks.

Yes, I have playlists. I used to have several, but I've recently whittled it down to about 3 that I use in Slimserver.

Yep, I think that's it - if you've playlists then you'll get this behaviour (I don't use them, which is why I'd not seen the problem). You also get the problem if you browse into a music folder to add newly ripped music.

I think that's enough information - I *should* be able to at least understand where it's making the decision to create a new instance of the same artist now. I'm pertty certain it's just my plugin at fault.

Thanks for the report - I'll try to find some way around it now.

I've posted an updated plugin that might include a partial workaround for this problem (it should solve the problem with playlists, at any rate). You can get it from the usual place:
http://hickinbottom.demon.co.uk/slimserver/lazy-searching/lazy-searching2.htm

Fixing the problem completely (including using browse music folder to introduce new music), will require a core slimserver modification I think.

Thanks! I won't be able to try it until next week, though. 

Dan checked in a change to the 6.5 trunk that added columns to the database that I believe will close this bug. I've done some preliminary testing and it looks to be resolved now (with a later version of the Lazy Search plugin that I'll release when I've tested it), so I'll post back to this bug to confirm it in a day or two.

Created attachment 1238 [details]
Patch for 6.2.x/6.3.x regarding LazySearch

Added a patch (for 6.3.x) that fixes the occurrence of duplicate artists after adding music by "search for new and changed music" or by browsing into the folder of the new music.

Usually an 'exact match search' for the existing artist is done on the namesearch column. Since LazySearch attaches a string to the values in this column, the patch changes the search to something like /^search name(regexp of LazySearch string)?/.

Created attachment 1239 [details]
A better fix for 6.3.x

This should be better as the old patch could create problems if separate artists start with the same words.

Yet to test whether there is a performance hit due to the two SQL queries.

I have tested the patch, mentioned above, for both - full rescan and manually adding music by browse directory. I have no more issues with duplicate artists, neither are there any significant performance hits.

Whilst this patch might help the 6.3 version I think it's unlikely as it would be incorporated into the product as it contains knowledge specific to the Lazy Search plugin (the "||" encoding in the NAMESEARCH column). As I understand it <6.5 versions are largely frozen to this type of change and the correct solution is that which has already been incorporated into the 6.5 version - a separate 'custom search' column that is used by plugins such as Lazy Search so that core database columns such as NAMESEARCH aren't meddled with.

At the time I asked whether that column could be added to 6.3 and was told that it was a new feature and hence would not be in the stable release version.

Whilst it's up to Slim Devices what they do with 6.3, of course, I'd personally be surprised if this was incorporated. It doesn't make that patch any less valuable for people willing to mod their own 6.3 installations, though.

This should be fixed with 6.5

anyone willing to confirm, now that 6.5.0 is out?

I think it's fixed - I've got playlists and I don't see this duplication any longer with 6.5.

Also, the original problem could not occur since the lazy search plugin is now using the CUSTOMSEARCH column rather than adding to the TITLESEARCH/NAMESEARCH column (it was this modification that meant that each artist found during the rescan looked new, and hence was created leading to the duplicates).

So, I believe it can be closed - if there's still a problem with duplicates it wasn't the one reported under this bug.

Thanks. Please reopen if you see this again.

This bug appears to have been fixed in the latest release!

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.

Make sure to include the version number of the software you are seeing the error with.