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: I just checked and I have a proper entry for Alone in the Dark 2 , and the file was downloaded successfully , however it hasn't been updated in ages ( 2019 )/. I recently did a full update too so it should have cleared the entry if it was a proper entry.
I am actually seeing it in the manifest:

[…]
u'downloads': [{u'date': u'',
u'desc': u'Alone in the Dark 2',
u'force_change': False,
u'gog_data': {u'headers': {u'accept-ranges': u'bytes',
u'age': u'49662',
u'connection': u'keep-alive',
u'content-length': u'437126440',
u'content-type': u'application/octet-stream',
u'date': u'Tue, 10 Feb 2026 13:11:28 GMT',
u'etag': u'"7f9a257e659dd55a565f4567ae8c7801-84"',
u'last-modified': u'Wed, 22 Jan 2025 04:35:04 GMT',
u'server': u'envoy',
u'via': u'1.1 varnish, 1.1 varnish',
u'x-amz-meta-mtime': u'1553102535',
u'x-amz-request-id': u'tx00000bbc42087a359cd1a-006956e3cc-1949e3e-default',
u'x-cache': u'HIT, HIT',
u'x-cache-hits': u'939, 0',
u'x-gog-backend': u'l',
u'x-ratelimit-limit': u'20000, 20000;w=1',
u'x-ratelimit-remaining': u'19727',
u'x-ratelimit-reset': u'1',
u'x-served-by': u'cache-fra-etou8220093-FRA, cache-muc13924-MUC'},
u'md5_xml': {u'available': u'1',
u'chunks': u'42',
u'md5': u'6db6990637b15f36628c8fcb30faa2db',
u'name': u'setup_alone_in_the_dark_2_1.0_cs_(28191).exe',
u'notavailablemsg': u'',
u'tag': u'file',
u'timestamp': u'2019-03-20 18:22:16',
u'total_size': u'437126440'},
u'name': u'Alone in the Dark 2',
u'original_headers': {u'Accept-Ranges': u'bytes',
u'Age': u'49662',
u'Connection': u'keep-alive',
u'Content-Length': u'437126440',
u'Date': u'Tue, 10 Feb 2026 13:11:28 GMT',
u'Via': u'1.1 varnish, 1.1 varnish',
u'X-Cache': u'HIT, HIT',
u'X-Cache-Hits': u'939, 0',
u'X-GOG-Backend': u'l',
u'X-Served-By': u'cache-fra-etou8220093-FRA, cache-muc13924-MUC',
u'content-type': u'application/octet-stream',
u'etag': u'"7f9a257e659dd55a565f4567ae8c7801-84"',
u'last-modified': u'Wed, 22 Jan 2025 04:35:04 GMT',
u'server': u'envoy',
u'x-amz-meta-mtime': u'1553102535',
u'x-amz-request-id': u'tx00000bbc42087a359cd1a-006956e3cc-1949e3e-default',
[…]
… there are multiple entries for the installer in quite a few languages, but none of them gets actually downloaded.

avatar
Kalanyr: Have you tried force updating the manifest using -ids alone_in_the_dark_2 ? It's possible there was a communication error at the time and the entry is simply not in your manifest as a result.
No, not exactly like this, I've written a script performing the following actions:

1) Backup of logs and some other things.
2) Update the manifest.
3) Verify files (so that everything already there should be verified when actually downloading).
4) Download chanǵed/new files.
5) Remove leftovers from backups and such (nothing from download folders themselves).

I can sort out the actual command lines (being built from variables) if that helps.

avatar
Kalanyr: ETA - Moving the old file away and then back can cause the result of verifications and last downloaded to desychronize but that should only be a real problem in very rare cases where GOG updates the file without changing the name and the file size doesn't change either ( weird things like the Baldur's Gate III Mac GameData files are the only things particularly likely to have this problem and that's probably finished updating for the immediate future, most of the other games with this issue also are no longer currently updating ).
So the following should be safe?:
1) Move "gog-manifest.dat" away.
2) Update the manifest with "-full".
3) Verify everything again with "-forceverify".
4) Download.
avatar
Kalanyr: I just checked and I have a proper entry for Alone in the Dark 2 , and the file was downloaded successfully , however it hasn't been updated in ages ( 2019 )/. I recently did a full update too so it should have cleared the entry if it was a proper entry.
avatar
ChFra: I am actually seeing it in the manifest:

