Rats. I hadn't realised that the SEARCH column was actually used for
anything other than searching, so what you describe seems quite likely.
I'll have a look into it, but I would have thought the right column to be
comparing against in that situation would be the "NAME" version rather than
"NAMESEARCH" version as I would have thought you'd expect to see two artists
with different punctuation be treated as separate artists (the NAMESEARCH
column throws away such things).
It comes back to it desire to have some way for plugins to maintain their
own bits of the database without patching the core code (ideally letting
them register to have their own columns on core types), but I can't think of
an easy fix to that myself. I've always thought it a little messy to go to
the trouble of creating things like MusicMagic and MoodLogic as plugins but
then require core SlimServer support for them in the database schema and DBI
stuff, but I can see it's not an easy problem to solve.
I'll take a look at the use name of the "NAMESEARCH" type columns over the
weekend and see what I can come up with. Letting me have my own column in
the contributors, genres, tracks and albums columns would be the easiest and
cleanest fix (anybody?)
Thanks for looking into it. I'm sure I can reproduce it now.
Stuart
-----Original Message-----
From: plugins-bounces (AT) lists (DOT) slimdevices.com
[mailtolugins-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of ceejay
Sent: 11 November 2005 2:48 PM
To: plugins (AT) lists (DOT) slimdevices.com
Subject: [SlimDevices: Plugins] Lazy Search causes Duplicate Artist on
rescan
Like everyone else I think Lazy Search is great - but I'm afraid I've
identified a bug in the way the rescanning is working.
The symptom is that if you add some new music to your library, where
the artist is the same as an existing artist, you will get duplicate
artist entries if you rescan "look for new and changed items". If you
rescan with a clear library, all is fine.
I've looked into it, and I've seen that the Artist is in fact being
duplicated in the database (a second artist ID is created).
I think the reason is that the code to check to see whether this new
piece of music has a new artist must be comparing the incoming artist
name with the "namesearch" field. Unfortunately, if Lazy Search is
active, this field has been modified by having the equivalent number
stuffed in it. So the comparison is between, say, "Mahler" and
"Mahler||624537", which of course fails, so a new artist is created.
I'm afraid my Perl isn't up to taking this any further, but I hope this
helps you find a fix.
Best regards
Ceejay
--
ceejay
------------------------------------------------------------------------
ceejay's Profile: http://forums.slimdevices.com/member.php?userid=148
View this thread: http://forums.slimdevices.com/showthread.php?t=18094
anything other than searching, so what you describe seems quite likely.
I'll have a look into it, but I would have thought the right column to be
comparing against in that situation would be the "NAME" version rather than
"NAMESEARCH" version as I would have thought you'd expect to see two artists
with different punctuation be treated as separate artists (the NAMESEARCH
column throws away such things).
It comes back to it desire to have some way for plugins to maintain their
own bits of the database without patching the core code (ideally letting
them register to have their own columns on core types), but I can't think of
an easy fix to that myself. I've always thought it a little messy to go to
the trouble of creating things like MusicMagic and MoodLogic as plugins but
then require core SlimServer support for them in the database schema and DBI
stuff, but I can see it's not an easy problem to solve.
I'll take a look at the use name of the "NAMESEARCH" type columns over the
weekend and see what I can come up with. Letting me have my own column in
the contributors, genres, tracks and albums columns would be the easiest and
cleanest fix (anybody?)
Thanks for looking into it. I'm sure I can reproduce it now.
Stuart
-----Original Message-----
From: plugins-bounces (AT) lists (DOT) slimdevices.com
[mailtolugins-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of ceejay
Sent: 11 November 2005 2:48 PM
To: plugins (AT) lists (DOT) slimdevices.com
Subject: [SlimDevices: Plugins] Lazy Search causes Duplicate Artist on
rescan
Like everyone else I think Lazy Search is great - but I'm afraid I've
identified a bug in the way the rescanning is working.
The symptom is that if you add some new music to your library, where
the artist is the same as an existing artist, you will get duplicate
artist entries if you rescan "look for new and changed items". If you
rescan with a clear library, all is fine.
I've looked into it, and I've seen that the Artist is in fact being
duplicated in the database (a second artist ID is created).
I think the reason is that the code to check to see whether this new
piece of music has a new artist must be comparing the incoming artist
name with the "namesearch" field. Unfortunately, if Lazy Search is
active, this field has been modified by having the equivalent number
stuffed in it. So the comparison is between, say, "Mahler" and
"Mahler||624537", which of course fails, so a new artist is created.
I'm afraid my Perl isn't up to taking this any further, but I hope this
helps you find a fix.
Best regards
Ceejay
--
ceejay
------------------------------------------------------------------------
ceejay's Profile: http://forums.slimdevices.com/member.php?userid=148
View this thread: http://forums.slimdevices.com/showthread.php?t=18094
Comment