I'll keep my AirTable up and updated for a while, no worries :). As to the "fixes", first two points I mentioned are definitely worthwhile, but maybe the third shouldn't be addressed?

I've always felt that by filtering out some of GOG's versioning problems they never really got any incentive to address them :/.

I've reported some of the versioning problems weeks and months ago directly to GOG support. They were silently ignored.

A bit of "public shaming" can do wonders, and the GOG DB has a lot more visibility than my glorified spreadsheet ;).

I tried that too --- https://www.gog.com/forum/general/the_forest_of_forgotten_fickets

Thanks, enjoy your retirement! ;)

They're at the bottom of the page, legitimate entries and are not hurting anyone. I don't see a reason to cut off the list at an arbitrary date.

That's a good suggestion, I can probably implement that very easily.

Everything in GOG DB is designed to require no regular maintenance because I have very little interest in personally reviewing results and crowdsourcing the data is also laborious and requires human interaction. If someone else wants to maintain a blacklist I'm open to taking that into account and pointing people to them. A simple text file on Github would be perfect, a forum thread where somebody manually confirms submissions works too. As long as I'm not responsible for keeping it updated I'm open to suggestions.

Fair enough, but they're going to be there until the end of times :P. You have been warned.

... story of my life until you've kindly provided a retirement option :P.

I assume by "blacklist" you mean a text file with ids which you'd simply hide in your list, right?

I can probably add something to GitHub once you've finalized the changes. It's not like I'll throw away my current delta code, so I can maintain a known false positive list reasonably up to date. If anyone wants to contribute to the maintenance I'm fine with sharing the GitHub repo.

I think ID + the specific versions is better, because any future updates should be flagged again. These 3 values separated by your favorite unicode separation character in a text file works or any other common data format like JSON or CSV.

That's actually pretty much how I do it currently, so makes sense. I'll create a draft later next week. Will probably add the game title as an extra field, as well as the reason for blacklisting, for readability. I expect 99% of entries to be semi-permanent anyway. Oh, and most likely I'll go for a CSV since I can easily export it from my current discrepancy table. Will post back once I get around to it. Cheers!

Yes, you're right. I've quickly dismissed them as being worthless and frankly forgot that the other ids only included an empty prices.json and no changes.json. That's fine, I can see how the changelog could still have some informational value in the future, if anything else happens with those products. I've adjusted my script to account for these cases and everything is running smoothly now, as it did before. Thanks again!

EDIT: As for your version discrepancy discussion: If you would like to keep all entries visible, maybe it would make sense to colorcode or otherwise visually distinguish legacy installers and false positives from the discrepancies that actually differ in content.

That's not a bad idea at all. Instead of not listing the ids covered in the blacklist I'll create, you could simply gray them out and add a legend to explain they're known false positives. I guess that's the best of both worlds.

Just out of curiosity, how often will the new table be updated? I get the feeling it's automated, so perhaps daily, or real-time?

Oh, and I wouldn't mind seeing a column for the discrepancy age.

Every 2 hours, just like the rest of the site. I won't add a column with discrepancy age because it's unlikely going to be different than the build age. It can't be longer than the build age (can't be outdated before the version is released) and the only way for it to be shorter is if a download is released that matches the version, which is later rolled back. Just not worth dealing with state data.

Thanks for the reply. I wasn't clear about what I wanted to see. Anything on this list has a difference between the last uploaded build and the last uploaded downloader. That's the difference I'd like to see and maybe some of the large numbers would help kick gog into gear about fixing them.