[…]
u'downloads': [{u'date': u'',
u'desc': u'Alone in the Dark 2',
u'force_change': False,
u'gog_data': {u'headers': {u'accept-ranges': u'bytes',
u'age': u'49662',
u'connection': u'keep-alive',
u'content-length': u'437126440',
u'content-type': u'application/octet-stream',
u'date': u'Tue, 10 Feb 2026 13:11:28 GMT',
u'etag': u'"7f9a257e659dd55a565f4567ae8c7801-84"',
u'last-modified': u'Wed, 22 Jan 2025 04:35:04 GMT',
u'server': u'envoy',
u'via': u'1.1 varnish, 1.1 varnish',
u'x-amz-meta-mtime': u'1553102535',
u'x-amz-request-id': u'tx00000bbc42087a359cd1a-006956e3cc-1949e3e-default',
u'x-cache': u'HIT, HIT',
u'x-cache-hits': u'939, 0',
u'x-gog-backend': u'l',
u'x-ratelimit-limit': u'20000, 20000;w=1',
u'x-ratelimit-remaining': u'19727',
u'x-ratelimit-reset': u'1',
u'x-served-by': u'cache-fra-etou8220093-FRA, cache-muc13924-MUC'},
u'md5_xml': {u'available': u'1',
u'chunks': u'42',
u'md5': u'6db6990637b15f36628c8fcb30faa2db',
u'name': u'setup_alone_in_the_dark_2_1.0_cs_(28191).exe',
u'notavailablemsg': u'',
u'tag': u'file',
u'timestamp': u'2019-03-20 18:22:16',
u'total_size': u'437126440'},
u'name': u'Alone in the Dark 2',
u'original_headers': {u'Accept-Ranges': u'bytes',
u'Age': u'49662',
u'Connection': u'keep-alive',
u'Content-Length': u'437126440',
u'Date': u'Tue, 10 Feb 2026 13:11:28 GMT',
u'Via': u'1.1 varnish, 1.1 varnish',
u'X-Cache': u'HIT, HIT',
u'X-Cache-Hits': u'939, 0',
u'X-GOG-Backend': u'l',
u'X-Served-By': u'cache-fra-etou8220093-FRA, cache-muc13924-MUC',
u'content-type': u'application/octet-stream',
u'etag': u'"7f9a257e659dd55a565f4567ae8c7801-84"',
u'last-modified': u'Wed, 22 Jan 2025 04:35:04 GMT',
u'server': u'envoy',
u'x-amz-meta-mtime': u'1553102535',
u'x-amz-request-id': u'tx00000bbc42087a359cd1a-006956e3cc-1949e3e-default',
[…]
avatar
ChFra: … there are multiple entries for the installer in quite a few languages, but none of them gets actually downloaded.

avatar
Kalanyr: Have you tried force updating the manifest using -ids alone_in_the_dark_2 ? It's possible there was a communication error at the time and the entry is simply not in your manifest as a result.
avatar
ChFra: No, not exactly like this, I've written a script performing the following actions:

1) Backup of logs and some other things.
2) Update the manifest.
3) Verify files (so that everything already there should be verified when actually downloading).
4) Download chanǵed/new files.
5) Remove leftovers from backups and such (nothing from download folders themselves).

I can sort out the actual command lines (being built from variables) if that helps.

