It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
Kalanyr: Okay, I see the problem here. Those are strict duplicates that would usually be passively omitted but (we) never scan installers + extras *together* for those because this never happened when wooly originally wrote the code for this or at the times I've updated it. I'll make a note to add this for the next update. I'll have to check if GOG provides MD5s for those extras as well ( they almost never do but they might in this case )
They sometimes do. Usually only when the extras are unsupported installers.

But there are so few of them that I also decided to skip looking for MD5s for extras in my downloader.
avatar
Kalanyr: Okay, I see the problem here. Those are strict duplicates that would usually be passively omitted but (we) never scan installers + extras *together* for those because this never happened when wooly originally wrote the code for this or at the times I've updated it. I'll make a note to add this for the next update. I'll have to check if GOG provides MD5s for those extras as well ( they almost never do but they might in this case )
avatar
Geralt_of_Rivia: They sometimes do. Usually only when the extras are unsupported installers.
See below, I think this should answer the question (with: "No, they don't here!"):
!md5_xmls/master_of_magic_classic$ ls -lArtR
.:
insgesamt 4
drwxrwsr-x 4 games games 4096 30. Mär 2025 downloads

./downloads:
insgesamt 8
drwxrwsr-x 5 games games 4096 30. Mär 2025 windows
drwxrwsr-x 5 games games 4096 30. Mär 2025 linux

./downloads/windows:
insgesamt 12
drwxrwsr-x 2 games games 4096 30. Mär 2025 français
drwxrwsr-x 2 games games 4096 30. Mär 2025 English
drwxrwsr-x 2 games games 4096 30. Mär 2025 Deutsch

./downloads/windows/français:
insgesamt 4
-rw-rw-r-- 1 games games 2030 30. Mär 2025 'setup_master_of_magic_1.3.1_(french)_(28044).exe.xml'

./downloads/windows/English:
insgesamt 4
-rw-rw-r-- 1 games games 2242 30. Mär 2025 'setup_master_of_magic_classic_momc_1.60.00_(67790).exe.xml'

./downloads/windows/Deutsch:
insgesamt 4
-rw-rw-r-- 1 games games 503 30. Mär 2025 'setup_master_of_magic_1.3.1_(german)_(28044).exe.xml'

./downloads/linux:
insgesamt 12
drwxrwsr-x 2 games games 4096 30. Mär 2025 français
drwxrwsr-x 2 games games 4096 30. Mär 2025 English
drwxrwsr-x 2 games games 4096 30. Mär 2025 Deutsch

./downloads/linux/français:
insgesamt 4
-rw-rw-r-- 1 games games 1897 30. Mär 2025 gog_master_of_magic_french_2.0.0.3.sh.xml

./downloads/linux/English:
insgesamt 4
-rw-rw-r-- 1 games games 381 30. Mär 2025 gog_master_of_magic_2.0.0.3.sh.xml

./downloads/linux/Deutsch:
insgesamt 4
-rw-rw-r-- 1 games games 388 30. Mär 2025 gog_master_of_magic_german_2.0.0.3.sh.xml
avatar
ChFra: See below, I think this should answer the question (with: "No, they don't here!")
They certainly did it in the past.

For example, trying to get the XML for the file witcher3_lang_de_2.0.0.52.exe (which is the Witcher 3 Classic DE Language Patch Part1, which is an extra for The Witcher 3: Wild Hunt) results in:

<file name="witcher3_lang_de_2.0.0.52.exe" available="1" notavailablemsg="" md5="af62945656154bd876435ae62150b4d9" chunks="1" timestamp="2016-09-15 15:50:41" total_size="799312">
<chunk id="0" from="0" to="799311" method="md5">af62945656154bd876435ae62150b4d9</chunk>
</file>
avatar
Geralt_of_Rivia: They certainly did it in the past.
Thet's why I've written:
avatar
ChFra: See below, I think this should answer the question (with: "No, they don't here!")
For those instances where they do NOT provide checksums, we've unfortunately no means of detecting duplicates before having downloaded the whole file. I think they should provide checksums for everything. This is just good practice. Perhaps it would even lower the burden on their servers, because it allows sophisticated downloaders to avoid downloads at the potentially smaller cost of creating those sums.

