Someone with more knowledge than me will likely reply soon, but meanwhile here are some of my thoughts.

Pretty sure I was told that Galaxy variants are no longer downloadable with gogrepo.py, so -skipgalaxy etc does nothing.

Did you fully update your manifest before initiating downloads?

Is that folder syntax correct tho?
For example I use this:
gogrepoc.py download "Z:\Gog games" -os windows -lang en -skipextras -skipgalaxy -skipfiles patch_* setup_*_32_* setup_*_(32bit)*

(btw, you shouldn't run gogrepoc during a big sale, since it could affect Gog's servers too much)

The syntax is correct (verify, for exemple, does see the downloaded content correctly)

But your point about the timing (during a huge sale) is a good one: maybe Gog did something to not allow some games to be downloaded that way: I will wait a few days and try again to get a correct manifest file (instead of the current one missing several games content)

Sorry, don't work:

18:02:12 | fatal...
Traceback (most recent call last):
File "gogrepoc.py", line 2777, in <module>
wakelock.take_wakelock()
File "gogrepoc.py", line 2685, in take_wakelock
self._PMerrcode, self._PMassertID = self._IOPMAssertionCreateWithName(a,self._kIOPMAssertionLevelOn,"gogrepoc")
File "gogrepoc.py", line 2643, in _IOPMAssertionCreateWithName
p_assert_name = self.raw_ptr(self._CFSTR(assert_name))
File "gogrepoc.py", line 2636, in _CFSTR
return CoreFoundation.CFStringCreateWithCString(None, py_string, CoreFoundation.kCFStringEncodingASCII)
ValueError: Expecting byte string of length 1, got a 'str'

If that was the case, I would expect other gogrepo users to report from the same issue as you.

If you are 100% sure your command syntax is ok, all I can think of:

1. Make sure you are using the latest version of the gogrepo(c).py (the Kalanyr version), and not the same you used one year ago.

2. Rename or move your one-year-old manifest file, and start from a scratch with a new manifest file (unless you tried this already).

EDIT: Of course, unless the problem is that for a reason or another, lots of offline installers are currently unavailable (not only to gogrepo users, but all GOG users):

https://www.gog.com/forum/general/gogteam_please_read_and_reply/page1

That would certainly affect gogrepo as well... So for some of those affected games, you could naturally check whether you can download them manually either, with your web browser.

There are other games with that problem. Including: Republique, Grave Keeper and Dying Light.

I've noticed all of the following codes: https://github.com/Magnitus-/gogcli/blob/main/sdk/download.go#L142

So: 404, 403, 301

The sanest way for a tool to handle this is to ignore those errors, but report them to the user on a separate channel (ex: a file).

I've given the output of that file several times to GOG staff on the forums hoping they'd fix the dangling download links, but they haven't so the will to address that problem is low.

Mmmm I have been keeping up-to-date with Dying Light, and haven't noticed that.

Is that just effecting the larger BIN file downloads? Because I have probably been using the browser link for them and Free Donwload Manager 5, rather than your gogcli.exe ... though I have still been using that for the smaller files (DLC etc).

And by the way, download speeds have been much better for me in the last month or so. I sometimes even use your program for files bigger than 1.5 Gb, with good result, though generally not as fast as if I had used FDM5.

Maybe GOG got sick of my complaints, and improved the situation.

but where to store that.. quite big data

I'm glad to hear. It would have been an interesting challenge, but there will be others (including planning how to do an affordable offsite backup taking into account download costs).

Otherwise for Dying Light, I'll check again next time, but I think it still holds. I think at this point, it has some listing entries that are not downloadable links.

I have 8TB-9TB game collection. You can affordably store it in a redundant pair of hard disks (even 10TB size disks are relatively affordable nowadays), but that won't protect you against theft or a fire.

I calculated that I could maintain an offsite backup with Backblaze for about 40$/month and AWS Glacier for about 8$/month, but while storage costs are affordable for those solutions, download costs can be prohibitive (and in the case of Glacier, download is downright limited) so for my solution I might have to rethink how checksums are checked (I'll have to recheck my code, but if memory serves, it just recomputes the checksum of the downloaded artifact to make double-sure).

I think aws glacier gives a md5 checksum on uploaded parts (but not the entire file) and backblaze includes a facility to verify checksum post-upload, but it does it in sha1, not md5 (which is what gog provides) so a translation layer would have to be implemented for this.

Otherwise for gogrepo.py, it doesn't have a plugable storage engine I believe, but you might be able to do a separate transfer from your disk to the cloud.

Magnitus>

look at first two. im lazy to understand too much english so i dont know what means "to be their customer" (if free as well) https://www.1mtb.com/how-to-get-50-tb-free-cloud-storage-get-huge-gbs-of-free-cloud-storage/
but otherwise i find peculiar to buy games as no rentalware like in steam but once for good and then to pay regular fee for stroring instead :\

The universe tends toward entropy. Resisting entropy always incurs a cost. If you are not shouldering that cost, someone else is.

Atm, GOG is "maintaining your collection" free of charge. Some people are ok with this. It rubs me the wrong way, because it depends on them continuously selling games. If that stopped or slowed down significantly, they'd be in the red maintaining your sizeable game collection for you (storage is not so bad because it is shared between all users... although reading throughput must be a pain, but I'm sure continuous bandwidth costs, plus the cost of operating the whole shabang adds up).

If someone charges me a recurring fee for something that continuously needs to be maintained, it seems fair and more maintainable to me.

Otherwise, my downloading my games locally has a maintenance cost too btw. I need to continuously replace failing hard-drives and monitor my redundant copies of my games (you have redundant copies right?) to ensure the data is intact.

Ahh yes, there's a patch submitted for this on the repo (the Mac Wakelock code was only tested on Python 2), that I was hoping to put off until the next release. I guess I should do a hotfix for this then.
This sounds like your manifest doesn't have the installer files at all.

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

Should effectively build a new manifest with everything in it. IIRC the default behaviour for update if -os and -lang isn't specified is to try for your OS (but the detection seems kinda dodgy on anything by Windows) + your system language, defaulting to English. And new updates can clobber old ones.

(it's possible fr is the wrong abbreviation for french , since gogrepo uses the GOG codes which aren't standard but I think fr is correct).

Download should try and grab everything in the manifest by default IIRC (sorry, I'm away so don't have my files to check) but you can force it with:

gogrepoc.py download "D:\TargetDir" -os windows linux -lang en fr

Should download to whatever path you specify in "D:\TargetDir"

If you're comfortable doing so I'd open up the manifest file and see if it actually has any executable files listed. It's possible the handful you are seeing are actually the handful of unsupported special installers that GOG provides as extras.

This script looks very useful, but I have some questions.
Does the script check the free space on the drive?
Does the script support automatically storing games on multiple specified drives / directories?

You see my issue is that I have LOADS of games and many of them are quite new and thus massive. I'm worried that I quite possibly have more games than storage. Even if I bought some additional hard drives, no single hard drive would be large enough to store all this data.

Is there no choice but to start looking at RAID to create a single volume from multiple drives?

I've thus far been avoiding RAID, as I'm worried that if the NAS, its OS or config ever gets botched, I may lose all of the data on that RAID.

From my experience, no, it doesn't. (at least once it started downloading 9 GB worth of files when my external hard drive had only 2~3 GB of free space)

Edit: forgot a small detail and adding the explanation below.

About saving in specific directories, the argument savedir mentioned in the GitHub page should let you download the files to specific folders.