Yes, even the cleverest of algorithms cannot circumvent the laws of physics which places some hard limits on some of the things we can do with computer systems.

Linux will encounter fragmentation problems if you fill your hard disk to the brink (I recommend doing something when you get above 90% disk usage, which is probably a sound thing to do regardless of fragmentation).

Otherwise, it will manage itself just fine.

See: https://www.howtogeek.com/115229/htg-explains-why-linux-doesnt-need-defragmenting/

My login cookie had apparently become old so I had to "gogrepoc.py login" again to re-create one.
When I tried this a month ago, it would fail with re-captcha:

https://www.gog.com/forum/general/gogrepopy_python_script_for_regularly_backing_up_your_purchased_gog_collection_for_full_offline_e/post2581

Fortunately, now it seemed to work just fine, so not sure what has changed. I now have a fresh new gog-cookies.dat, I didn't hit recatcha or even the two-factor authentication this time. I did log into gog.com with a web browser on the same machine just before trying it, no idea if it mattered.

Glad to hear, I pretty much completely gave up on the tool when I couldn't login (well, ok, I also wanted to integrate support for the s3 protocol and I didn't see myself having a good time refactoring this into the codebase).

I think unless you literally embed GOG's login form in a browser engine you control, an abstracted login feature will be flaky at best.

Btw, its not the most user-friendly/sexiest thing in the world, but in terms of GOG's api (maybe not the galaxy api, but the api used by the browser to access and download games from your shelf which is sufficient), you can login normally on gog and copy only 2 fields from the cookie to make it work: "sessions_gog_com" and "gog-al".

At this point, I can confirm without any doubt that you can make a functioning tool using only these two values.

Interesting. Out of curiosity, how would anyone go about using these values to interact with their GOG library? I thought about making a small info tool previously, but stumbled upon the weird login process and dropped the idea early on.

A small example would be appreciated!

I can provide you with a lot more than a small example :P: https://github.com/Magnitus-/gogcli/tree/main/sdk

That part of the code is dedicated strictly to talking to the gog api.

See step 1 of usage to retrieve the values from your cookie: https://github.com/Magnitus-/gogcli#usage

Also, all the cmd-gog-api... commands are essentially wrappers around simple calls to the gog api (I use it to troubleshoot that this part of the code works correctly): https://github.com/Magnitus-/gogcli/tree/main/cmd

The help documentation does not mention this case, so it's probably not supported, but I thought I should ask...

Could we use the gogrepo.py script (eddie3 repo) to "update" or "download" a specific selection set of games rather than only one at a time or all of them.

Something like:

gogrepo.py verify -id the_technomancer phantasmagoria prey

or even better use wildcards?

You can do it with gogrepoc (kalanyr), but you should use -ids, rather than -id, I believe.
Don't know about gogrepo (eddie3), never used it.

Excellent! Thank you, will take a look when I find some time.

Ok, I'll probably give that a go next time.
Thank you!

