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

×
avatar
Sude: --galaxy-install is now multithreaded and --galaxy-show-builds supports generation 1 builds
--galaxy-install still doesn't have support for generation 1 builds and I'm not sure if I'm going to add support for those because GOG said they plan on making everything generation 2 at some point.

e9ac6d0 Galaxy: Make --galaxy-install multithreaded
40cbb5f Galaxy: Show generation in --galaxy-show-builds output
553c6dc Galaxy: Add support for generation 1 builds to --galaxy-show-builds
Would it have any use in rolling back to earlier releases? (I've never used Galaxy, so I don't know what their retention policy is on old versions.)
avatar
ssokolow: Would it have any use in rolling back to earlier releases? (I've never used Galaxy, so I don't know what their retention policy is on old versions.)
Only if there is a gen 1 build of older version available.
The number of available builds depends on the game.

For some games the builds are removed pretty much as soon as new version is available.
For example Gwent only has one build available most of the time. Just after a new update or when PTR is online there can be 2 or 3 builds available.
lgogdownloader --galaxy-show-builds 1971477531
0: Version 0.9.20.6.390 Public Beta - 2018-02-07T16:31:15+0000 (Gen 2)

Some games have quite a few available builds for different versions. For example Divinity Original Sin 2
lgogdownloader --galaxy-show-builds 1584823040
0: Version 3.0.171.819 - 2018-02-08T14:25:11+0000 (Gen 2)
1: Version 3.0.169.700 - 2018-02-02T18:27:06+0000 (Gen 2)
2: Version 3.0.168.526 - 2018-01-31T23:14:20+0000 (Gen 2)
3: Version 3.0.165.009 - 2018-01-17T15:38:10+0000 (Gen 2)
4: Version 3.0.160.028 - 2017-12-12T13:53:27+0000 (Gen 2)

For older games like The Witcher Enhanced Edition there is a gen 1 build available. However I'm not sure if the gen 1 build is any different from the newer gen 2 builds. And I think that the only difference between 1.5 and 1.5(A) is cloud save support for Galaxy.
lgogdownloader --galaxy-show-builds 1207658924
0: Version 1.5 (A) - 2017-03-22T08:59:43+0000 (Gen 2)
1: Version 1.5 - 2017-01-23T14:08:45+0000 (Gen 2)
2: Version - 2015-01-02T09:55:57+0000 (Gen 1)

And then there are old games like The Longest Journey that only have gen 1 build available at the moment.
lgogdownloader --galaxy-show-builds 1207658794
0: Version - 2015-01-02T19:33:52+0000 (Gen 1)
When GOG finally decides to update it to gen 2 I don't think there is going to be any difference between the gen 1 and 2 build other than the build type.
Post edited February 12, 2018 by Sude
First of all, thanks Sude for putting this together.

Is there a way to not download Windows related executables for extras, etc. when setting "platform=l,w"? The latter switch has the desired effect of prioritizing downloading Linux instead of Windows builds, but it also seems to download extras, patches, etc. that exist for Windows, but not Linux .