avatar
Kalanyr: ETA - Moving the old file away and then back can cause the result of verifications and last downloaded to desychronize but that should only be a real problem in very rare cases where GOG updates the file without changing the name and the file size doesn't change either ( weird things like the Baldur's Gate III Mac GameData files are the only things particularly likely to have this problem and that's probably finished updating for the immediate future, most of the other games with this issue also are no longer currently updating ).
avatar
ChFra: So the following should be safe?:
1) Move "gog-manifest.dat" away.
2) Update the manifest with "-full".
3) Verify everything again with "-forceverify".
4) Download.
Yes, though that should mostly be unnecessary. In the absence of an existing manifest, the first attempt is -full by default (you'll need to overide the lang and OS though, I think ). Likewise because it's a new manifest everything will be considered unverified and will verify by default the first time you run verify

There will probably be an unintended side effect though, for installer files that lack MD5s , their last downloaded will be cleared so it'll be considered that they need updating by default ( extras work the opposite way, you can force that behaviour with a flag but they assume if the name and size is correct then all is good by default, this was a practical decision since extras extremely rarely have MD5s and are very rarely exactly 4 GB in size which is the cause of installers / GameData failing to get marked for updating when they sometimes should ).

ETA - Regarding Alone in the Dark 2, I wanted to check before I commented and I now have. Your entries are definitely bad for some reason. There is MD5 XML data available for those files so I think it must have had a problem while you were updating at some point.


'md5_xml':
{'available': '1',
'chunks': '42',
'md5': '6db6990637b15f36628c8fcb30faa2db',
'name': 'setup_alone_in_the_dark_2_1.0_cs_(28191).exe',
'notavailablemsg': '',
'tag': 'file',
'timestamp': '2019-03-20 18:22:16',
'total_size': '437126440'},
Post edited February 12, 2026 by Kalanyr
Hello Kalanyr,

I have tried to download both ATOM games today, and I got these errors. Can you please check out, what might be the issue for me? Other games I've tried last few weeks seems fine.

(command included)

(also if you need the values from <redacted> fields, I can send them to you by PM)

EDIT: both files have been downloaded though.

gogrepoc.py update -os windows linux -lang en -ids atom_rpg_postapocalyptic_indie_game atom_rpg_trudograd

11:51:52 | loading local manifest...
11:51:53 | loading token...
11:51:53 | loading local resume manifest...
11:51:53 | fetching game product data (page 1)...
11:51:54 | scanning found "atom_rpg_postapocalyptic_indie_game" in product data!
11:51:54 | scanning found "atom_rpg_trudograd" in product data!
11:51:54 | saving resume manifest...
11:51:54 | saved resume manifest
11:51:54 | (1 / 2) fetching game details for atom_rpg_postapocalyptic_indie_game...
11:51:57 | request failed: 404 Client Error: Not Found for url: https: //gog-cdn-fastly.gog.com/token=nva=<redacted>~dirs=6~token=<redacted>/secure/linux_offlines/167336 7037/1673367037/57186263152814002/2281/atom_rpg_post_apocalyptic_indie_game_1_190_70193.sh.xml. will not retry.
11:51:57 | no md5 data found for atom_rpg_post_apocalyptic_indie_game_1_190_70193.sh
11:51:58 | request failed: 403 Client Error: Forbidden for url: https: //cdn.gog.com/secure/linux_offlines/1673367037/1673367037/57186263152814002/2281/atom_rpg_post_apocalyptic_ind ie_game_1_190_70193.sh?<redacted>&fileExtForIe=.exe. will not retry.
11:51:58 | failed to fetch https: //www.gog.com/downlink/atom_rpg_postapocalyptic_indie_game/en3installer0
11:51:58 | Successfully fetched file info from https: //www.gog.com/downloads/atom_rpg_postapocalyptic_indie_game/en3installer0 but no md5 data was available
11:51:59 | request failed: 404 Client Error: Not Found for url: https: //gog-cdn-fastly.gog.com/token=nva=<redacted>~dirs=6~token=<redacted>/secure/linux_offlines/167336 7037/2085203195/57186263152814002/5416/atom_rpg_supporter_pack_1_190_70193.sh.xml. will not retry.
11:51:59 | no md5 data found for atom_rpg_supporter_pack_1_190_70193.sh
11:52:00 | request failed: 403 Client Error: Forbidden for url: https: //cdn.gog.com/secure/linux_offlines/1673367037/2085203195/57186263152814002/5416/atom_rpg_supporter_pack_1_190 _70193.sh?<redacted>&fileExtForIe=.exe. will not retry.
11:52:00 | failed to fetch https: //www.gog.com/downlink/atom_rpg_supporter_pack/en3installer0
11:52:00 | Successfully fetched file info from https: //www.gog.com/downloads/atom_rpg_supporter_pack/en3installer0 but no md5 data was available
11:52:01 | (2 / 2) fetching game details for atom_rpg_trudograd...
11:52:05 | saving manifest...
11:52:06 | saved manifest
11:52:06 | saving resume manifest...
11:52:06 | saved resume manifest
11:52:06 | --
11:52:06 | total time: 0:00:14.518677
11:52:06 | exiting...
Post edited February 22, 2026 by MMLN
avatar
MMLN: Hello Kalanyr,

I have tried to download both ATOM games today, and I got these errors. Can you please check out, what might be the issue for me? Other games I've tried last few weeks seems fine.

(command included)

(also if you need the values from <redacted> fields, I can send them to you by PM)

EDIT: both files have been downloaded though.

gogrepoc.py update -os windows linux -lang en -ids atom_rpg_postapocalyptic_indie_game atom_rpg_trudograd

11:51:52 | loading local manifest...
11:51:53 | loading token...
11:51:53 | loading local resume manifest...
11:51:53 | fetching game product data (page 1)...
11:51:54 | scanning found "atom_rpg_postapocalyptic_indie_game" in product data!
11:51:54 | scanning found "atom_rpg_trudograd" in product data!
11:51:54 | saving resume manifest...
11:51:54 | saved resume manifest
11:51:54 | (1 / 2) fetching game details for atom_rpg_postapocalyptic_indie_game...
11:51:57 | request failed: 404 Client Error: Not Found for url: https: //gog-cdn-fastly.gog.com/token=nva=<redacted>~dirs=6~token=<redacted>/secure/linux_offlines/167336 7037/1673367037/57186263152814002/2281/atom_rpg_post_apocalyptic_indie_game_1_190_70193.sh.xml. will not retry.
11:51:57 | no md5 data found for atom_rpg_post_apocalyptic_indie_game_1_190_70193.sh
11:51:58 | request failed: 403 Client Error: Forbidden for url: https: //cdn.gog.com/secure/linux_offlines/1673367037/1673367037/57186263152814002/2281/atom_rpg_post_apocalyptic_ind ie_game_1_190_70193.sh?<redacted>&fileExtForIe=.exe. will not retry.
11:51:58 | failed to fetch https: //www.gog.com/downlink/atom_rpg_postapocalyptic_indie_game/en3installer0
11:51:58 | Successfully fetched file info from https: //www.gog.com/downloads/atom_rpg_postapocalyptic_indie_game/en3installer0 but no md5 data was available
11:51:59 | request failed: 404 Client Error: Not Found for url: https: //gog-cdn-fastly.gog.com/token=nva=<redacted>~dirs=6~token=<redacted>/secure/linux_offlines/167336 7037/2085203195/57186263152814002/5416/atom_rpg_supporter_pack_1_190_70193.sh.xml. will not retry.
11:51:59 | no md5 data found for atom_rpg_supporter_pack_1_190_70193.sh
11:52:00 | request failed: 403 Client Error: Forbidden for url: https: //cdn.gog.com/secure/linux_offlines/1673367037/2085203195/57186263152814002/5416/atom_rpg_supporter_pack_1_190 _70193.sh?<redacted>&fileExtForIe=.exe. will not retry.
11:52:00 | failed to fetch https: //www.gog.com/downlink/atom_rpg_supporter_pack/en3installer0
11:52:00 | Successfully fetched file info from https: //www.gog.com/downloads/atom_rpg_supporter_pack/en3installer0 but no md5 data was available
11:52:01 | (2 / 2) fetching game details for atom_rpg_trudograd...
11:52:05 | saving manifest...
11:52:06 | saved manifest
11:52:06 | saving resume manifest...
11:52:06 | saved resume manifest
11:52:06 | --
11:52:06 | total time: 0:00:14.518677
11:52:06 | exiting...
This is a normal output when GOG fails to provide MD5 information for specific files, this:
Successfully fetched file info from https: //www.gog.com/downloads/atom_rpg_supporter_pack/en3installer0 but no md5 data was available

indicates that the files will be treated the same way as extras are ( ie verified by file size and name only ) .

You get a different error if there's a major problem and file info can't be fetched.
Just as a small headsup for those who care / might find it a problem, the python 3.14 modules are now updated to the point I can move over, there will probably be a small to gogrepoc to fix the 3.14 deprecation issues in the next week or so, first to dev then to main after the usual test period. It'll be a bit longer before I work on anything serious.
This may require some more testing than I had anticipated since I'm not sure how far backwards compatible Python 3 open is , it seems like it should be backwards compatible at least as far back as I support ( 3.8 ) but I'm curious if there's anyone who's actually using old versions of Python 3 to test with.

ETA - I love Python. Why *not* just arbitrarily change the position of the buffering parameter between codex.open and open for no apparent reason ? I love having to change every instance of open from positional to keyword to allow for compatibility.

ETA2 - Actually I think point 1 is probably helpful indirectly, that codecs.open and open are identical for my purposes with the keyword arguments does at least imply that it should be compatible as far back as matters for me. Anyway I'll let my test run finish and then upload it to dev and we'll see if I get any reports.
Post edited February 24, 2026 by Kalanyr
avatar
Kalanyr: This may require some more testing than I had anticipated since I'm not sure how far backwards compatible Python 3 open is , it seems like it should be backwards compatible at least as far back as I support ( 3.8 ) but I'm curious if there's anyone who's actually using old versions of Python 3 to test with.
I'm using python 3.11.2.

I wouldn't mind having to upgrade if it makes things simpler for you.
avatar
Kalanyr: This may require some more testing than I had anticipated since I'm not sure how far backwards compatible Python 3 open is , it seems like it should be backwards compatible at least as far back as I support ( 3.8 ) but I'm curious if there's anyone who's actually using old versions of Python 3 to test with.
avatar
mrkgnao: I'm using python 3.11.2.

I wouldn't mind having to upgrade if it makes things simpler for you.
No, I'm quite happy with you not upgrading and I'll tag you when I've uploaded to dev for testing if that's okay with you.
avatar
mrkgnao: I'm using python 3.11.2.

I wouldn't mind having to upgrade if it makes things simpler for you.
avatar
Kalanyr: No, I'm quite happy with you not upgrading and I'll tag you when I've uploaded to dev for testing if that's okay with you.
Of course.
avatar
Kalanyr: No, I'm quite happy with you not upgrading and I'll tag you when I've uploaded to dev for testing if that's okay with you.
avatar
mrkgnao: Of course.
Pushed to dev branch now.

-NEW-

As the reply above says the deprecation warning fix for 3.14 is now on dev branch. I've tested 3.14 and I'm interested in test results for 2.7/ 3.8 / 3.10-3.14 in particular.

( 3.9 isn't really supported since it's EOL and unlike 2.7/3.8 there shouldn't be any hard compatibility reasons to support it, I'll update the version check to mention that next time I do something major )
Post edited February 24, 2026 by Kalanyr
avatar
mrkgnao: Of course.
avatar
Kalanyr: Pushed to dev branch now.

-NEW-

As the reply above says the deprecation warning fix for 3.14 is now on dev branch. I've tested 3.14 and I'm interested in test results for 2.7/ 3.8 / 3.10-3.14 in particular.

( 3.9 isn't really supported since it's EOL and unlike 2.7/3.8 there shouldn't be any hard compatibility reasons to support it, I'll update the version check to mention that next time I do something major )
1) Downloaded the dev branch and merged my local changes (mostly commenting out many of the info prints) into it
2) Replaced my latest manifest with a backup I had from earlier today in order to force an actual update
3) Moved three game directories from my backup HDD in order to force an actual download (of ~13GB)
4) Ran my regular update + clean + download + verify script (on python 3.11.2)
5) Compared the new manifest to the latest one before the gogrepoc update --- no unexpected differences
6) Compared the downloaded game files to the old ones before the gogrepoc update --- identical
7) Checked the screen prints --- everything looked fine
8) The only warnings I saw were the same ones I've been getting for months now in verify (about the non-existent UK version of Realms of the Haunting)

