I've figured out what's going on.
I ran a test with SbS 7.6, latest SVN, running with SQLite. I also set
up a test library with two Mp3 tracks, different artists ('Bob Smith',
'Harry Jones'. Ran a full scan and SbS showed two artists. Changed
them to both the same, then ran a new & changed scan and it _did_ clear
the stale artist name from the database.
Then the same test explicitly using 'Sinead O`Connor' and 'Sinead
O'Connor', with the backtick in the first track. Same results as the
OP. After the initial full scan the first one is the only found in the
library. After correcting it and running a new & changed scan, it's
still the only thing in the library.
The problem lies in the NAMESEARCH column in the contributors table and
the way scanner lookups are apparently being done. Both 'Sinead
O`Connor' and 'Sinead O'Connor' would be stored in the NAMESEARCH
column _without_ the punctuation character, as this accommodates the
way SbS string searches are performed (punctuation is removed and
multiple spaces are compacted to a single space). So the first string
encountered is stored in the database NAME column, the stripped string
in NAMESEARCH (as well as NAMESORT) and subsequent lookups of the
second string with different punctuation match it. Even after
correcting it and running a new & changed scan all of the lookups match
the one with the bad NAME value.
I've always wondered whether the NAMESEARCH column was really
necessary. If the name lookup was done on the NAME column then you
would have had two different artists on the first go, but it would have
been corrected after fixing the tags. It may go back to using a BLOB
for the NAME field and using that field for only display purposes.
An easy fix for the current schema would be that after doing a lookup
to see if a record exists, also compare the raw name to the value of
the NAME column returned in the lokup. If they differ, update the
record. You end up with a 'last in' type of behavior instead of the
current 'first in', but it would only affect strings that differ only
by their punctuation. When the new & changed scan is run it would then
fix the NAME column. Can't say how expensive this would be, but the
updates would be very infrequent. You'd want to do the same thing for
all tables with a NAMESEARCH field.
--
JJZolx
------------------------------------------------------------------------
JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10
View this thread: http://forums.slimdevices.com/showthread.php?t=81548
_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/beta
