Thanks for the code snippet that yields a clear reproducible methodology. I'll give it a try in my tool.

However, out of curiosity: Why not do a couple of retries with the modulo on the number of milliseconds since epoch, which would avoid having to wait a minute?

I opted for a solution that would require as few code changes as possible, so it could be easily communicated here. Retries would have required changes in multiple places, I believe.

EDIT: Plus, retries hide issues. I prefer to see a failure when something fails. I have similarly disabled most of gogrepoc's existing retries in my copy.

Fair enough.

Well, there are different ways about this.

When I operate with a clear purpose other than troubleshooting a tool, I prefer when it is as resilient as possible and assuming that there are no undesirable side-effects, get me from point A to point B by whatever means necessary without the need for interventions.

If I want to troubleshoot the tool itself, well, this is where modular design comes in handy. If I take gogcli for example, I can just run the gog-api command to get a file info on a problematic file and set retries to 0 if I really want to try this with great granularity (although I do think in most cases, given retries will be enabled when I normally operate the tool, it makes sense to troubleshoot with retries on... with clear logging, ideally changeable to different levels of details, giving proper traceability on what happened on each retry).

Yours is indeed the sensible approach. You have probably gathered by now that, generally speaking, mine rarely are.

I know I've been told in past places I've worked at that I often go too much for the "dream" solution from the start, which admittedly can be a drawback when there is a need for very quick prototyping to validate uncertain assumptions though I'm getting much better at it as I grow older, but creating ephemeral/throwaway code will never be my prime focus which is part of the reason I strongly prefer to work with solid dependencies (which I then proceed to learn a great deal about to avoid surprises) so that I can be pretty certain of the underlying assumptions that I make and avoid backtracking too much.

So I know there are situations where your approach is superior (as creating highly modular/troubleshootable code takes consideration and time). It takes all kinds.

I've had this argument a billion times now. The only other store that sells DRM-Free game is Zoom. Steam and Epic do not count. Why? because they do not offer offline installers. The best you can hope for is that the game is "portable enough" to be backed up and carried around in an "installed state" and that any dependency setups are stored within the install dir.

DRM-Free games on Steam and Epic are worthless without offline installers. Period.

No they are not worthless, they just take more work and time and aren't guaranteed ... and as you say might need an outside dependency. If they are good to go though, then you are cooking with gas. They are certainly not worthless if GOG don't provide the game at all.

If they have been tested properly and you zip up the install folder making it self-extracting (i.e. with 7-Zip), then you get pretty close to an Offline Installer. In fact, the way GOG now do their installers, you may even have a better installer.

The only other issue is if you need to update or install DLCs, either of which could undo the DRM-Free state, though your created installer version will be fine ... despite any bugs needing an update.

I personally refer to such games from Epic and Steam as DRM-Free Lite ... to indicate the differences, which may or may not be significant.

Well I have that issue when using this command

"gogrepoc.py update -os windows linux -lang en -full"

and it is happening to all of my games, not only to AoW :(

11:56:55 | ( 18 / 258) fetching game details for beneath_a_steel_sky...
11:56:55 | The handled exception was:
11:56:55 | error
Traceback (most recent call last):
File "D:\Backup\GOG\gogrepoc.py", line 1379, in cmd_update
item_json_data = response.json()
File "C:\Program Files\Python39\lib\site-packages\requests\models.py", line 900, in json
return complexjson.loads(self.text, **kwargs)
File "C:\Program Files\Python39\lib\json\__init__.py", line 346, in loads
return _default_decoder.decode(s)
File "C:\Program Files\Python39\lib\json\decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "C:\Program Files\Python39\lib\json\decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
11:56:55 | End exception report.

EDIT: OK disregard it I have found the issue. The stored cookie from my last session has become for some reason invalid. Running the "gogrepoc.py login" command again solved my issue, and it now updates correctly...

EDIT2: If Kalanyr reads it, maybe there would be nice to have some error message explaining that a person needs to login again, if this error message pops up all around your screen, to be less confusing, for the noob users, like myself :)

And another point is that they don't officially support their games DRM-free. So if you have issues trying to run them offline without a client, don't expect them to do anything about that.

If I recall right, many of the allegedly DRM-free Epic games don't e.g. save the game progress, unless you use the client with them (in which case they are not DRM-free anymore). Some update to those games apparently caused that, making them less DRM-free and more dependent on the online client.

There should already be detection for if you're logged out which notifies you that you need to log in again but I guess GOG has changed something that's broken it. I'll look into it at some point but I don't think it's a super high priority and I'm working on something else eight now.

I had lots of issues downloading Imperator Rome (both with the browser and gogrepo), I wonder what happened there. I finally managed to grab the .bin file via the browser but after countless retries.

Ok so I gave gogrepoc by Kalanyr a try and it seems to work a bit better than gogrepo by eddie3.

Unfortunately I can't quite understand some of the syntax. IMO the ReadMe file is not good enough.

Can someone clarify the following:
1) How to specify the end of the "-lang" parameter. At the moment it seems to interpret every subsequent parameter as a language and then, naturally, fails. As a workaround I have to place the "-lang" parameter at the end. Are there any brackets or anything I can use?

2) How to use the "savedir" parameter. No matter whether I use quotation marks or not, whether they are single or double, it just fails. What is the proper syntax for the "savedir" parameter using a Windows path WITH spaces.

Every good Readme file should include examples for every command. Examples can often convey the information far better than any explanation.

In my experience, unless a project achieves a high usage status, documentation is the achilles' heel of a lot of projects.

Programmers will spend countless hours toiling away on the code, but when comes time to spend a fraction of that time to highlight the fruits of that labor, they won't do it.

Looking at gogreoc's documentation, it is ahead of the curve. You might find it lacking in some regards (most documentations that have not been battle-tested with a lot of user feedback is), but I wish most devs documented the usage of their project at least to that extent.

That's probably universally true, but understandable. Writing good documentation is a lot of work and takes a lot of time (that may still be only a fraction of the time it took to implement the thingy, but only because the implementation requires a lot of time). It is very hard if you are extremely familiar with how anything works – you have to view the program from a different perspective. And on top of that: writing code and writing (non-technical) documentation are disjunct skill sets.