Dev branch version looks ok.

================================================================

Unrelated.

While checking the downloaded files, I happened to notice that the file endings in the !info.txt were 0x0d 0x0d 0x0a (CR-CR-LF), rather than what I would have expected, namely 0x0d 0x0a (CR-LF). It was the same in both the new and old gogrepoc, so it's not a new thing. But, I'm just curious, is that intentional?

================================================================
Post edited February 25, 2026 by mrkgnao
avatar
Kalanyr: Pushed to dev branch now.

-NEW-

As the reply above says the deprecation warning fix for 3.14 is now on dev branch. I've tested 3.14 and I'm interested in test results for 2.7/ 3.8 / 3.10-3.14 in particular.

( 3.9 isn't really supported since it's EOL and unlike 2.7/3.8 there shouldn't be any hard compatibility reasons to support it, I'll update the version check to mention that next time I do something major )
avatar
mrkgnao: 1) Downloaded the dev branch and merged my local changes (mostly commenting out many of the info prints) into it
2) Replaced my latest manifest with a backup I had from earlier today in order to force an actual update
3) Moved three game directories from my backup HDD in order to force an actual download (of ~13GB)
4) Ran my regular update + clean + download + verify script (on python 3.11.2)
5) Compared the new manifest to the latest one before the gogrepoc update --- no unexpected differences
6) Compared the downloaded game files to the old ones before the gogrepoc update --- identical
7) Checked the screen prints --- everything looked fine
8) The only warnings I saw were the same ones I've been getting for months now in verify (about the non-existent UK version of Realms of the Haunting)