I'm wondering if it were still worth the effort to implement "cross section" checksum checks. You don't want to add error-prone complexity for cases occuring really seldom and doing no "real" harm (other than wasting some space) if they're encountered, I think.
Post edited May 11, 2026 by ChFra
Is it only possible to download the game's image backgrounds (with -covers) or also the screenshots?

Also, are the extra subfolders "image_url\images-N.gog-statics.c0m" unavoidable? (the path isn't fixed too)
avatar
phaolo: Is it only possible to download the game's image backgrounds (with -covers) or also the screenshots?

Also, are the extra subfolders "image_url\images-N.gog-statics.c0m" unavoidable? (the path isn't fixed too)
Only supports covers and backgrounds, I don't think screenshots are possible without significant messing around ( those are stored in the shop info of the games not the library API IIRC )

I can probably adjust those folders to not appear if covers/backgrounds have never been run but they are unavoidable after that because the path preservation is how changes are detected ( that's why the path isn't fixed ).
avatar
phaolo: Is it only possible to download the game's image backgrounds (with -covers) or also the screenshots?

Also, are the extra subfolders "image_url\images-N.gog-statics.c0m" unavoidable? (the path isn't fixed too)
avatar
Kalanyr: Only supports covers and backgrounds, I don't think screenshots are possible without significant messing around ( those are stored in the shop info of the games not the library API IIRC )

I can probably adjust those folders to not appear if covers/backgrounds have never been run but they are unavoidable after that because the path preservation is how changes are detected ( that's why the path isn't fixed ).
But you do have the game's ID in the library API and once you have that what's stopping you from getting

https://api.gog.com/v2/games/ID

and collecting all the screenshot URLs from there?

Have a look at Doom Eternal for example.

You'll find all the screenshot URLs under _embedded.screenshots[]._links.self.href.
Post edited May 18, 2026 by Geralt_of_Rivia
avatar
Kalanyr: Only supports covers and backgrounds [..]
[..] those folders [..] they are unavoidable
Oh ok, thanks.

--

Btw I've also realized that gogrepoc doesn't grab this info:
- developer\publisher
- genres after the first
- rating decimals

Is such data also too troublesome to get?
avatar
Kalanyr: Only supports covers and backgrounds, I don't think screenshots are possible without significant messing around ( those are stored in the shop info of the games not the library API IIRC )

I can probably adjust those folders to not appear if covers/backgrounds have never been run but they are unavoidable after that because the path preservation is how changes are detected ( that's why the path isn't fixed ).
avatar
Geralt_of_Rivia: But you do have the game's ID in the library API and once you have that what's stopping you from getting

https://api.gog.com/v2/games/ID

and collecting all the screenshot URLs from there?

Have a look at Doom Eternal for example.

You'll find all the screenshot URLs under _embedded.screenshots[]._links.self.href.
Last time I looked into this the unofficial API write up specifically said the IDs weren't strictly consistent across library and shop ( they mostly are but suddenly grabbing stuff for the wrong game would be bad ). If that's no longer the case I can do more cross-referencijg.
avatar
Geralt_of_Rivia: But you do have the game's ID in the library API and once you have that what's stopping you from getting

https://api.gog.com/v2/games/ID

and collecting all the screenshot URLs from there?

Have a look at Doom Eternal for example.

You'll find all the screenshot URLs under _embedded.screenshots[]._links.self.href.
avatar
Kalanyr: Last time I looked into this the unofficial API write up specifically said the IDs weren't strictly consistent across library and shop ( they mostly are but suddenly grabbing stuff for the wrong game would be bad ). If that's no longer the case I can do more cross-referencijg.
That's strictly speaking true because the product IDs that you find in the library are the product IDs of the games themselves while what you buy in the shop can not only be games but also bundles (different editions which are bundled with different extras or DLC, bundles with other games, Amazon, etc.) which can have a different product ID than the game but I have never seen a product ID from the library point to a different game in the shop. As far as I know the product IDs are unique. You should be able to use the product ID from the library in all GOG APIs and not only in the API referencing the library and it should always point to the same item.
avatar
Kalanyr: Last time I looked into this the unofficial API write up specifically said the IDs weren't strictly consistent across library and shop ( they mostly are but suddenly grabbing stuff for the wrong game would be bad ). If that's no longer the case I can do more cross-referencijg.
avatar
Geralt_of_Rivia: That's strictly speaking true because the product IDs that you find in the library are the product IDs of the games themselves while what you buy in the shop can not only be games but also bundles (different editions which are bundled with different extras or DLC, bundles with other games, Amazon, etc.) which can have a different product ID than the game but I have never seen a product ID from the library point to a different game in the shop. As far as I know the product IDs are unique. You should be able to use the product ID from the library in all GOG APIs and not only in the API referencing the library and it should always point to the same item.
That is good to know, thank you.
New problem:

Every year, when the "Warhammer Skulls" video games festival takes place, GOG gives a package for free, mostly desktop walllpapers & coupons, sometimes even with a game. These days I obtained the "Warhammer Skulls 2026 Digital Goodie Bag", very similar to the "Warhammer Skulls 2025 Digital Goodie Bag" from last year. In particular, both come with a file called "cubicle_7_discount.zip", of course one with the coupon for last year, the other with a new one for this year. When you've both "packages" in your "library" on GOG, and none of them hidden, and, like me, have set up a cron job to download "everything which is missing", then the 2 files will be constantly overwritten: on each "turn" the existing one will be moved to "!orphaned" (and subsequently deleted by the "clean" function, if you wish), and the now "missing" one will be downloaded to replace it. Next time, of course, the other one will be missing, as soon as its "package ID" has been checked for missing files.

I'm reporting this, but don't see a possible solution for such behaviour, except setting the old package to "hidden".


Oh, sorry, I've forgotten to mention that I keep all those "Skulls" packages in the same directory symbolically linked to each year's "package name". Otherwise they obviously would probably happily co-exist in 2 differently named directories.
Post edited May 23, 2026 by ChFra
avatar
ChFra: I'm reporting this, but don't see a possible solution for such behaviour, except setting the old package to "hidden".

Oh, sorry, I've forgotten to mention that I keep all those "Skulls" packages in the same directory symbolically linked to each year's "package name". Otherwise they obviously would probably happily co-exist in 2 differently named directories.
Having 2 options to resolve the issue on my side (different directories or "hide" one item), I'm turning this into a feature request: new option "-rename-duplicates" or alike, which doesn't move those to "!orphaned", but renames those files instead (with a time-stamp prefix or something alike).

On a 2nd thought, it wouldn't be THAT easy, because if not keeping track of this action, one would end up with the unrenamed file still being downloaded repeatedly.
avatar
ChFra: I'm reporting this, but don't see a possible solution for such behaviour, except setting the old package to "hidden".

Oh, sorry, I've forgotten to mention that I keep all those "Skulls" packages in the same directory symbolically linked to each year's "package name". Otherwise they obviously would probably happily co-exist in 2 differently named directories.
avatar
ChFra: Having 2 options to resolve the issue on my side (different directories or "hide" one item), I'm turning this into a feature request: new option "-rename-duplicates" or alike, which doesn't move those to "!orphaned", but renames those files instead (with a time-stamp prefix or something alike).

On a 2nd thought, it wouldn't be THAT easy, because if not keeping track of this action, one would end up with the unrenamed file still being downloaded repeatedly.
Yeah, the problem here is the symbolic linking, I've actually thought about trying to do this automatically in the script for cross game duplicate files but I've never come up with anything that I'm remotely happy with.

There isn't actually a clean up step that removes duplicate files per se, manifest duplicates get resolved/removed within a given game but file duplicate files get removed because they fail to match anything in the manifest, so from the perspective of the script they aren't duplicates they are just weird files that happen to be in the directory and get treated the same way.
Bug report: The 'update -lang cn' option doesn't work.

I have several games in my library with separate chinese language installer files. But the corresponding files are not in the manifest. The german installer files on the other hand are there.

I think this is because there are two different chinese writing systems: traditional chinese and simplified chinese.
Does your script differentiate between them?