If you search for


HTTP_RETRY_COUNT

You should find the appropriate constant

I'd only recommend bumping it to 4 though ( or 5 if somehow have more than 10000 owner games ).

Thank you.

Using the OG gogrepo script (i've had the most success with geting it working....) to try to even update to then download what i've bought (windows/linux releases) ... For some reason the linux terminal windows I'm using (seperate folders one for windows, one for linux) freeze at the most random points. Sometimes one will freeze at 'updating' 89, than other times at like 150. Anything to do with using an external HDD?

I saw that a few times though ususally I use an enclosure rather than a standalone usb disk

I've tried USB stick, external ssd, external hard drive, all the same result. I just want to download the bloody files while I can. Doubt it'd make any difference, but the commands I run (from within the respective folder):

python3 ./gogrepo.py update -os windows -lang en bl ru gk sb ar br jp ko fr cn cz hu pt tr sk nl ro es pl it de da sv fi no
python3 ./gogrepo.py update -os linux -lang en bl ru gk sb ar br jp ko fr cn cz hu pt tr sk nl ro es pl it de da sv fi no

Tried both -lang and without.

You should use gogrepoc: https://github.com/Kalanyr/gogrepoc/tree/master

When people talk about gogrepo nowadays, they mean gogrepoc. The original gogrepo has been abandoned long ago.

I would suspect something wrong with the USB, like your USB drive being sometimes disconnected or something.

Since update merely updates or creates the manifest text file, try to create it on your local hard drive, not the USB drive. Does the problem happen there too?

In fact, if you want, you could set up gogrepoc so that the manifest file and the partially downloaded files are on your local (internal) hard drive, and only the fully downloaded files are then moved to the USB hard drive. Then the external USB drive would be accessed only when a file has been fully downloaded.

The only drawback of this is that there will be a little pause whenever it moves a downloaded file to the external drive (depending how slow that USB drive is), but at least it would not require you to have constant uninterrupted access to it, in case there is something weird with that.

Whenever I run verify I get the following errors:
00:35:46 | no known filename for "jagged_alliance_2_wildfire (Jagged Alliance 2: Wildfire)"
00:35:46 | no known filename for "republique (Manual (coming soon) )"
00:35:46 | no known filename for "warhammer_skulls_2022_digital_goodie_pack_goodies (Warhammer Chaos Gate)"
00:35:46 | no known filename for "wasteland_2_directors_cut (Wasteland Avellone Novel (coming soon))"

These are expected, as these items do not exist, have never existed, and will never exist. Is there a way for me to tell gogrepoc not to check these, short of editing the code? Skipfiles does not seem to work, as these items do not have a file name.

I don't think there's anyway to meaningfully "skip" them programatically apart from hard coding skipping those links, I could throw in an option to suppress that error if you want ? It fails so early that there's no real different from checking and skipping anyway.

I don't want to suppress the error completely, for if a new one appears, I do want to know about it. I want to be able to suppress it only for the ones I already know about.

I thought about something along the lines of "SkipManualUrl", which allows to skip based on manual URL, rather than file name.

But I'm not sure it's worth the trouble if I'm the only one interested. As you said, I can hard code it myself for the URLs affecting me.

Even though I use "-os windows" parameter when updating the manifest, for Stardew Valley, after recent version update, the script also downloaded a .pkg file, which seems to be a Mac version of the installer.

I guess that may be a wrong flag on GOG's side of things, and nothing you can do anything about?

(If anyone else had this happen to them: an easy workaround is adding "-skipfiles *.pkg" to a download command.)

The reason is that GOG has put an older 32-bit Mac version under extras, also with the Windows version. That's why it gets downloaded, quite correctly. The main Mac version is a newer version, I presume 64-bit version.

That's the case with some other games as well where GOG has, for a reason or another, put e.g. non-English versions under Extras (in which case they get downloaded even if you select to download only the English version), or also some Mac and Linux versions under Extras.

E,g, the original Planescape: Torment has fan-made Russian translations of Windows, Mac and Linux versions in the Extras, and Broken Sword: Director's Cut has the Mac and Linux versions of the original Broken Sword under Extras.

I recall at least earlier the idea for GOG was that they'd put unofficial/unsupported versions of games under Extras, like the aforementioned fan-translated Russian versions of Planescape: Torment. I guess the original Broken Sword isn't officially supported either due to the Director's Cut.

So I recently updated my gog backup with some pretty big games (Cyberpunk etc) and now I ran the verify command on the new games.

It reported 9 MD5 mismatches. What do I do with that information? I can't find any information which files exactly where mismatched, so the entire thing seems completely useless.

Can anyone help me?

EDIT: Ok I found some of it in the log.
This script desperetaly needs a function to summarize things at the end, going trough the entire log is incredibly ineffective and sometimes impossible because it cuts of at a certain point in my command line window when there is too much stuff.

So in the end, instead of just telling you about the numer and type of erros, it should list exactly what files were affected.

The log can be read and searched in its file, even after the window has been closed.

The latest log is gogrepo.log and if it does not contain the entire run you are interested in, the previous one is gogrepo.log.1 and the one before is gogrepo.log.2, etc.

Thank you, i didnt know that. That's very helpful! I was able to identify the problematic files this way (there was some wierd update for Wolfenstein New Order recently, I pulled all the install files manually from gog and the verification worked this time).

A small summary would still be nice at the end of each verfication, but with the full logs in text format it works ok.