Is there a way to make the size of the GUI and the fonts a bit larger ?

fyi: https://github.com/Magnitus-/gogcli/issues/29#issuecomment-2406666184

The workaround being always applied for the extras should be resolved now. As it turns out, it was due to an api change from gog.

Thanks, I'll check it out.

FYI - My work-around for creating a manifest entry for a game by alternate means, has continued to work well, and in every instance except the one, it is always an Extras file that gives grief, but solved by my work-around. That one instance you may recall, was an alternate OS offline installer file (Mac I think) ... had to test (verify) using 7-Zip for that one.

Sorry, I'm currently dealing with a horrid cold, perhaps the worst one I've ever had, though I have had a worse Flu before.

Anyway, this is not really the right thread to discuss my GUI. You should use the following.

GOGcli GUI ... frontend downloader and validator

But the short answer, is that it isn't easy to change things without a major overhaul.
My GUI is designed to take up minimal desktop space.
It does use some default system settings, so you could possibly change those to improve things a bit, but that may likely impact what you are used to for other programs.

Anyway, if you wish to discuss this further, please use my thread, and not this Magnitus one.

I've now used v0.24.1 for a handful of games, and while it appeared to work well, I discovered a missing checksum value when validating after downloading. Luckily that was the very last game on my download list and the last file.

I've now verified that the manifest is indeed missing a checksum value for the PKG file.

The file or version appears to be a recent addition for The Witcher: Enhanced Edition

the_witcher__enhanced_edition_english_2_3a.pkg

It was the only (update) file I needed to download for the game. I was able to verify it with 7-Zip, creating a checksum in the process, but I was surprised by it, it not having been reported to me by gogcli.exe. Not really ideal with a 9.6 GB file. Luckily for me, such instances get reported and queried by my GUI after all downloading and regular validating has been completed. The file passed the bytes size check.

Is this expected behavior now or some new unexpected behavior?

I'll look into it further at my end.

P.S. If it had been reported to me, I could have set the validating etc to be automatic, and thus saved some time at the end.

EDIT
The following is what was reported for the game. The checksum value is also missing from the individual manifest download, before it gets incorporated into the full manifest. So I am guessing that should have been detected.

Created checksum value = 5A9AD426C1941FFC2D8E10707EFBE0A8

That seems to be on GOG. That file does not have a corresponding XML.

Yeah, I also checked that file individually, and no checksum was returned.
A reasonably rare occurrence, and somewhat ironic to be a CDPR game file.

I'll have to code something to detect earlier, probably on populating the download list, just for those occasions where I have PC Shutdown activated, and automation should not be held up. Currently I have a manual setting to cater, but the user needs to know when to set it.

And now for something strange ... at least it seems that way to me.

I'm only aware of GOG using two file types for Mac versions of their games - DMG and PKG.

I'm not a Mac user either, so have very little Mac knowledge.

Anyway, I implemented some new code for detecting files with a missing checksum, and the very next game I updated the manifest for, gave me the following weird seeming results, and four missing checksum values. Those funny looking file names (GameData_1_aa etc) also occurred when downloading directly via browser links.

It looks like some kind of error to me, especially as Part 1 is 11.6 GB and at odds with the next two parts. Anyway, it is the first time I have come across anything like this.

The single updated Linux file by comparison is very much bigger, at 19.73 GB, and does have a checksum value.

Installers should always have a checksum (even if it means having the workaround applied to them), unless the gog api is treating them like extras for some reason (the way gogcli currently differentiates are that extras return a 403/404 on the xml metadata path if I recall while installers with bad checksums will return something different and invalid).

I'm currently in Japan for 5 weeks visiting my inlaws and not on the computer a lot, but I'll look when I can.

However, if gog doesn't provide a checksum, no rectification on my end will make it so. The main thing I'd do is make sure it behave like other installers with a bad checksum: Either return an error or apply the workaround (ie, mock download the installer to get the checksum which will be verified again for consistency when downloading to storage) depending on what the end-user specifies in the command's flags.

Enjoy your family holiday. :)

Yep, clearly an empty checksum return is not seen as invalid, so I have now catered for that with my GUI, and while I know that your work-around could help, it doesn't for me and might confuse a user of my GUI, if they don't understand all the ins and outs, so I have opted for using a 7-Zip test instead, and if that is successful, then if desired a checksum value is also created. But that only currently applies to Mac and Linux installer files. If a Windows installer file is missing a checksum, then I recommend using InnoExtract to test the file, or my GOGPlus Download Checker program, which uses InnoExtract or UnRAR or 7-Zip.

Alas InnoExtract testing is much slower than just using the API provided checksum, and in the case where you have one file only, without a checksum, out of several linked installer files, the whole lot is tested, which could result in a very long test, hours potentially, depending on the PC and total game files size.

Still, with the crappy download speed I get with GOG (Fastly CDN), we could be talking a long time anyway to secretly download an installer file without a checksum, to compute one. A 10 GB Linux file for instance would take most of the day to download with gogcli, and no guarantee it is okay. In fact, I would be better off downloading such files myself twice using the faster downloading options I have access to (i.e. aria2 or FDM5 with curl), and then comparing them.

The good thing about using InnoExtract etc, is that that can occur after the fact, when all downloading is done. I haven't implemented it in my GUI, because of the complexity involved, where it might be just one BIN file or the EXE that is missing a checksum. InnoExtract, as far as I am aware checks all or none. So with 20 linked installer files for instance, you can just imagine how many hours of testing could be involved.

UnRAR (or 7-Zip) can usually check a single BIN file, and 7-Zip an EXE file.

GOGPlus Download Checker cannot currently be forced to check an EXE file with 7-Zip. It will only do that, if the EXE file is not recognized as an InnoExtract one. I could cater for that, but I am yet to come across a scenario, where the EXE is missing a checksum value but any linked BIN files do have checksums. The first time that ever happens, I will of course modify my GOGPlus Download Checker program.

P.S. Of course, I am usually not relying just on 7-Zip testing for this rare instance of a missing checksum, as we are also using a bytes check for the file. So long as the bytes value isn't also missing, we should be good.

P.S.S. While my GUI uses the 7-Zip test by default, the user can opt for your work-around method instead, via program settings. I do present my reasoning not to, but if the user understands the situation and has a good download speed with gogcli, then I don't prevent that.

Never say never.

I had a spare moment today and felt motivated enough, so implemented what might be a never used feature into my GOGPlus Download Checker program.

I've added a checkbox at the bottom of my floating dropbox, that indicates an EXE file should be tested with 7-Zip rather than InnoExtract, so tested independently of any linked BIN files.

If you isolate the EXE file from linked BIN files, InnoExtract will spit the dummy, if you try to test with it.
7-Zip however doesn't know about linked BIN files, and is quite happy, with the right parameter, to test an InnoSetup created EXE file on its own, and it works well.

Of course this new feature is only useful, where the EXE file is missing a checksum value, but linked BIN files have a checksum value. I've never seen that happen, so pretty rare, but I guess it's possible.