> Hi!
>
> Is it possible that the CD entries with old-style (MD5 based) ID
> calculation were not subject of a migration to the new-style
> (SHA1 based) ID?
CDindex is backwards compatible with MD5 clients (they'll still
get all the records they entered, and if there were a lot of them being
used, I suppose MD5 IDs could be created for new records automatically)
BUT The MD5 client wasn't providing very much info to the database in
the submit process. It relied on the MD5 ID being unique forever, and
only tells the server that ID and a track count IIRC.
So it was impossible to calculate SHA1 ID numbers for the albums which
were entered by the MD5 client. These albums remain in the database,
and by now most of them have associated SHA1 ID numbers.
> My reason for this suspicion:
>
> I hacked up the latest cdindex demo client to run under FreeBSD
> but was not able too get successful lookups of some of my CDs
> that are in the database.
This makes sense. However, those CDs are in the database still, they
just need a new ID number associated with them, as you seem to have
discovered.
> Example Björk: Post
[snip]
Four IDs are currently associated with this album in the index. Presumably
the first ID, in the MD5 style was your original entry, I know the third
one is my UK copy (probably a slightly different pressing) and the final
one is the SHA1 identifier for your new entry.
16EB9914688E6E00FA87E607581973F4
qlxGYSacB5ejBq.req7vsESwUuo-
Yxn157NYSWRyCGO8l1hmXPCNG3E-
m1WjfYjQRY48XLUeb0jydF0s2tc-
> For debugging purposes it would be helpful, if it was possible
> to display the ID of an stored entry, maybe date of entry too.
For an entry looked up from the TOC data, simply use xget.pl instead of
get.pl or hget.pl when calculating the URL for the HTTP lookup. I can't
persuade the web-based search to give up XML data (which has the IDs
embedded in it) so I guess Rob doesn't allow that (yet?)
Nick.