Dev branch version looks ok.

================================================================

Unrelated.

While checking the downloaded files, I happened to notice that the file endings in the !info.txt were 0x0d 0x0d 0x0a (CR-CR-LF), rather than what I would have expected, namely 0x0d 0x0a (CR-LF). It was the same in both the new and old gogrepoc, so it's not a new thing. But, I'm just curious, is that intentional?

================================================================
Thank you for the testing.

For the second report: This is a change in the way Python handles universalNewLines , I would have expected it to be consistent but it's not ( the U mode for Python 2 would override the default behaviour of codecs.open to convert new lines on read but doesn't on write , in Python 3 it wouldn't convert at all because codecs.open , opens the files as binary and doesn't override this behaviour by default. This is going be a ride because they've now deprecated codecs.open in favour of open for Python 3 but it open files in text mode by default ( which translates on both read and write by default and neither if you force it into binary mode ). This means this problem originated with the removal of U mode for codecs.open in Python 3.11. I am not sure how to fix this exactly so I'm going to have to think about it a bit.

ETA - There are actually somewhat important underlying differences here. codecs.open *expects* encodings for binary mode ( since it's always in binary mode ) but Python 3s open specifies encodings should only be used for text mode. This does present something of a problem since all the relevant files are actually text files but with utf-8 encoding ( for Python 3 support originally but it's largely the default now even in Windows ).

