I still get those error messages with the -installers standalone and -skipgalaxy flags. I just have gotten to the point I ignore them.

I intend to turn checking for galaxy stuff off by default in the new build (maybe completely). Which ones still have active versions is completely random, and I suspect anyone who wanted to archive them long since has. I've also added downloading for the new Galaxy Stubs if someome wants them for some bizarre reason.

Valve has said in the past they would release the files to the public so people could continue to enjoy their games from Steam. Not sure if that still holds up today. Also Steam works just fine when it's offline, you just can't interact with the community features or the store when it's down. The games work just fine offline. The only time they've stopped working (for me) was being offline for too long, we're talking being offline for a year though.

same here

Fedora 29.... I am also receiving errors that just started...

22:09:11 | request failed: HTTP Error 403: Forbidden. will not retry.
22:09:11 | fatal...
Traceback (most recent call last):
File "./gogrepo.py", line 1167, in <module>
main(process_argv(sys.argv))
File "./gogrepo.py", line 1142, in main
cmd_update(args.os, args.lang, args.skipknown, args.updateonly, args.id)
File "./gogrepo.py", line 627, in cmd_update
'page': str(i)}, delay=0) as data_request:
File "./gogrepo.py", line 170, in request
page = opener.open(req)
File "/usr/lib64/python3.7/urllib/request.py", line 531, in open
response = meth(req, response)
File "/usr/lib64/python3.7/urllib/request.py", line 641, in http_response
'http', request, response, code, msg, hdrs)
File "/usr/lib64/python3.7/urllib/request.py", line 569, in error
return self._call_chain(*args)
File "/usr/lib64/python3.7/urllib/request.py", line 503, in _call_chain
result = func(*args)
File "/usr/lib64/python3.7/urllib/request.py", line 649, in http_error_default
raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 403: Forbidden
22:09:11 | loading local manifest...

At the moment both scripts (eddie and Kalanyr) don't work....

I have been doing direct downloads by -id and have not been having a problem, other then the script can't resume from what it levet off.

The main reason I do it by ID is that my net connection is horrid. I have a 3mb line and that is it.

Example:

python gogrepoc.py download -id bioshock_2_remastered_game
python gogrepoc.py download -id bioshock_remastered_game

Even with -installers standalone I still get these error messages during an update. Looking forward to the build that eliminates these Galaxy issues.

Earlier I said that the script didn't seem to have the ability to resume, I am happy to say that I was wrong. Just ran the script after the program got canceled, (gotta love windows) and the downloade picked up where it had left off.

YEAH!!!

Yeah, everything worked on my test of the current build that's up. So I'm kind of confused.

I'm going to finish up the rewrite over Christmas if I can.

Right now I am running an update with Kalanyr's latest main build (file date August 2018).
Python 3.7

I expected a ton of script error messages, but it is working fine....

An info for those who notice(d) a very slow download speed:
I had the same issue some months ago. I switched to an older version of kalanyr's script which worked flawlessly as a temporary workaround. Until I noticed that the newer versions suddenly ran faster again. I didn't change anything on my end, so I don't know what might have caused this issue...

And people wonder why the site is behaving strangely. You do understand that in effect you are performing a ''DDOS'' of the GOG servers with this script, you do understand that, right?

How ignorant and lazy can you people be?

The more people use this, the worse it is going to get. Do you want GOG to add a verification check before every game download or even a verification check for every time we access our game libraries? Cus this is what will happen if you continue with this stupidity.

The site is behaving strangely because the site *always* behaves strangely during the time its under heavy load (during the various sales, Cyber Monday and Christmas). Like you can have a look through this thread for when people are having problems to verify that if you like.

No, they aren't. A single user of this script is by definition not performing a Distributed Denial of Service Attack. Could enough people using it at the same time effectively perfom a DDOS ? Yes. But you could do that by using the web site too (and there's well known internet tools that would be far more effective at it^). And I do my best to organize things to minimize problems (only checking for changed stuff by default, recommending only doing full updates monthly, trying to automate adherence to any limits GOG puts on the site* etc).

This script acts like a person going through the website and downloading their stuff manually. Except it automates it. It does what the old GOG Downloader did.

It gets about 40 unique visitors a month (of whom at least 1 is me) and since that number is pretty consistent it's mainly people looking for updates (it's upticked by about 10 since I started tracking it , halfway throught the year).

This script also has a clearly identified user agent so GOG could block it if they wanted. And this script is on their forums and I've contacted their support with issues found due to my maintenace of this script. They could certainly reach out to me if they want me to implement limits or talk about adding proper requrest limits to their header which I will automate the script following.

^ At it's most aggressive this script is about 1/2 the lowest setting of a DOS tool and again has a unique and easily blocked User Agent ID. I recommend being in that state for less than 6 hours per month (which would require you to own every GOG game) and about 1/4 of the time during that interaction is in that mode, the other 3 quarters are much lower intensity downloads.

*Which is hard because GOG sometimes uses the wrong HTTP response codes and doesn't specify request limits in the standard header form).

I would add to Kalanyr's response that GOG have recently created additional load on the system themselves due to the large number of installers that they keep creating internal updates for, i.e. updates that change the installer but not the game. In a single month this year my list of games that had been updated reached 100 with the vast majority of those updates being associated with GOG internal installer changes. Based on your comments apparently I'm lazy not wanting to download each one of these manually!!!

There is little difference to GOG if I automatically download these updates, which are done sequentially, and me doing the downloads manually using a browser where I can also download multiple games at a time and also set them off sequentially.

Your argument and its impact on GOG is nonsense and misinformed.

Thanks. I finally shifted to Kalanyr's version and everything working fine.
Python 3.7.1