I forgot to increase the connection timeout to 10 seconds in the API previously. Current git has the timeout increased to 10 seconds.
There was a timeout in the earlier logs so try if the current git version with longer timeout works.

That's good. Another bug crushed :)

great, thanks =)

https://aur.archlinux.org/packages/lgogdownloader-git/

I've uploaded a git version of the Arch PKGBUILD to the AUR.

LGOGDownloader 2.3
- Use static memory allocation for extras and installers in gameDetails
- Added listing and downloading updated files
* use --update-check with --list or --list-details to list updated installers
* use --update-check --download to download updated installers
- Show update status for installers when listing details
- Fixed a bug in API that caused update flag to be set true for all installers
- Connection timeout increased to 10 seconds
- API::API() now has a parameter "const bool& verbose" that sets verbose mode for curlhandle in API
- Respect RFC 2616/10.3.2 by not converting POST requests to GET requests when following redirects

http://sites.google.com/site/gogdownloader/lgogdownloader-2.3.tar.gz

sha256: b1a5fd26f650a697b63a8da0f237b24f6a0900d4581f061e90c632d1ea077272
md5: e5172939854d5644301ab564034b1be1

Will you add these releases branches to git somehow? It can actually even produce tarballs as well, so there is no need to store it in two places.

Done

Apparently some installers use the same filename for all languages (for example The Witcher 2)
It might get fixed server side later
https://secure.gog.com/forum/general/introducing_the_beta_release_of_the_new_gogcom_downloader/post1479

EDIT: changes partially reverted because of this

For folks trying to use this on Fedora (18 in my case):

Dependencies in Repositories:

yum --enablerepo updates-tesing install jsoncpp-devel

yum install gcc-g++ make boost-devel curlpp-devel libcurl-devel liboauth-devel tinyxml-devel boost-program-options boost-regex boost-filesystem

Unfortunately, Fedora does not package htmlcxx or librhash. You'll need to compile them yourself.

rhash 1.2.10 is straight forward enough (make lib-shared ; make install-lib-shared, and possibly add a symlink from /usr/local/lib/librhash* to /usr/lib64/; the "make rpm", unfortunately, does not work).

htmlcxx 0.84 requires a patch due to the g++ being used by Fedora being newer than it expects; just add

#include <cstddef>

to the html/tree.h file right below the other includes. Then it's a straigh ./configure ; make ; make install (and possibly symlinks as before).

Finally, you may need to change the Makefile of lgogdownloader (add -I<YOUR_PATH_TO_RHASH>/librhash to the INC variable so it can find the rhash headers).

Once it is all compiled, lgogdownloader works like a charm. Thanks Sude :-)

Git version now has the ability to help keep installers up to date regardless of GOG's retarded method of updating installers (silent updates without increasing the version number of the installer)

This is done by using the repair mode.
Repair mode can now redownload the file if filesizes don't match (possibly different version). Use "--repair --download" to enable redownloading durring repair.
This deletes the old file before attempting to download.

It's probably better to use MD5 hash, rather than filesize. But why don't GOG bump the version if they change the installer? You should try reporting this problem to them.

Instead of calculating md5 for a 2GB file it's a lot faster to just check the file size first (this assumes that the user has complete file). If the filesizes match then it does hash check on the chunks.

This of course doesn't work on normal downloads. When running --download normally it just assumes that the file is incomplete if it is possible to continue downloading (server has bigger file) and resumes the file.
This is will cause problems (corrupted installers because of incorrectly resuming old complete file with parts of new file)

It would be possible to download a small chunk of the file and compare it to local file before attempting to resume.
I may work on this if GOG continues to do silent updates without incrementing the version number.
Makes you wonder what's the point of having version numbers in the filename if they are not used.

GOG usually are listening to sensible proposals. May be create a site request for that ( http://www.gog.com/wishlist/add/site ) if you think it's a "feature" request or report it to GOG directly if you think it's a bug report: http://www.gog.com/support/contact

It would be interesting to follow up on this issue. Hopefully they'll respond if they do, please post their response here.

I think that this wouldn't work, since I'm under the impression that some chunks on the installers were the same. I'll try to shift through the log file and see if I can verify it, but best to do a full md5 hash.
Unless the HTTP-last-modified flag can be used instead, or however the flag is called.