For example, the script correctly downloads the Linux version of Kerbal Space Program, but it also downloads all the patches for the Windows version (that don't exist for the Linux version).

I suppose LGOGdownloader is just doing as instructed, but I'm wondering if there's a way to change this behaviour without having to resort to blacklists for each affected game.

Cheers, and keep up the good work. I hope GOG sends some freebies your way!

PS- I'm using the "l,w" switch because I have two Windows-only games (boo! hiss!) that I'd like to archive.

PPS-These were freebies, so I couldn't specify a Linux platform.
Post edited March 04, 2018 by prophet60091
Unfortunately I am unable to login.
http login is successfull and I can also sucessfully login to the api using the flag,
but whatever I do I get a

Couldn't resolve host name
HTTP: Login successful
Galaxy: Login failed
avatar
Sude: ...
This is unlikely to be worth addressing as it won't affect many (and would require quite a bit of rewrite), but from the behaviour I am seeing, I'm going to guess that you are opening the downloads for writing, even if they are complete (or your use of curl is)?

This behaves really badly for copy-on-write filesystems (such as overlay) as it just causes everything to be copied from the lower directory to the upper directory.
avatar
xyem: This is unlikely to be worth addressing as it won't affect many (and would require quite a bit of rewrite), but from the behaviour I am seeing, I'm going to guess that you are opening the downloads for writing, even if they are complete (or your use of curl is)?

This behaves really badly for copy-on-write filesystems (such as overlay) as it just causes everything to be copied from the lower directory to the upper directory.
+1
I'm using snapper snapshots (on top of Btrfs) as a safety and to manually review changes between updates, and snapshots diff take a lot longer than they could because for many files snapper can't quickly tell they're unchanged. Nothing critical for me either, but a few TB reads for no good reason...
avatar
prophet60091: First of all, thanks Sude for putting this together.

Is there a way to not download Windows related executables for extras, etc. when setting "platform=l,w"? The latter switch has the desired effect of prioritizing downloading Linux instead of Windows builds, but it also seems to download extras, patches, etc. that exist for Windows, but not Linux .

For example, the script correctly downloads the Linux version of Kerbal Space Program, but it also downloads all the patches for the Windows version (that don't exist for the Linux version).

I suppose LGOGdownloader is just doing as instructed, but I'm wondering if there's a way to change this behaviour without having to resort to blacklists for each affected game.

Cheers, and keep up the good work. I hope GOG sends some freebies your way!

PS- I'm using the "l,w" switch because I have two Windows-only games (boo! hiss!) that I'd like to archive.

PPS-These were freebies, so I couldn't specify a Linux platform.
Currently the priority handling doesn't take this situation into account.
It could be possible to change it to skip patches for platforms that don't have the same priority as installers.
I've been thinking about changing the priority system so that the user has more control over it. But for now this is a low priority issue.

avatar
Zerginator: Unfortunately I am unable to login.
http login is successfull and I can also sucessfully login to the api using the flag,
but whatever I do I get a

Couldn't resolve host name
HTTP: Login successful
Galaxy: Login failed
I wasn't able to reproduce this. Might have been a temporary server issue.
Try running "lgogdownloader --threads 1 --login --verbose" to see which host name it fails to resolve.

avatar
xyem: This is unlikely to be worth addressing as it won't affect many (and would require quite a bit of rewrite), but from the behaviour I am seeing, I'm going to guess that you are opening the downloads for writing, even if they are complete (or your use of curl is)?

This behaves really badly for copy-on-write filesystems (such as overlay) as it just causes everything to be copied from the lower directory to the upper directory.
avatar
petchema: +1
I'm using snapper snapshots (on top of Btrfs) as a safety and to manually review changes between updates, and snapshots diff take a lot longer than they could because for many files snapper can't quickly tell they're unchanged. Nothing critical for me either, but a few TB reads for no good reason...
The downloader always tries to continue downloading just to be sure nothing is incomplete.
I can rewrite it to skip complete installers, language packs and patches because we can get accurate file size information and file hashes for those.
For extras always trying to resume seems like the best option at the moment because GOG doesn't provide xml data for those. Though I could get the file size info from the content-length header.
The changes probably need little code restructuring so I'm not sure when I can get it done. But I was already planning on doing changes to some of the download logic so adding some code restructuring to that doesn't seem like a bad idea.
Trying out this tool. Looks like I got it to build successfully, but am struggling to login. Once again it's Google's bastard named captcha that seems to be the issue. Presumably this isn't the first time people mention it, so has a solution been found?


Login form contains reCAPTCHA (https://www.google.com/recaptcha/)
Try to login later
HTTP: Login failed
avatar
Sude: I wasn't able to reproduce this. Might have been a temporary server issue.
Try running "lgogdownloader --threads 1 --login --verbose" to see which host name it fails to resolve.
You're right, it is working perfectly now. Obviously some temporary problem on GOGs side.
Surprisingly it worked to login today, and the cookies.txt file got created. Woot.

However, I have already downloaded a great deal of files 'manually' with uGet. Currently they're all in the same folder, as it was easier that way, not least for checking if the file was already downloaded. Is it possible to download the rest of the files in my library (including all extras), and put them in subfolders, without redownloading 200GB of files?

In other words, check in the folder if the file is already downloaded. If it isn't, download it and put it in a game subfolder.

Edit: I've run the --status command, which returns ND (not downloaded) for all files, so I'm guessing this doesn't work like I hoped.
Post edited May 02, 2018 by Pangaea666
avatar
Sude: .....
Was finally able to login again, and trying the --repair function. Shouldn't it use remote xml if there isn't a local version? I keep getting:

[i]Repairing file ./wizardry_8/extras/wizardry_8_soundtrack.zip
XML: Using local file
XML: File doesn't exist (/home/pangaea/.cache/lgogdownloader/xml/wizardry_8/wizardry_8_soundtrack.zip.xml)
XML: Parsing failed / not valid XML[/i]


The config.cfg file looks like the below, which to me indicates remote XMLs should be used.

[i]automatic-xml-creation = false
cache-valid = 2880
chunk-size = 10
cover-list = https://raw.githubusercontent.com/Sude-/lgogdownloader-lists/master/covers.xml
directory = .
dlc-list = https://raw.githubusercontent.com/Sude-/lgogdownloader-lists/master/game_has_dlc.txt
exclude = covers
include = all
insecure = false
language = en+no
limit-rate = 0
no-color = false
no-duplicate-handling = false
no-remote-xml = false
no-subdirectories = false
no-unicode = false
platform = l,w
progress-interval = 100
retries = 3
save-changelogs = true
save-serials = true
secret = 0b76a6e65b20edeebe2fdecaa45e5aa433e411ce
subdir-dlc = dlc/%dlcname%
subdir-extras = extras
subdir-game = %gamename%
subdir-language-packs = languagepacks
subdir-patches = patches
threads = 4
timeout = 10
token = a6e750cc15a3719f4d87d26ebf1d0da6936862e6
use-cache = false
verbose = false
wait = 0[/i]


I keep saving so that covers should be included, but it goes back to exclude them pretty quickly. Not sure why. For instance, just now I ran the --repair function (nothing else), and then I noticed exclude covers was back in the config file (as quoted above). Would be nice to get the covers too. When I save the file with --exclude "" --save-config that line is removed, but for some reason it doesn't "stick".


But back to the original point: Why isn't remove XML used? Don't they exist for all files or something?
avatar
Pangaea666: But back to the original point: Why isn't remove XML used? Don't they exist for all files or something?
No remote XML for extras.
avatar
Pangaea666: But back to the original point: Why isn't remove XML used? Don't they exist for all files or something?
avatar
Gydion: No remote XML for extras.
Ok, thanks. I've managed to download most files now. But I did notice one issue that may not be easy to solve. Games that have been removed from GOG's store, but exist for users who bought them before the removal, don't get processed.

For example, I have the Wallace and Gromit games, and I don't find them in the store, so they must have been removed at some point. That means folders and extras and such don't get created or downloaded by LGOGDownloader, but would need to be downloaded manually.
avatar
Pangaea666: For example, I have the Wallace and Gromit games, and I don't find them in the store, so they must have been removed at some point. That means folders and extras and such don't get created or downloaded by LGOGDownloader, but would need to be downloaded manually.
I also have Wallace & Gromit and downloaded it a while ago with LGOGDownloader (older pre-Galaxy API build). Is this one of the games that has a weird/wrong game folder by default from GOG? I think I overrode the download directory for them. I will check when I'm back in front of the machine with LGOGDownloader. Can you see it with --list-details?
avatar
Pangaea666: I keep saving so that covers should be included, but it goes back to exclude them pretty quickly. Not sure why. For instance, just now I ran the --repair function (nothing else), and then I noticed exclude covers was back in the config file (as quoted above). Would be nice to get the covers too. When I save the file with --exclude "" --save-config that line is removed, but for some reason it doesn't "stick".
I think this is an issue caused by the downloader removing exclude option from config file instead of saving it as empty string. When boost program options parses the config file it doesn't see the option set because it's missing and fallbacks to default value (exclude = covers).
You can either edit the config file and manually and add "exclude = " to it or just set its value to something that isn't a valid option in INCLUDE_OPTIONS. For example "lgogdownloader --exclude nothing --save-config" in which case value for exclude is set to 0 when the option get parsed.


I will probably remove cover download option when I work on the download logic next time.

The cover list is unmaintained. I haven't updated the cover list for almost 4 years now.
I added --cover-list option few months after I stopped updating the list in case someone else wanted to maintain the list but I don't know about anyone maintaining an updated cover list.
I certainly don't have any interest in maintaining the list.

"exclude = covers" has been default for almost 3 years and this is the first time this bug has been discovered so I doubt many people even use the option anymore.

Thus removing the option seems like a logical course of action.