Thanks, I'll check it out.

Don't know if you have ever tried my GUI for your program, but it measures size and speed of each download. Times are also logged.

I compare that with the speed etc I get with Free Download Manager 5, and the difference is striking.

Unfortunately, I don't really use Windows, except to run games so I can't run Autoit applications.

You'd think that by now, we'd have widespread cross-platform software figured out, but commercial interests nipped that in the bud.

A mate of mine, TheDcoder, who you know, is making a cross-platform type implementation, called EasyCodeIt. I know him through AutoIt, though he uses Linux mostly now. He is quite a clever guy, that I have known since he was 14 ... he's 20 now.

Talking about download speeds.

In the early hours this morning, speed was down to between 200 and 300 KB/s for me with gogcli.exe, and between 800 and 900 KB/s with Free Download Manager 5. It should be around 5 MB/s.

I got a few of the smaller files from two new purchases, then eventually decided to turn my modem off for a bit and restart my PC.

It made bugger all difference. A bit later though, I finally manged to download the larger files at around 2 MB/s with FDM5.

GOG's servers seem to be very erratic in my neck of the woods these days, but that's the worst speeds I have ever experienced with them.

I created some issues to start managing my todos with the tool:
https://github.com/Magnitus-/gogcli/issues/4
https://github.com/Magnitus-/gogcli/issues/5

I have to balance that with my side projects that are work-related, but I'll progress on it this weekend.

I added some perf metrics for the sdk download command which may be of interest to you. So far, I got readings roughly corresponding to my home internet speed (but it probably depends on whether the GOG servers are saturated with traffic).

After some reflection, I'll try to go with the multipart data on the web offline endpoints. I'll progress on that over a couple of weeks.

At first, I'll add the multipart data from the xml to the download info gog-api command when available.

Then, I'll augment the capability of the download sdk functionality in a backward-compatible way and incorporate it as POC to the download gog-api command.

If that goes well, I'll incorporate it into my storage commands. That might take a bit of time, but anyways, you're not using that part so its mostly for me.

Keep in mind that I'm not working on the above 100% of the time, I want to gradually incorporate my own personal wishes for missing features as well, but I'll be progressing on it steadily.

I probably won't be touching it (or very lightly) tomorrow, I have to rampup my fluentd, so further progress will have to wait next week.

No problem for me. I always code for myself first, and then maybe incorporate things for others if I am going to share, and I mostly like to share. I have a need, much like yourself, and so I often code something, then I look at the viability of sharing, and then consider features that others might appreciate, that are reasonable for me to do, time and skill wise. My need is the motivation I need to code something, and coding is purely a hobby for me. So I'm never out there creating something purely for others, it has to also be of use to me.

----------------------------------------------------

Not sure if you have been following any of my other software threads or my older posts in the gogrepo.py thread.

Anyway, I never had good downloading success with Kalanyr's fork of gogrepo.py, only with the original gogrepo.py. In discussions we kind of worked out that his fork downloads differently and on my low powered PC, that creates a problem.

Having now investigated the Python based CLI downloading etc program, Legendary, for Epic Games, where with my 32 bit version compile of it, I run into a Shared Memory issue, and downloading fails, I am guessing there might be some parallel. I imagine that Legendary is downloading in chunks, so supports multi-threading, plus no doubt has a resume ability. Legendary is only provided as a 64 Bit version, which was why I had to compile to 32 Bit myself from the available source, and the author warned about no 32 Bit version due to Shared Memory concerns.

So essentially what I am trying to say, is that your improvements may not help me much on this low powered PC, though I can but hope. Don't let that put you off though. Galaxy certainly works for me, so it can't be impossible. :)

I am hoping to bring my much more powerful 64 bit PC into use, sooner rather than later. Just need to finish with house and shed jobs. Health concerns have delayed me far too long, but now finally seem to be on the improve ... been a long road of many years now ... one thing leading to another and then another etc.

Just realized that I've been a bum and did not update the initial post in a while, so I just did so.

