Oh dear! I think I may have to install a spell checker in my Visual Studio. Sometimes I just get blind to my own spelling mistakes.
But DJ Doena was kind enough to be my spell checker today. 

So no more "Mismathcing IDs" in version 1.0.1. 

I'm always grateful when people point out my mistakes, big or small!

And btw, I almost misspelled "spell checker" above. Wouldn't that be ironic? 

Edit: I have installed a spell checker. So from now on, if there are any more "misspellments" in my programs, I can always blame the spell checker! 

I found your tool to be both useful and interesting. Not only was it easy to find contribution mistakes, it also exposed what I think is a flaw with DVDprofiler that allowed mistakes to be made.

After studying the contribution notes of the various mismatches found in my library, I found most were Blu-rays and the one common denominator was the "Change UPC/Locality" function.

Too often contributors would take short-cuts when configuring new DiscID profiles by cloning a foreign DiscID profile and using "Change UPC/Locality" to modify the profile name and locality and submit it for approval.

The problem with that process was the contents of the profile had not changed and the original foreign DiscID had remained in the new profile.

So DVDprofiler had no validation check on the newly created DiscID profile and the screeners did not carry out checks on the validity of the disc information within the profile to ensure it matched the profile name. Rather, it was up to the contributor to check the disc information was consistent with the newly created DiscID profile name.

Hence, the mistakes.

Yes, that's another mismatch scenario I observed as well when the contributor added a different Blu-ray DiscID to a foreign Blu-ray DiscID profile which was approved. The DVDprofiler program didn't validate the DiscID variation and the screeners didn't detect the anomaly.

With regards to the DVD DiscID conundrum, yes, I've been thinking about adding multiple DiscIDs into a single DiscID profile as a potential solution for some time, but I discounted it as a viable solution as it would break the cardinal rule that there should be a one-to-one relationship between the DiscID profile name and the DiscID in the disc information section of the profile.

If we allow multiple DVD DiscIDs in a single DVD DiscID profile, it sets a precedent for changing DiscIDs in Blu-ray DiscID profiles and 4K DiscID profiles as well. If we can't use the original DiscID profile name as our single reference how can we prove which DiscID is correct?

Here's another observation you may wish to consider:

• Alternate DiscID profiles have a different profile ID name beginning with typically "VV..........." which don't match the DiscID in the Disc Information section.

Oh yes you do!

Just look at the XML, its all there. Example VV1G3QULL3TQ0I302.xml.

  <ProfileTimestamp>2018-03-10T02:06:32.000Z</ProfileTimestamp>
  <ID>VV1G3QULL3TQ0I302</ID>
  <ID_Base>I0C07AF56A3EE8123</ID_Base>
  <ID_VariantNum>2</ID_VariantNum>
  <ID_LocalityID>0</ID_LocalityID>
  <ID_LocalityDesc>United States</ID_LocalityDesc>
  <ID_Type>DiscID</ID_Type>

Remove the "I" from ID base, and you get the original 16 digit hex disc ID.

I sent you a PM for how to do it with the API.

IdCheck version 1.1.1

I don't quite know what to say. Looking at the code I see that I actually did the comparison correctly, even for alternate IDs. I just should have displayed the original ID instead of the alternate ID. Color me absent minded.

So I changed that, and added a checkmark to show that the profile actually has a alternate ID.
But I also found I bug that I fixed, so it was good that I had to have a close look at the code. It turns out that double clicking a row to select the profile in Profiler only worked for US profiles. Doh!    Anyway, that's been fixed. And now it looks like this:



There is something screwy, though. It looks like we actually can get different IDs on a new submission. I'm going to have to dig deeper to investigate that.

Note: The Disc IDs don't actually start with "I". This was added to make the comparison easier since the profile ID does start with an "I". Maybe I ought to have dropped it in the display? Call me lazy ...

And reminder: "Profile ID" includes Locality. An Invelos anomaly is that a Profile ID with Locality 0, "United States", is usually displayed without the ".0".

So, if your table were labelled "Profile ID Base" or "UPC/EAN", it would be more accurate, or you could include the locality in the table. In fact, it is not clear how what your table would display for profiles with the same ID Base and different localities?

On your second point, again Invelos is full of confusions. Look at the collection columns. Disc ID appears in the UPC column, but identified within the cell as a Disc ID. And of course, internally, the database stores the UPC, DiscID, manual ID, and alternate ID in the same field.

I agree with your point about locality suffix, but of course the column is available in the collection tab. And unless you show it, how can you distinguish two entries in your table that have the same Disc ID, but different localities?

Minor side point: Adding to collection "multiple", and flag sets, both use the internal profile ID format, including the locality suffix with the US exception. While not explicitly in the UI, anybody who uses those, must understand the format.