I think I should probably favour correct output for modern Python 3 in a cross platform fashion and then hit things with sticks until Python 2.7 is at least readable on Linux ( it is probably the case that any instances of Python 2.7 are being used on *nix based NAS setups and so will be in Linux format* )

* There is an argument to be made here that I should actually drop support for this actively because I don't think such NAS setups should be connected to the internet in all likelihood , they are unlikely to be secure barring extremely weird setups that are using LTS releases from 2016-2020 that supported Python 2 until the end but weren't providing Python 3. I suppose I might drop a deprecation warning and see if I get any requests to maintain support for 2.7 / 3.8.

ETA2 - I think I've actually found a fairly elegant way (or at least no worse than any of the other kludge for backwards compatibility ) to handle this.
Post edited February 25, 2026 by Kalanyr
avatar
Kalanyr: Pushed to dev branch now.

-NEW-

As the reply above says the deprecation warning fix for 3.14 is now on dev branch. I've tested 3.14 and I'm interested in test results for 2.7/ 3.8 / 3.10-3.14 in particular.

( 3.9 isn't really supported since it's EOL and unlike 2.7/3.8 there shouldn't be any hard compatibility reasons to support it, I'll update the version check to mention that next time I do something major )
avatar
mrkgnao: 1) Downloaded the dev branch and merged my local changes (mostly commenting out many of the info prints) into it
2) Replaced my latest manifest with a backup I had from earlier today in order to force an actual update
3) Moved three game directories from my backup HDD in order to force an actual download (of ~13GB)
4) Ran my regular update + clean + download + verify script (on python 3.11.2)
5) Compared the new manifest to the latest one before the gogrepoc update --- no unexpected differences
6) Compared the downloaded game files to the old ones before the gogrepoc update --- identical
7) Checked the screen prints --- everything looked fine
8) The only warnings I saw were the same ones I've been getting for months now in verify (about the non-existent UK version of Realms of the Haunting)

Dev branch version looks ok.

================================================================

Unrelated.

