Yes, I tried using gogrepoc earlier this year and gave up on it. The login command wasn't working and the way to plugin your cookie values directly required extra tooling. I think the tool would benefit from a way to pass your cookie values directly as an alternate way of doing it.

Yes, I think Linux users are better served using this one. I would be if I wasn't extremely specific in what I wanted.

Indeed.

Should be able to run that tool from a virtual machine. Linux is great for things like that. I just don't like gaming on it.

I tried it once (that was a couple of years ago though), and it felt quite good like it showed the estimated remaining time for the download and such (wouldn't be that hard to add that same to gogrepo as well), but:

- it was apparently Linux-only, unless you compile it yourself to e.g. Windows. What I like about gogrepo is that is works on pretty much any device that can run python scripts. I use it e.g. on my Raspberry Pi4.

- If I understood right, that tool depends on the new and changed tags to see which files need to be downloaded?

gogrepo, on the other hand, can detect any changed or new files that need to be downloaded, regardless if GOG has provided the tags. I presume that is why it can take such a long time for gogrepo to check which files it needs to download, compared to lgogdownloader.

I might be wrong on that one, but that's the impression I got when I used it. Then you might miss many updated files, just because GOG didn't mark them as such.

It has the option to only work on flagged files (--updated option) but by default it will try to download everything and
1. skips already downloaded files (not changed/updated)
2. downloads new files (new version or missing file)
3. renames old version and downloads new version ("silent" updates, meaning that the file has been updated but file name hasn't changed and possibly no update flag)

So it won't miss those files that don't have update flags.
It can also use Galaxy repositories to install and update games if one wants to use that feature.

For Windows users gogrepo is probably the best choice unless one wants to try compiling lgogdownloader for Windows.
At one point I was going to compile for Windows but at the time there were issues with MinGW handling some C++11 features on Windows so I dropped that idea.
It should be possible to compile lgogdownloader for Windows nowadays with mingw but I'm not sure if lgogdownloader requires some #ifdefs or changes to handle Windows specific things.
I guess that WSL would be the easiest way to use lgogdownloader on Windows.

Thanks. I'll report that today.

Seems like the Garou Mark of the Wolves unofficial linux build (provided as an extra) is also missing.

Yes, that and another game:
https://www.gog.com/forum/general/snk_seems_to_be_silently_pulling_linux_version_from_some_of_their_games

I flagged it some time ago. I think they are looking into it.

Ok thanks for setting the record straight. It is good there are options.

As a headsup Imperator:Rome is currently borked on GOGs end for Windows. Installer 2 of 2 is missing (404) so the game can't be installed, as far as I can see if you had already downloaded RC2 before it went walkabout it will be fine, but you'll have to manage it manually.

Umm.. all my new downloads got stuck in the "!downloading" directory.
How did this happen? Also, is there a way to fix this automatically (with a gogrepo command) instead of manually?

I only noticed this because I needed to retry "divinity_original_sin_2" which gave a "503 Server Error: Service Unavailable" error..

EDIT: oh great, all those files (120Gb!) seem corrupted.. WTF happened?
The log doesn't report problems for them..
Can I at least recover the huge bin files?

Btw a new download command would just wipe the "!downloading" folder..

Anything in the !downloading folder will recover automatically if the next -download command doesn't filter it out (so just using the generic full spectrum download is fine for most people, though you might have to add -os / -lang specs if you're doing custom stuff) if it's salvageable. If it's getting wiped it's possible you had errors on your last -update and need to fix that, you can either use -ids just to fix the titles you've got stuff in !downloading for or do a full update.

Ah thank you, I'll try it.
Btw, it feels like the DOS2 errors somehow interrupted all the other file transfers?

I'm using version 0.4.0-a (old dev before it became stable), is there a newer stable one?
(I'm not sure on Github, I only see Testy Mctest lol)

EDIT: I'm redownloading all the files broken after DOS2.
I'm using the ids parameter, because Gog still has some problems: error "502 Bad Gateway" on other files now..

Master should be up to date (and I think slightly newer than old dev, I believe I pushed a slightly tweaked local copy before I synced) and dev should be the same while unstable should swiss cheese your manifest.

Yeah, I've noticed some errors with GOG , my second to last update got 503d on some stuff which broke parts of my manifest, and I had a couple of 502s on the last one, I think GOG is having some server issues. There's also a handful of missing files scattered across my collection (of which the Imperator Rome installers being missing is by far the most significant)

I've reported the problem, and the issues seem solved for now.
Also, I've updated my local gogrepo.
Btw, if I interrupt the "verify" process, will it resume from the point it reached or from the start?

EDIT: oh well it finished. It took 4.5 hours, oof..
Averaging items/time I get 5mins per file. Isn't it kinda slow for md5, even for the biggest 4gb ones?
No errors btw, at least

On the latest build the default behaviour for -verify is that a file is marked as verified in the manifest and will be skipped for subsequent checks unless the md5 and/or size changes (or the name changes and no md5 data is available to verify that it's the same file), this happens at verification time.

Python's md5 implementation actually seems to be worse with large files (small files verify extremely quickly but there's fixed overhead), I suspect the default memory management is pretty questionable (it gets really bad with the extremely large Linux files which can be ~20-30 GB). It's also very sensitive to fragementation since it has to read the entire file sequentially for every file verified. I could use the md5 chunk data to do threaded verification where that's available but that has it's own problems (the md5 chunk data and md5 for the full file sometimes disagree due to GOG whoopsies).

Ah great. But I wonder if stopping the script could break the manifest if it happens at the wrong time.

Mm, I see.
Btw at least gogrepo's downloaded files are preallocated without fragmentation, no?