It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
As a headsup, GOG has done something bizarre with the Windows Battletech files. I think they've uploaded the 32-bit installers with the 64-bit names, naturally gogrepoc will spit warnings everywhere while it renames stuff to avoid clashes. Not much I can do about this but at least you know until it gets fixed.
avatar
Kalanyr: As a headsup, GOG has done something bizarre with the Windows Battletech files. I think they've uploaded the 32-bit installers with the 64-bit names, naturally gogrepoc will spit warnings everywhere while it renames stuff to avoid clashes. Not much I can do about this but at least you know until it gets fixed.
I think this may have been fixed. One user was reporting seeing two sets of download files with the same names. I've just looked at my downloads and it's only showing one (64 bit) set to download.
Post edited March 04, 2020 by ikrananka
avatar
Kalanyr: As a headsup, GOG has done something bizarre with the Windows Battletech files. I think they've uploaded the 32-bit installers with the 64-bit names, naturally gogrepoc will spit warnings everywhere while it renames stuff to avoid clashes. Not much I can do about this but at least you know until it gets fixed.
avatar
ikrananka: I think this may have been fixed. One user was reporting seeing two sets of download files with the same names. I've just looked at my downloads and it's only showing one (64 bit) set to download.
Yeah, you're correct.
GOG Downloader officially is no longer supported come March 17th, 2020. They will souly support downloading from the website or Galaxy.

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

Since GOGREPO uses html query's its going off the web links and not the gog downloader platform which the linux tools are using right?
avatar
Starkrun: GOG Downloader officially is no longer supported come March 17th, 2020. They will souly support downloading from the website or Galaxy.

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

Since GOGREPO uses html query's its going off the web links and not the gog downloader platform which the linux tools are using right?
It should but something weird may break, if so I'll fix it.
There is now an unstable branch of gogrepoc. This is basically just to help me organize my thoughts with regard to the big changes. There is about a 110% chance it will munge your manifest if you use it, at the wrong time, so this is a fair warning not too. I'll fold stable-ish changes back into Dev.
have gogrepo a bandwith limit? i can only download with 4x2,5mb/s
SOLVED

A year ago, I was able to download my library using GoGRepo. Back then, I had to login into GoG, solve the Captcha, export the cookies and now run the update command. Now, this no longer seems to work. Just running
gogrepo.py update -os windows linux mac -lang en de fr
without doing anything else resulted in the following error:

fetching game product data (page 1)...
failed to load product data (are you still logged in?)

I then deleted my cookies, logged in again and did the stuff described above. Problem: there was no more Captcha. Exporting the cookies did not help. I still get the same error.

Have I missed anything? Is there a new process to follow in the meantime? Could 2 factor auth. be a problem?

Thanks for any help!

EDIT: Never mind, silly me, pulling the latest version of gogrepo has of course helped :)
Post edited March 14, 2020 by spitfire_ch
So as part of the update I'm doing, I'm storing significantly more of the information pulled down from GOG and as part of that I want to also keep to the "names" GOG uses for things as much as possible but this poses some problems:

eg what gogrepo currently calls a title is called a slug (this is the short form used for eg naming game folders) by gog and what is currently a long_title is just a title,

This leads to a bit of a problem when communicating with the user:
When talking to a user of gogrepo and specifying a game would you rather it continue to be referred to as a title or be changed to slug ?

The former is more understandable to a user but it will mismatch what is stored in the manifest if someone looks at it (another thing I'm doing is providing the ability to spit out a pretty human readable manifest).
avatar
Kalanyr: eg what gogrepo currently calls a title is called a slug (this is the short form used for eg naming game folders) by gog and what is currently a long_title is just a title,
Just rename them to title_slug and title_long
:P
avatar
Kalanyr: eg what gogrepo currently calls a title is called a slug (this is the short form used for eg naming game folders) by gog and what is currently a long_title is just a title,
avatar
phaolo: Just rename them to title_slug and title_long
:P
I want to keep the manifest data to a match of what GOG has (or a lossless processed version of the same thing) to avoid any potential shadowing. Anything derived by gogrepo is going to go in it's own gogrepo namespace. So the question is more about what to display to the user than who things are stored on the backend.

I suppose one other possibility is to just refer to it as a game and display the slug,
avatar
Kalanyr: I assume you're looking at a multi-user scenario and also doing something like dividing the manifest up by OS ?
avatar
Gekko_Dekko: I thought about using gogrepo as normal linux package (e.g when script itself is installed system-wide. You cant write to its installation folder as normal user - instead, script's data (manifest, cookie) is saved into $HOME/.local/config/gogrepo, and games get downloaded to $HOME/.local/share/gogrepo).
Do you have a python program that's coded this way, that I can use as a reference ? Preferably one that's cross platform with Mac / Windows.

I think I've worked out the state problems, so redirecting the manifest is possible, so knowing what the standard hooks for this are so I can prep it as a package is a reasonable step now.
Even tough i'm still abit concerned about using a non official tool, manually updating my library is reaching a point where i find it unpleasantly time consuming.
So i did a test with a dummy account and the free games. Everything worked ok, but the download speed for the whole process seemed slower than it should be. I ran the process in cmd directly from the external hdd, does that have an impact, or the script limits download speed somehow?
avatar
darkangelz: Even tough i'm still abit concerned about using a non official tool, manually updating my library is reaching a point where i find it unpleasantly time consuming.
So i did a test with a dummy account and the free games. Everything worked ok, but the download speed for the whole process seemed slower than it should be. I ran the process in cmd directly from the external hdd, does that have an impact, or the script limits download speed somehow?
No limit, i fully saturate my connection, its all based on location.... and currently depending on location in work the powers that run the net are throttling communication due to COVID-19.

But that aside there is no throttle at all, its whatever your pipe can handle.
I supose that's possible, i read that afew days ago our isp's would have to give priority to essential services if required by a big increase in traffic.
I'm also trying to figure out the best solution to another problem of switching to gogrepo: i already have a gog backups folder but that has a different structure and added subfolders for hidden games for example. I checked the import and backup options and they seem to work about the same way, so i was thinking about something like this for the initial process:

- create the manifest
- import or backup my existing files into a new backup folder
- download for uptodate files
- clean to remove older files to the orphaned folder
- verify
- backup to a secondary drive

I'm just not sure wich option would be best to avoid unneeded extra downloads