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: LGOGDownloader 3.7
The file size of the (stripped) lgogdownloader binary has more than doubled for me with this release:

978K 2020-02-26 22:52 lgogdownloader-v3.5-20-g0a7648d
2.2M 2020-04-09 01:09 lgogdownloader-v3.7

Has there anything new been included? (it's not a problem, just out of curiosity)
Downloaded and built the 3.7 version today, which worked as a charm. Tried to download Stardew Valley's latest updates using --download --game stardew_valley, and that worked too. Used 4 threads, and it didn't grind to a halt, which I had a problem with before, so I'm crossing my fingers this works on my end now :)

However, I'm getting an error message in terminal. I assume it's because the old config file got overwritten, but retained the old lines that apparently don't exist any more. Which ones are safe to remove, and will get rid of the error message?

The error message is: Unrecognized options in /home/pangaea/.config/lgogdownloader/config.cfg

automatic-xml-creation = false
cache-valid = 2880
chunk-size = 10
curl-verbose = false
directory = .
dlc-list = https://raw.githubusercontent.com/Sude-/lgogdownloader-lists/master/game_has_dlc.txt
exclude =
include = all
insecure = false
language = en
limit-rate = 0
lowspeed-rate = 200
lowspeed-timeout = 30
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 = [BLANKED]
subdir-dlc = dlc/%dlcname%
subdir-extras = extras
subdir-game = %gamename%
subdir-installers =
subdir-language-packs = languagepacks
subdir-patches = patches
threads = 4
timeout = 10
token = [BLANKED]
use-cache = false
verbose = false
wait = 0
avatar
Pangaea666: Downloaded and built the 3.7 version today,
avatar
Sude: "token" and "secret" options are no longer needed in config.cfg
Hi. I wanted to incorporate this program into a Gentoo eclass to enable installing GOG games through Portage. However, I've run into an issue. And while trying to report the issue, I ran into another issue.

1. Can you please enable issues on GitHub? That way people can report problems and feature suggestions. I don't even know why GitHub allows this, because this is just a pointless obstacle on the way to reporting bugs to developers. Pointless, because people will find one way or another. So I can't even begin to imagine what are people even trying to accomplish by disabling issues.
@edit - issues are disabled for anonymous. Can this be improved please?

2. Please add an option to supplement email and password from a credentials file. This is absolutely necessary to automate the use of lgogdownloader in Portage.
Post edited April 15, 2020 by grepwood
avatar
grepwood: 2. Please add an option to supplement email and password from a credentials file. This is absolutely necessary to automate the use of lgogdownloader in Portage.
For added security enforce a 0600 permissions on the password file, and it will be fine.
avatar
Sude: "token" and "secret" options are no longer needed in config.cfg
avatar
JackknifeJohnson:
Thank you, that worked :)
avatar
grepwood: 2. Please add an option to supplement email and password from a credentials file. This is absolutely necessary to automate the use of lgogdownloader in Portage.
avatar
coffeecup: For added security enforce a 0600 permissions on the password file, and it will be fine.
Filed https://github.com/Sude-/lgogdownloader/issues/168
I have a better idea than credential files. Environment variables. When Portage runs an ebuild, it has access to all the variables defined in /etc/portage/make.conf. Since this is a legal Bash file, we can order make.conf to source certain variables from other files like this:

GOG_EMAIL=$(grep ^GOG_EMAIL= /etc/portage/gog.conf | sed 's/^GOG_EMAIL=//)
GOG_PASSWORD=$(grep ^GOG_PASSWORD= /etc/portage/gog.conf | sed 's/^GOG_PASSWORD=//)
Is there something odd with the folders of the Pathfinder: Kingmaker extras, or my config file? It comes under "dlc" no matter what I do, while I wanted it in "extras" instead, so it's easier to differentiate proper content expansions from maps, books and so forth.

The default I had was:
subdir-extras = extras

This put it into dlc/NAME/extras/files

Tried extras/%dlcname%
but of course that just made matters worse.

Removed everything so I just have
subdir-extras =

But this still puts the extras into the dlc folder. But it does omit the subfolder in there, so now it's
dlc/NAME/files

Is it possible to change this in the config file, or is something weird with this particular game? I've not tried to download the whole catalogue (don't have spare space right now), so not sure if it's a universal thing. But I'd definitely prefer to have extras in their own folder, separate from dlc.
avatar
coffeecup: For added security enforce a 0600 permissions on the password file, and it will be fine.
avatar
grepwood: Filed https://github.com/Sude-/lgogdownloader/issues/168
I have a better idea than credential files. Environment variables. When Portage runs an ebuild, it has access to all the variables defined in /etc/portage/make.conf. Since this is a legal Bash file, we can order make.conf to source certain variables from other files like this:

GOG_EMAIL=$(grep ^GOG_EMAIL= /etc/portage/gog.conf | sed 's/^GOG_EMAIL=//)
GOG_PASSWORD=$(grep ^GOG_PASSWORD= /etc/portage/gog.conf | sed 's/^GOG_PASSWORD=//)
automatic login won't work with two-factor authorization. or when GOG decides to let you solve some reCAPTCHAs before allowing you in. The only way this would work is if the user stays logged in all the time and lgogdownloader can just use the existing authorization token. Though I am not sure if this is really a sensible approach from a security POV. Especially since GOG unfortunately didn't implement any kind of scope in their authorization system. So this authorization token gives not only access to your downloads but full access to your whole account.

I think the only good way to implement this is to mark the ebuild with RESTRICT=fetch and tell the user to download the package and place them in into their DISTDIR themselves. You could place a message into the ebuild that gives the user the necessary commandline to let lgogdownloader download the game in question.
avatar
grepwood: Filed https://github.com/Sude-/lgogdownloader/issues/168
I have a better idea than credential files. Environment variables. When Portage runs an ebuild, it has access to all the variables defined in /etc/portage/make.conf. Since this is a legal Bash file, we can order make.conf to source certain variables from other files like this:

GOG_EMAIL=$(grep ^GOG_EMAIL= /etc/portage/gog.conf | sed 's/^GOG_EMAIL=//)
GOG_PASSWORD=$(grep ^GOG_PASSWORD= /etc/portage/gog.conf | sed 's/^GOG_PASSWORD=//)
avatar
immi101: automatic login won't work with two-factor authorization. or when GOG decides to let you solve some reCAPTCHAs before allowing you in. The only way this would work is if the user stays logged in all the time and lgogdownloader can just use the existing authorization token. Though I am not sure if this is really a sensible approach from a security POV. Especially since GOG unfortunately didn't implement any kind of scope in their authorization system. So this authorization token gives not only access to your downloads but full access to your whole account.

I think the only good way to implement this is to mark the ebuild with RESTRICT=fetch and tell the user to download the package and place them in into their DISTDIR themselves. You could place a message into the ebuild that gives the user the necessary commandline to let lgogdownloader download the game in question.
What if Portage would rely on the absolute path to your GOG cookie? It already logged in given by chance it didn't have any captcha.
In an earlier post, I complained that update-cache was taking way too long. Lately, with lower internet connectivity, it's taking too long for the time window in which I can connect. I finally figured out a part of the cause, and a temporary fix. A while back, I cranked the retries variable to 100, because it seemed silly for the entire download to fail because of a temporary glitch. However, there are some API calls made during update-cache that always return a 404, and are thus retried 100 times. In fact, with my lower connectivity, I cranked the number to 1000, and of course that just made the problem worse. For now, I have just set the retry count to 2 during update-cache. A better long-term fix will take me some time: figuring out why the 404s, detecting them, and never retrying them (a 404 could also be the result of a network glitch, so I'm not sure yet what to do). Not that it was adding much, but it also seemed like the DLC info was downloaded on both phases, making the first phase take unnecessarily long, but that's still OK for now.
I do not know what is wanted by this error message:

-- iostreams
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
HTMLCXX_LIBRARY_CSS_PARSER (ADVANCED)

similarly:

lgogdownloader-master
HTMLCXX_LIBRARY_CSS_PARSER_PP (ADVANCED)

what exact file should they be pointing to?

diziet
Hi there,

I have used lgogdownloader some time ago to download my stuff, on gog.com, and it worked fine. Now, I currently put one of my RasPIs to work as an auto download host of sorts, and have it automatically downloa my stuff and any updates from several store fronts. For GOG.com, obviously, I use lgogdownloader. But now, alas, it does not work.

The symptoms are: it gets athe game names and the game info for all games and then stops.

So this is on a RasPI 3b with a fresh install of the most recent Raspian. I've created a build directory in the lgogdownloader folder and built with

cmake .. -DCMAKE_INSTALL_PREFIX=/home/autodl -DCMAKE_BUILD_TYPE=Release -DUSE_QT_GUI=OFF

plus the usual make... stuff.

The most basic call to lgogdownloader I've tried is

lgogdownloader --download --directory=/data/GOG-Downloads/ --retries=500

The target directory contains my old downloads, but I have also tried an empty directory. I also tried with --repair, and a lot of other stuff, nothing helps. --verbose does not output any aditional information, so I have no clue what's going on... is there anything else I can try, at least to get some additional information on what's going on?

Gunnar

Edit: OK, so I found the option to make libcurl more vorbose. In the (massive!) output I saw a few "The requested URL returned error: 404" errors, and some instances of "Connection 1 seems to be dead!". While the 404s are unexpected, none of those nor the dead connections seemed to be fatal.
Post edited May 20, 2020 by gunnar_z
I looked for it but did not find an answer. Is there any way to ignore a expecific game from downloading? My account has Witcher 3 GOTY and the normal version, it downloads both, any way to make it just download the GOTY version?

Edit: Blinded hard the man page. For anyone blind like me, create a blacklist.txt with the folder name for witcher(or game you want to exclude downloading): Rp the_witcher_3_wild_hunt_game/
Post edited June 19, 2020 by Adjuntor
Thanks, Adjuntor, for reminding me to post this. If anyone is interested, I am lazily keeping a set of lgogdownloader patches on my own misc game support project instead of trying to get any of it pushed upstream. I blame the COVID-19 panic keeping me away from the Internet, mostly. Patches include:

don't change the shelf search order when updating the cache
ignore SIGPIPE during cache updates (not sure why I felt the need to do that any more)
only write changelogs if they change

and ones I did specifically for the limited net access I referred to above:

make cache updates faster by skipping details updates in first pass and aborting 404 errors in second, as mentioned in my previous post on the subject
don't log in for check-orphans if using cache, and provide an as-yet-undocumented option to do an offline check of what would be downloaded

All these patches are in the lgogdownloader subdirectory.

Maybe in a month or two, if/when this idiotic panic ends, I'll put more effort into it.

edit: a few notes about that last patch:
First, it moves code around from the changelog patch, so that needs to be applied first.

The reason I wanted offline check-orphans is because it doesn't need to be on-line, and sometimes I forgot to run it while i'm on-line, and I have way too many games so my storage space is running low and I have to delete orphans before downloaning.

The reason for the offline download check is to prevent the need to redownload the XML and/or run a test download for every single file like normal on-line downloader does. I can use the new feature in three ways:

To just get an idea of what will be downloaded:

lgogdownloader --quick-download-check --exclude=p,c 2>/dev/null

When I have my USB drive that holds my downloaded games plugged in, to skip games that probably don't need downloads: I can still do a full download when all it's probably going to do is checks later.

lgogdownloader --download --exclude=p,c --game=$(lgogdownloader --quick-download-check --exclude=p,c 2>/dev/null | cut -d/ -f5 | sort -u | tr '\n' \| | sed -e 's/|$//')

But, since I do this on my laptop with no power, I prefer not to have the USB drive plugged in, and use my internal storage instead. So, off-line, I copy the affected game dirs over to the internal drive, do my downloads on the internal drive, and copy them back when done. This, and the cut command in the above snippet, relies on my root download directory being /mnt/usb3f/gog (the gog dir on drive connected to the front USB3 connector) When the drive is unmounted, I have a soft link in that dir to /mnt/gog, which is on the local drive.

# with the USB drive mounted, copy game dirs to be updated
for x in $(lgogdownloader --quick-download-check --exclude=p,c 2>/dev/null | cut -d/ -f5 | sort -u); do rsync -avH /mnt/{usb3f/,}gog/$x/; done

# to actually download, without the USB drive mounted (using only 1 thread for better reliability)
ls /mnt/usb3f/gog >/tmp/.ls$$; g=; while read x; do g="$g|$x"; done </tmp/.ls$$; rm /tmp/.ls$$; lgogdownloader --download --exclude=p,c --threads=1 --game="^(${g#|})\$"

# to move the new downloads back to USB
rsync -avH /mnt/{,usb3f/}gog/

It'd be even better if I added an option to make the 2nd use case a matter of giving a command-line option. Also, the ETA should be adjusted to remove files that are likely complete.
Post edited June 21, 2020 by darktjm