lgogdownloader --wishlist stops after a 11 entries ( mine is > 150 items long :) with:

terminate called after throwing an instance of 'std::invalid_argument'
what(): stoul
Aborted

I think it is the same bug as in --list

I made some changes to how wishlist is handled.
Does 6bf76db fix this issue?

$ lgogdownloader --wishlist 2>&1 | egrep "^[a-Za-Z0-9]+" | wc -l

nets 153 games, my full wishlist :-)

LGOGDownloader 2.22
- Added option to download files by using file id
* --download-file "gamename/fileid"
- Fixed multiple DLCs when using cache (patch by: Ismo Toijala)
- Made progressbar display 10 second average download speed instead of average for the whole download
- Added support for new account page layout
- Added --wishlist option to show wishlist
- Makefile change: "make install" will now install debug build if it has been built

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

sha256: 407df29d6d051cbbad1d80096ca4158cb3be13ce5065229ed193a9885c5c37d2
md5: 309b8b78df4627c226670c27aee57f56

Hi. I'm having a big issue on lgogdownloader 2.21 compiled on Linux Ubuntu 14.04 LTS (64 bit)

well.... it says:
HTTP: Login failed

I tryed:
lgogdownloader --login
lgogdownloader --insecure --login
lgogdownloader --verbose --insecure --login

(compiled using "make" without changing anything)

but I cannot figure why I am not able to login with lgogdownloader.

Any help?

2.21 uses the old account page layout. It tries to find username/email at https://www.gog.com/account/settings/ to check if login was successful.
The login could be successful but the check will fail because it can't find a match there (that page no longer contains the info).

Updating to 2.22 should fix this issue.

LGOGDownloader 2.23
- Option to show wishlist is no longer saved to config file
- Added simple login check as a fallback to current complex HTTP login check
* This fallback method should work even if GOG changes the site layout as long as account page location remains the same
- Fixed error with login when cookies didn't exist but API login worked because config.cfg contained valid secret and token

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

sha256: e04bfa506e5ba5b5d98255babfd9fbadf4c53af6198aace7ac33a7ed44083c66
md5: 799152a5611e4b1f6bec823b0e07b70c

Thank a lot... I downloaded 2.23 attached here and it seems it finally log-in. Now I will test it :)

Now the games are unbundled, lgogdownloader is grabbing extras multiple times. I run lgogdownloader to download all my games at varying intervals; I have 3 copies of each of the Ultima 4-5-6 extras, and a few other cases of extras being done twice.

For me it's not a problem - the games that do this have extras of a small filesize, but it's a funny quirk and one which is probably tricky to workaround.

If GOG would provide XML data for extras this would be relatively easy to workaround by maintaining a database of filehashes and comparing those before starting to download the file. Then either skip the file or automatically symlink/hardlink it to previously downloaded file.
Unfortunately GOG doesn't provide XML data for extras :(

Another method would be to have a file containing the filenames of extras which to download or skip but it would require human interaction in keeping the file updated so it isn't very practical.
Which is also one of the reasons I've been thinking about removing the option to download covers. I haven't updated the cover list in a long time because I haven't had the time to do it manually after I lost the script that did it automatically for me.

Please don't.

If you can post the information necessary to recreate the script, maybe one of us could do it for you. (I'd offer but, at the moment, I'm catching up to some backlogged coursework. However, if you remind me in July, I could.)

Now, I don't know how you currently check login status, but if you load https://www.gog.com/userData.json, isLoggedIn will be true or false depending on said status.

This is when I last updated the list
https://www.gog.com/forum/general/unofficial_dvd_covers_for_gog_com_games/post1450

The script parsed the posts from that thread and gathered the author's name, game names and urls.
Because the game names in that thread are the displayed game title instead of the game name that lgogdownloader uses, the script converted those by using data from GOGWiki and GOG game list.
When the script had gathered all the info it called a simple program that I wrote in C++ which modified the existing cover list.

Here's add_cover.cpp which was used by the script to add covers to the cover list.
Compiling: g++ -std=c++11 -Wall -ltinyxml -o add_cover add_cover.cpp
Usage: ./add_cover covers.xml gamename author url

That seems much simpler than what I'm currently doing.
Currently the downloader tries to find username or email in https://www.gog.com/account/settings/personal and if that fails it tries to load https://www.gog.com/account and checks that the response code is 200

Something's weird with a witcher 3 extra:

Repairing file ./the_witcher_3_wild_hunt/the_witcher_3_videos.zip
XML: Using local file
XML: Valid XML
XML: Parsing finished

the_witcher_3_videos.zip
MD5: fbe8986e6cf8717b92a901f76ddf2e41
Chunks: 61
Size: 638814958 bytes

Filesizes don't match
Incomplete download or different version
Redownloading file
Renaming old file to ./the_witcher_3_wild_hunt/the_witcher_3_videos.zip.20150529T180132.old
100% ▕██████████████████████████▏ 1264.67/1264.67MB @ 2.09MB/s ETA: 0s

The downloaded file is exactly the same that was there before, with 1.2GB and not 600MB like 'Size' claims. Any ideas?

This is caused by old XML data and Downloader::repairFile not updating the XML data when it redownloads the file.
0230a35 should fix this issue by creating new XML data on filesize mismatch.