Now, if you run test.pl (it should just run straight off),
2004-01-26 02627, 2004
djce
you'll see it trying out this theory.
2004-01-26 02642, 2004
djce
it spits out approx 76 lines of output, twice.
2004-01-26 02600, 2004
ruaok
mb.pm is missing
2004-01-26 02624, 2004
djce
you can probably comment that out - or just point it towards your mb_server
2004-01-26 02603, 2004
djce
The first set of lines represents one test album I chose. In this case, all the IDs match - i.e. our calculation yields the right result.
2004-01-26 02615, 2004
djce
hence, the output lines end in "Y" (== a good match)
2004-01-26 02632, 2004
djce
for the second set, the values don't match ("n")
2004-01-26 02610, 2004
djce
So basically I think we've been doing it wrong for a while; the good news: we can easily fix the algorithm.
2004-01-26 02622, 2004
djce
The bad news: has this introduced any bad data into the db?
2004-01-26 02630, 2004
djce
So far, I don't know.
2004-01-26 02641, 2004
ruaok
gimme a sec -- i need to move the files to a location where I can copy the modules
2004-01-26 02646, 2004
djce
ok
2004-01-26 02608, 2004
djce
(I'm done setting out my case now, so I'll go quiet now :-)
2004-01-26 02630, 2004
ruaok
ok, I'll tinker and observe and think
2004-01-26 02652, 2004
djce
thanks
2004-01-26 02646, 2004
djce
(Just out of interest: this arose because I wanted to test Discid.pm. What I was trying to do was find a FreeDB entry, then work out what request to make to MB to cause it to fetch it from FreeDB)
2004-01-26 02613, 2004
djce
(Straight away I found a "bad" case :-( with no match, when there should have been one)
2004-01-26 02615, 2004
ruaok
ok, forget copying to another dir.
2004-01-26 02601, 2004
ruaok
Ok
2004-01-26 02609, 2004
ruaok
I see what you're saying.
2004-01-26 02628, 2004
ruaok
I don't think it will have introduced bad data into MB.
2004-01-26 02648, 2004
ruaok
If a bad id was calculated, then one of the following would've happened:
2004-01-26 02656, 2004
ruaok
1. The CD was not found.
2004-01-26 02622, 2004
ruaok
2. The FreeDB fuzzy matching algorithm matched it up anyways.
2004-01-26 02603, 2004
ruaok
3. A wrong CD was returned for moderation or the user.
2004-01-26 02603, 2004
ruaok
Case #3 is the worst here, no doubt. But that means that a wrong CD may have been inserted, but the actual CD that was inserted is structurally ok.
2004-01-26 02622, 2004
ruaok
I'd say fix the code, update the server and not worry about it more.
2004-01-26 02641, 2004
djce
Hmmm.... I'm not sure if you've covered this case or not:
2004-01-26 02653, 2004
djce
* user requests info using GetCDInfo
2004-01-26 02657, 2004
djce
* not in db
2004-01-26 02603, 2004
djce
* wrong one fetched from FreeDB
2004-01-26 02617, 2004
djce
* wrong album added to MB,
2004-01-26 02617, 2004
Necronom has quit
2004-01-26 02618, 2004
djce
then,
2004-01-26 02637, 2004
djce
* the /right/ disc's MB discid is associated with the /wrong/ly imported album.
2004-01-26 02655, 2004
djce
All under the guise of a "FreeDB moderation".
2004-01-26 02607, 2004
ruaok
hmmmm
2004-01-26 02635, 2004
ruaok
yes, the cdindex id would be a concern. But not the album itself.
2004-01-26 02642, 2004
djce
Right.
2004-01-26 02611, 2004
djce
Track lengths...? It depends which ID - MB or FreeDB - the track lengths are based on.
2004-01-26 02614, 2004
ruaok
we could write a script to verify each of our discids.
2004-01-26 02645, 2004
djce
Feed it through the bad algorithm and see which ones yield a wrong result?
2004-01-26 02655, 2004
ruaok
es, as step one.
2004-01-26 02610, 2004
ruaok
and then for those that generated a bad id, fetch the album again.
2004-01-26 02639, 2004
ruaok
do a sanity check (a coarse one since the data may have been edited) to see if the right album was fetched.
2004-01-26 02601, 2004
ruaok
if we suspect a problem either flag it or imprort the correct album for the CD id.
2004-01-26 02639, 2004
djce
hmmm... ok sounds reasonable. I think we'll thrash out the details of this problem over the next few days (or however long it takes).
2004-01-26 02652, 2004
djce
i.e. I may consult you for advice again :-)
2004-01-26 02637, 2004
ruaok
ok. good detective work.
2004-01-26 02642, 2004
ruaok
brb
2004-01-26 02620, 2004
djce is sorry to welcome ruaok back to the week with such a pain :-(
2004-01-26 02607, 2004
KyleB joined the channel
2004-01-26 02636, 2004
ruaok
djce: no worries. :-)
2004-01-26 02657, 2004
KyleB
how is everyone
2004-01-26 02642, 2004
ruaok
KyleB: busy as usual :-)
2004-01-26 02654, 2004
ruaok is away: chaueffeur
2004-01-26 02655, 2004
KyleB
working on helix stuff?
2004-01-26 02610, 2004
ruaok
that too :-)
2004-01-26 02622, 2004
ruaok is back (gone 00:31:28)
2004-01-26 02656, 2004
ruaok
djce: you around?
2004-01-26 02652, 2004
djce
yes
2004-01-26 02602, 2004
ruaok
wendell asks:
2004-01-26 02604, 2004
KyleB
ruaok, do you think it would create a lot of server strain if people were using it just for metadata queries like return all songs by artist x, but not doing that in the context of moding/tagging?
2004-01-26 02625, 2004
ruaok
djce: What's the easiest way to tell if there is a rejected moderation to merge two artists?
2004-01-26 02638, 2004
ruaok
he is looking at the moderation table.
2004-01-26 02646, 2004
djce
direct SQL you mean?
2004-01-26 02659, 2004
ruaok
general approach.
2004-01-26 02620, 2004
ruaok
I'd say look for merge artist mods and then scan for artist you might be interested in.
2004-01-26 02613, 2004
djce
Does he mean for two /particular/ artists? i.e. you know the IDs already?
2004-01-26 02614, 2004
ruaok
the primiary artist is listed in the artist col and the secondary artist(s) are in the new field, right?
