https://api.gog.com/v2/games/1 has the box art in _links.boxArtImage. How are you doing it now?

I'm using your https://www.gogdb.org/data/products/ url to get it now.
Before that I was using https://gamesdb.gog.com/platforms/gog/external_releases/
And before that I had used the one you mentioned, but I changed for some reason and I don't know why or when *shrug*

I think gamesdb works for a bigger number of games than any other API.

Ah, it could be to do with packaged games then. I know I always used to have issues with that and I think I remember changing something to fix it.

I noticed that some games have an unlikely GOG release date: 1991-12-25.
Is it possible to fix the problem or is the data no longer available?

That might be the default date of the operating system, used when no date is available. I don't know what is used these days, it used to be an earlier date.

This is authentic GOG data, I have no better source. I usually try to work around their mess, but in this case I can't.

It's Christmas in 1991. You are young. You get up in the morning and there's a new video game under the brightly decorated tree. Nothing to do but play it all day long. Life is good. :P

That's typically 1970-01-01...

I see, and I don't find it hard to believe. XD

Good memories, good memories... GOGbears once again played with our feelings.

Have you had the time to look at the problem or fix it yet? When I run my scripts, it still detects all the discrepancies. Or is it maybe a matter of having to clean up the broken entries?

I can share my code with you, no problem. It's written in amateur python, so maybe you can make use of it. I don't want to make it public though, given how it's a structural nightmare. Feel free to message me should you be interested.

I deleted the empty price files a while ago. It just occurred to me that you are probably still iterating the empty directories, which I forgot to delete. They will be gone with the next dump. Sorry for the late response, I was on vacation.

Thanks, most of the problematic product ids are gone now. However, there are still 77 left when I run my script against the current gogdb_2022-09-09.tar.xz. I've uploaded a full list for you here.

I've added my own version of WinterSnowfall's download version mismatch table at https://www.gogdb.org/user/version_mismatch (with his approval). It will be better integrated into the site later.

These products have a changelog entry of when they were added, so I won't remove them for being empty.

Ah, now I can finally retire and grab that margarita on a tropical island somewhere :P. Glad to see this up and running and thank you for your work. It looks better part of GOG DB, gotta say :).

However, it does look like you're capturing more data that you should be (at least compared to my current code), mostly due to the following:

- I simply skip comparisons for any offline installer that matches on .*(gog-.*)$ - this is because they're legacy versioned installers that are most likely in sync with Galaxy and haven't been updated in literal years anyway

- I don't collect any build versions from named branches (such as "dev" or "beta") - those won't ever get offline installers so the discrepancies will be artificial. It was first brought to my attention by mrkgnao but matches my observations anyway.

- there are some that will be blatantly false positives (like The Little Acre) - having a manual way of ignoring those in the backend and not listing them in the table is useful and what I'm also using at the moment for some entries. I can provide what I've currently marked as manually invalid based on user reports so far, if you're interested - though you could also keep them in the table as they are essentially versioning problems GOG should fix, even if the content is in sync.