If you have Firefox logged into GOG, you can use this script to extract all GOG related cookies (didn't bother finding out which were actually needed) into gog-cookies.dat format.

I tried the excellent program by Magnitus, and alas the gog-cookies.dat file isn't acceptable, so with a little help from Magnitus, I had to manually get them from my browser Inspect page in Brave (Chrome Clone) - Network -> Headers section, from an entry with cookie in the name. Just grabbed the two required entries and saved them to a text file called 'Cookie.txt', then referenced that with his command-line.

So far I have checked out all the available commands, and they work well.

User Info (includes friends list)
List of owned games ... on a page number basis ... I have 12 pages.
Details for one game, using Game ID.
Download a single file using a URL found in the above details.

I am very impressed so far.
I have noticed no MD5 values are listed in Game details, so hope that is on the todo list ... and maybe a Verify option.

For those using Windows, here is my testing BAT file entries, once you get a working cookies file. Just change the first 'goto' target (i.e. FILENAME) for the command you want to use (i.e. DOWNLOAD). And of course adjust where necessary to match your number of game pages and the selected game and game file. EDIT
I just checked a browser download URL in my GOG game library, and if you take 'https://www.gog.com' off the front, it is identical to what is in the game details ... so that is handy.

The tool is still in WIP. Minimally, I have this left to do before I consider it stable:

6. DOING: Implement actions update in storage as manifest upload happens
7. Implement "storage resume-actions" (tentative syntax) command
8. Add "number of games" flag to "storage resume-actions" and "storage apply" commands
9. Implement "manifest generate-patchfile" (tentative syntax) Command
10. Implement "storage apply-patchfile" (tentative syntax) command
11. Add more documentation
12. Write unit tests pipeline
13. Write functional tests pipeline

The actions update is so that you don't have to start from scratch if an error happens (ex: gog returns an error on one of the downloads). It will also enable scenarios like "ok, I have 1000 games in my manifest, but please, only download the next 5 for now".

The patchfile notion is so that you can get a fixed list of new games and updates at a specific point in time and potentially apply it multiple times afterwards (useful for testing as GOG removes new/updated flags from games once you get the detailed view, though there might be other interesting use cases for it, if you have multiple redundant stores for example).

I'll look into supporting that format as well if its easier.

Ultimately, long term, I would like to attempt loading the login form and using something like webview (https://github.com/webview/webview) to inject a bit of js that sends back to the client the credentials that it needs. I'll see how doable it is.

Alternatively, I could also build a separate smaller utility in electron just to handle the login part and generate a file from it.

Either way, I consider handling the login flaky enough that I think the most low tech solution of copying cookie values in a text file should always be supported as a fallback.

Unfortunately, the gog api doesn't seem to provide checksums so checksums are not available when the manifest is initially generated.

Checksums are computed and the manifest is updated with them when you download files into the storage (ie, "gogcli storage apply"). There isn't much additional overhead there as I leverage the same download stream both to compute the checksum and to store the file when using the filesystem and for s3 stores, you get the md5 checksum "for free".

There is a commmand to verify that the checkum of files match the manifest once the files are into storage (ie, "gogcli storage verify"). This handles validating that the stored files are valid relative to the download stream you initially got from GOG.

I'll probably add another command to verify that the checksums in a manifest file match what is downloaded in the gog api (something like "gogcli manifest verify") although that will involve having to redownload the files for the sole purpose of validating the checksum (and so will be expensive). That will validate that something didn't go wrong in transit from GOG's website (a much rarer, but not impossible occurence).

There is also a "gogcli gog-api download-url-path" command that takes the relative url and downloads the file (I used it for troubleshooting file download, although I imagine that someone who likes scripting might do something with that on top of the client).

AFAIK, lgogdownloader has something like this.

If I had the time, I would expand my fork of gogrepo to scan the home directory for Firefox, Chrome and Edge, and extract the relevant GOG cookies from there.
It should be fairly trivial but, as the current state of it works well enough for me as is, I can't really be ar*ed. :-)

Mmmm I'm not so sure about that, as my gogrepo.py manifest lists them all.


I don't really understand what you mean by that, as I haven't downloaded the majority of my games with gogrepo.py, but the manifest file contains MD5 values and file size values for the greater majority of my games ... they were present when the manifest was initially generated.


I did see and note that.

----------------------------------------

By the way, I just successfully got the first gog-al entry from my gog-cookies.dat file and used that in my 'cookie.txt' file with your program. There is no session value, so I also tried without that in my 'cookie.txt' file and it appears your program doesn't need it.

Indeed, I saw (from reading the doc). That emboldened me that it might actually work.

Well, if it works cross-browser (at least among the major ones), then that would indeed be a very interesting more lightweight alternative.

Interesting. I couldn't find anything about it in the unofficial api documentation (there were some promising leads, but they turned out to be dead ends for me).

Superficially, I didn't find anything in the code of gogrepo.py either (I did look at it to compare gog api usages and the projects seems to be using the same endpoints I am which are the endpoints used by the browser when you navigate your game catalog on GOG btw), but I won't claim to be a master of that codebase. I'll give it another look. I might have missed something.

Interesting, I'll try it.

You are right though, the program will return an error if you use anything, but those two entries, but it will not validate that BOTH entries were present (an oversight on my part, but an happy one it seems):

https://github.com/Magnitus-/gogcli/blob/main/sdk/sdk.go#L30

Edit: Actually, it won't return an error if another cookie field is used, it will simply ignore it. That was truly atrocious validation on my part there. I'll fix that so that the user gets some error warning at least when he enters cookie fields that are not supported.