Updating the game installation is the most useful case.

Bellend much?

After seeing the update here on 3.10 the other day I thought I'd give that a try and... yeah. 3.10 fixes the login issue on Mac and I am once again updating my library with lgogdownloader.

Thanks Sude!

Good luck continuing to wrestle with lgogdownloader workarounds! :-P
And welcome back ;-)

Would anyone have any suggestions on how to speed up the --update-cache operation? It's taking about 4 seconds / game and I have a lot of games. Using --threads 8 on the command line as well, and pasted my config below. Thanks!

automatic-xml-creation = true
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
include-hidden-products = true
info-threads = 12
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 = w+l
progress-interval = 100
retries = 20
save-changelogs = true
save-serials = true
size-only = false
subdir-dlc = dlc/%dlcname%
subdir-extras = extras
subdir-game = %gamename%
subdir-installers =
subdir-language-packs = languagepacks
subdir-patches = patches
threads = 4
timeout = 10
use-cache = true
use-dlc-list = false
verbosity = 1
wait = 2

Forgot to mention, on 3.10; just compiled 3.11 and will run tonight but the different versions over the last long while haven't made any difference.

Hello sude, thanks again for the great work and also to everybody on github that contributed.

What is the safest method of updating?
Should I delete all the files / manual uninstallation or can I download and build everything that it will autoswap all the files needed?

Thanks.

b520eb8 Speedup cache update

That change should massively speedup cache update when --ignore-dlc-count option is not used
Previously cache update always forced dlc count to be ignored for all games causing the downloader to get lots of unnecessary details in a single threaded code path.
Now some of the details (mainly serials and changelogs) are gathered later on the multi threaded code path if necessary.
I'm actually considering removing --ignore-dlc-count option because it doesn't really have a purpose anymore due to changes in the downloader even though GOG still doesn't report dlc count properly.

Setting --info-threads to bigger value could speed up the operation but it's not really guaranteed

Thanks! I'll give it a try this evening and report back.

RE b520eb8 Speedup cache update

Wow, it zipped right through the update cache! Thanks!

Now, another question, during the next step, I use:
--download --report --verbosity 1
and sometime I believe within the last build or two I get a lot of these messages (I'm sure I'm probably just seeing them now, maybe to your verbosity change in 3.10?) Anything needed to be done about this on my end or is it just a GOG thing?


Response code for https://api.gog.com/products/1440500290/downlink/installer/en2installer0 is [404]
Response code for https://api.gog.com/products/1440500290/downlink/installer/en1installer0 is [404]
Response code for https://api.gog.com/products/1781057675/downlink/product_bonus/93589 is [404]
Response code for https://api.gog.com/products/1380416196/downlink/product_bonus/89453 is [404]

That's most likely caused by downloader trying to get details for unowned DLCs.

9cd85f6 Don't try to get details for unowned DLCs

That should get rid of most or all of the 404 errors

Great! It got rid of all but 5:
Response code for https://api.gog.com/products/1978178686/downlink/installer/en1installer2 is [404]
Response code for https://api.gog.com/products/1207665233/downlink/installer/fr1installer3 is [401]
Response code for https://api.gog.com/products/1430740458/downlink/patch/en1patch1 is [401]
Response code for https://api.gog.com/products/1088633272/downlink/patch/en1patch4 is [401]
Response code for https://api.gog.com/products/1978178686/downlink/patch/en1patch0 is [404]

Version 3.11 and current master of lgogdownloader cannot be built with libcurl3 anymore:

-- Found CURL: /usr/lib/x86_64-linux-gnu/libcurl.so (found suitable version "7.52.1", minimum required is "7.32.0")

src/downloader.cpp: In static member function ‘static int Downloader::progressCallback(void*, curl_off_t, curl_off_t, curl_off_t, curl_off_t)’:
src/downloader.cpp:1435:63: error: ‘CURLINFO_SPEED_DOWNLOAD_T’ was not declared in this scope
if (CURLE_OK != curl_easy_getinfo(downloader->curlhandle, CURLINFO_SPEED_DOWNLOAD_T, &curl_rate))

CURLINFO_SPEED_DOWNLOAD_T is used in at least two more places.

Is there a workaround available to still build lgogdownloader with libcurl3?
If not at least the minimum libcurl requirement should be adjusted.

Edit:
Reverting 78c8f435768b63224bb4ee429d5575813956b6a8 and replacing CURLINFO_CONTENT_LENGTH_DOWNLOAD_T by CURLINFO_CONTENT_LENGTH_DOWNLOAD fixes the build for now. But I'm not sure if the different variable type for the returned file size causes any problems at runtime.

I forgot bump the minimum libcurl version in 78c8f43
0f3ce5d sets minimum to 7.55.0

Reverting 78c8f43 shouldn't cause issues due to different variable type because the value is casted to double like it was previously

The GOG servers have gotten slower and slower over the years, for me from initially half a second to 3 or 4 seconds per game lately. This change speeds up the process again to multiple games per second, despite the slower GOG servers. Amazing work!

But what are the newly added (between v3.9 and v3.11) zeros at the end of the filename lines? Like:

ND dreadful_river_demo setup_dreadful_river_demo_0.4.138.1_(64bit)_(63857).exe 0
ND imagine_earth_demo setup_imagine_earth_1.11.4.5788-gog-demo_(63810).exe 0

Is there any option to get rid of them?