It seems that some change broke the automatic login.
You can use "lgogdownloader --login" to avoid the issue caused by automatic login.

Or you can try this patch to see if it fixes the issue with automatic login
https://sites.google.com/site/gogdownloader/fix_automatic_login.diff

Failed login attempts while testing the patch caused me to start getting recaptcha on login form so I haven't been able to test it properly yet.
Once recaptcha on the login form goes away and I've been able to test it properly I'll apply this patch to git repository.

No luck - 'lgogdownloader --login' appears to work properly, but afterwards 'lgogdownloader --list' gives the same result as before. 'lgogdownloader --login --list' also doesn't work. I'll try the patch later, but I'm also getting the recaptcha now so I'll have to wait.

I made some code restructuring
https://github.com/Sude-/lgogdownloader/commit/dea82b7

I hope that it also fixes the login issue. Everything seemed to be working on my tests.

Most recent source is working for me now, thanks.

Downloading is working great now, but I just ran into a new problem - checking the validity of downloaded files doesn't always work. I created an issue at GitHub (GOG isn't letting me post a link for some reason, but it's issue #98), but the tl;dr is that it's only checking the MD5 hash for installers and not extras, patches, etc.

Despite that, this is still a very useful tool for downloading my new purchases without needing to start up Galaxy. Thanks again for all the work you've put into this!

Your rep is too low.

Sorry I haven't used lgogdownloader, but where does it get the md5 hashes? My understanding is that GOG.com provides md5 hashes for the installers, but not for e.g. the extras. The extras' integrity should be checked by some other means, e.g. by their zip file integrity.

If my understanding is correct, that would at least explain why it is not using md5 to verify the extras. :)

That makes sense. I did some experimenting, looking at the XML cache the MD5 sums it writes there are generated from the existing files rather than from the GOG servers. Well, that's slightly disappointing, and a little weird that GOG would only supply hashes for some of their files, but what are you going to do. I'll go ahead and delete that issue then, since it's not really a bug.

If you want integrity checking then you are better off using --repair which does integrity checking based on file chunks and can repair the corrupted files.

--status isn't very good for checking integrity because it relies on the saved xml data.
It doesn't compare the actual file hash but instead only compares local xml data against the remote xml data.
The reason for this is that initially the main purpose of --status was to quickly see if there had been any server side changes like silent updates to installers or new files added.

When checking the code for Downloader::checkStatus() function I noticed that I hadn't actually added remote xml data support for patches and language packs since GOG started to provide xml data for them (or at least some of them).
I've started to work on a rewrite of Downloader::checkStatus(). I'll try to remove most of the duplicate code from it and add remote xml data support for patches and language packs.

Hi, I am trying to build the lgogdownloader on Ubuntu 16.10 and after solving every dependencies needed I am stuck on this one,
-- Checking for module 'oauth'
-- No package 'oauth' found
CMake Error at /usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:367 (message):
A required package was not found
Call Stack (most recent call first):
/usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:532 (_pkg_check_modules_internal)
cmake/FindOAuth.cmake:9 (pkg_check_modules)

But I have the php-outh installed.
Also installed with pecl install oauth
How can I add it to cmake?
Couldn't find any hint by googling, that's weird I can't be the single one with this issue.

Edit: Managed to solved all deps; now I have a make error, downloader.cpp:(.text+0x1d59f): undefined reference to `curl_easy_setopt' what this could mean?

Install solved: I have found a package install-able with apt-get and it worked.
Now I can't login because it keeps prompting me to add the browser's cookie to the cookie.text which I did but doesn't work, I get everytime login failed and that file is getting recreated.
I am sick of the amount of time lost on a thing that should be working.
When I buy a game I expect to get a working game not spend a day with workarounds which are not working anyway.
You're selling games for Linux but not able to deliver them?
Final edit (I hope): finally got it to work :-( all this trouble because the game file downloaded through the browser didn't work, bad md5 sum too.
Final final edit: downloaded the game, this file doesn't work either:
/bin/sh: 0: Can't open ./gog_tex_murphy_the_pandora_directive_2.1.0.7.sh
still the wrong md5sum either.
Frack!

Finally: found the solution by myself, without any other help from GOG (except telling me to try the lgogdownloader) no matter how many emails I have sent or the post on this forum.
For others in this situation with errors on executing the sh file and ABSOLUTELY NO SUPPORT from GOG:
The solution is to change the .sh extension into .zip, unarchive the zip file and start the game directly.

LGOGDownloader 3.1
- Make libcurl usage thread-safe (Patch by: Philipp Kerling)
* libcurl internally uses signals by default, which will crash the application when using multiple threads.
* Setting CURLOPT_NOSIGNAL on all handles avoids the crashes and is recommended in the libcurl documentation.
- Made getTerminalWidth detect if it is running in a terminal before trying to get the width (Patch by: Steffan Byrne)
* Before this change, if you tried to pipe the standard out to a file or run this as a process, it would fail.
- Moved global curl init/cleanup and ssl thread setup out of the Downloader class
* Allows using libcurl calls before calling Downloader::init() which can be useful in future
- Some code restructuring
* Moved some code from Downloader::init() to constructor
* Added function API::isLoggedIn()
* Added function Downloader::isLoggedIn()
* Downloader::init() no longer calls Downloader::getGameList() it is now called from other functions when needed
- Fixed some login issues
- Limit download thread count to number of items in download queue
- Rewrote and removed lots of duplicate code from Downloader::checkStatus()
* --status now tries to get remote file hash for patches and language packs
* GOG doesn't provide xml data for extras so we still have to rely on local xml data for those
- Made --list show number of updates for games that have been updated
* Allows user to check for updated games more easily
- Replaced all printf and sprintf calls using new Util::formattedString() function
* Util::formattedString creates formatted std::string using std::snprintf
* Fixes possible buffer overflow in Downloader::printProgress() caused by sprintf call

https://sites.google.com/site/gogdownloader/lgogdownloader-3.1.tar.gz

sha256: 010d98e23108f605a553efd42ae68abd9ec78db1b2cd18cab89f8fb7e20484c9
md5: fe22da56725c6af2d05bfa6047c2f69d

Why does "lgogdownloader --login" demand interactive shell? Using it from script requires "expect" witchcraft for no real reason, or am I missing anything here?

Why can't I just:

lgogdownloader --login $user $pass

case $? in
1)
do_nice
;;
2)
do_err_wrong_credentials
;;
*)
do_err_othererror
;;
esac

??

Almost 24 hours and no answer... awesome.

I am also using position-based interactively generated password, thus entering password as lgogdownloader wants it right now - is outright impossible.

Is there an equivalent for this thing, beside gogrepo?

dude, this ain't no support hotline. people are not sitting in front of their computers waiting to answer your questions ... passing passwords on the command line is usually considered a security risk, since command line arguments of all processes can be seen by every (unprivileged) user. Plus this way there is a high chance the password gets saved in plain text in ~/.bash_history (or similar)

ninja'ed