Same here. However, I'll do a reasonable (nothing too crazy) amount of extra work if it allows others to better leverage what I'm doing for myself, provided that the amount of work is not insane (I do have a job and other ambitions) and that it doesn't turn the tool into some Frankenstein monster that is trying to do too much.

I try to provide building block functionalities so that if others want to build something on top of what I'm doing for their own custom flow, they can. I think it forces sensible design decisions anyways.

If it is a 32 bit download speed issue, I'll admit that it is not something that interests me greatly (32 bits system are on a fast track for deprecation, still relevant only for some low-end iot devices). I'm happy to support such systems provided that it doesn't require too much overhead.

I'll do the multi-part download anyways because I think its relevant to be able to resume larger downloads and we'll see if it makes a difference for you.

Otherwise, I wish you the best recovery for your health. We all get there, sooner or later.

I don't go that far, though I do provide source code.

Thanks, and I hope so.

P.S. Of course, it isn't just Galaxy that can do multiple threads and resume with GOG downloads, the Free Download Manager 5 program works well too. The 32 Bit issue is no doubt a Python related download issue with a specific method of use.

Added notes for version 0.16.0 and 0.17.0 releases (forgot about it).

Might release sporadically until early December.

Work is ramping up and I'm running out of small/medium quick wins improvement to do. One small & one medium feature left, and then the others are more ambitious and large, best left for when my work load at the office is more moderate.

Just an informative comment to further illustrate my speed issues.

Late last night I bought four games from GOG.

Two of them, roughly 1.3 Gb each, downloaded at around 4.2 MB/s.
The other two games, dropped dramatically in speed, when downloading the two 4 Gb files ... at roughly 2 MB/s.
Because I was tired and just wanted to go to bed, I cancelled the downloading.

Today, a little while after awaking, I tried again.
Damn it, speed was worse ... roughly 1.2 MB/s for the two 4 Gb files.
So I cancelled again.

Then I fired up Free Download Manager 5, and proceeded to download those 4 Gb files at an average of 4.7 MB/s.

It would appear to me, that when downloading via the GOG SDK, that large (i.e. 4 Gb) files are being forced to download slowly ... certainly for me here in AUS. This something I have often noticed in the last year or so.

I took a quick peek. The only thing that caught my attention in what the tool you are talking about does is the multipart download so I think it is the most likely suspect.

Otherwise, in terms of the underlying golang implementation for http, I have a lot of faith in it. Its a language that is used A LOT in the cloud for all manners of very large distributed networked systems so saying its core networking components have been battle-tested would be an understatement.

I guess it hasn't been as much tested on Windows 32 bits so there could be that (for example, perhaps some default configs are not well optimised for large downloads on a 32 bits system, I'm not sure), but I'm still pretty sceptical. We'll see after we have a functional multi-part download.

Today, all day and this evening, I have not been able to download any faster than 204 KB/s from GOG .... yes you read that right ... a lousy 204 KB/s. If I instead used Free Download Manager 5, it fluctuated all over the place and never got above 1.2 MB/s and was consistently much lower than that.

In the same period, and even occasionally at the same time, I have been able to download from Epic, flat out ... so around 5 MB/s. Even while doing that or not, the 204 KB/s from GOG never varied ... like the speed was set in concrete.

Clearly I am having a connection issue with GOG today, no doubt server based and their fault .. probably being deliberately limited, going by the unvarying very slow speed.

Considering I made 10 purchases from GOG earlier today, you won't be very surprised at how pissed off I am at them right now, for giving such lousy poor service. And I say that as a GOG supporter.

GOG need to seriously start caring about ALL their customers, and improve the server situation.

GOG's content delivery servers for your part of the world must suck really hard or there is some problem with their hardware or in their configuration.

I just downloaded updated offline installers for 9 games and had 60 MB/s pretty much the whole time (for plain old single threaded browser downloads) so it's obviously not something everyone is seeing. Have you asked fellow Australians about their download experience?