While checking the downloaded files, I happened to notice that the file endings in the !info.txt were 0x0d 0x0d 0x0a (CR-CR-LF), rather than what I would have expected, namely 0x0d 0x0a (CR-LF). It was the same in both the new and old gogrepoc, so it's not a new thing. But, I'm just curious, is that intentional?

================================================================
I've now pushed a version to dev that should hopefully fix this now, if you could let me know if it does that would be great.
avatar
Kalanyr: I've now pushed a version to dev that should hopefully fix this now, if you could let me know if it does that would be great.
Indeed it does. Thank you.
avatar
MMLN: Hello Kalanyr,

I have tried to download both ATOM games today, and I got these errors. Can you please check out, what might be the issue for me? Other games I've tried last few weeks seems fine.

(command included)

(also if you need the values from <redacted> fields, I can send them to you by PM)

EDIT: both files have been downloaded though.

gogrepoc.py update -os windows linux -lang en -ids atom_rpg_postapocalyptic_indie_game atom_rpg_trudograd

11:51:52 | loading local manifest...
11:51:53 | loading token...
11:51:53 | loading local resume manifest...
11:51:53 | fetching game product data (page 1)...
11:51:54 | scanning found "atom_rpg_postapocalyptic_indie_game" in product data!
11:51:54 | scanning found "atom_rpg_trudograd" in product data!
11:51:54 | saving resume manifest...
11:51:54 | saved resume manifest
11:51:54 | (1 / 2) fetching game details for atom_rpg_postapocalyptic_indie_game...
11:51:57 | request failed: 404 Client Error: Not Found for url: https: //gog-cdn-fastly.gog.com/token=nva=<redacted>~dirs=6~token=<redacted>/secure/linux_offlines/167336 7037/1673367037/57186263152814002/2281/atom_rpg_post_apocalyptic_indie_game_1_190_70193.sh.xml. will not retry.
11:51:57 | no md5 data found for atom_rpg_post_apocalyptic_indie_game_1_190_70193.sh
11:51:58 | request failed: 403 Client Error: Forbidden for url: https: //cdn.gog.com/secure/linux_offlines/1673367037/1673367037/57186263152814002/2281/atom_rpg_post_apocalyptic_ind ie_game_1_190_70193.sh?<redacted>&fileExtForIe=.exe. will not retry.
11:51:58 | failed to fetch https: //www.gog.com/downlink/atom_rpg_postapocalyptic_indie_game/en3installer0
11:51:58 | Successfully fetched file info from https: //www.gog.com/downloads/atom_rpg_postapocalyptic_indie_game/en3installer0 but no md5 data was available
11:51:59 | request failed: 404 Client Error: Not Found for url: https: //gog-cdn-fastly.gog.com/token=nva=<redacted>~dirs=6~token=<redacted>/secure/linux_offlines/167336 7037/2085203195/57186263152814002/5416/atom_rpg_supporter_pack_1_190_70193.sh.xml. will not retry.
11:51:59 | no md5 data found for atom_rpg_supporter_pack_1_190_70193.sh
11:52:00 | request failed: 403 Client Error: Forbidden for url: https: //cdn.gog.com/secure/linux_offlines/1673367037/2085203195/57186263152814002/5416/atom_rpg_supporter_pack_1_190 _70193.sh?<redacted>&fileExtForIe=.exe. will not retry.
11:52:00 | failed to fetch https: //www.gog.com/downlink/atom_rpg_supporter_pack/en3installer0
11:52:00 | Successfully fetched file info from https: //www.gog.com/downloads/atom_rpg_supporter_pack/en3installer0 but no md5 data was available
11:52:01 | (2 / 2) fetching game details for atom_rpg_trudograd...
11:52:05 | saving manifest...
11:52:06 | saved manifest
11:52:06 | saving resume manifest...
11:52:06 | saved resume manifest
11:52:06 | --
11:52:06 | total time: 0:00:14.518677
11:52:06 | exiting...
avatar
Kalanyr: This is a normal output when GOG fails to provide MD5 information for specific files, this:
Successfully fetched file info from https: //www.gog.com/downloads/atom_rpg_supporter_pack/en3installer0 but no md5 data was available

indicates that the files will be treated the same way as extras are ( ie verified by file size and name only ) .

You get a different error if there's a major problem and file info can't be fetched.
Thank you for clarification. I was just a little bit surprised, as this happened for the first time (at least I have never noticed this before).