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.

Hello Magnitus.

My GUI keeps tabs on newly added games to my games list at GOG. It does that in a text file, which then allows me to step through the list in my GUI with a LAST button, starting with the most recent addition first, then working backwards toward the oldest addition.

Sometimes an older game name will appear as the most recent addition. This can occur for one of two reasons. Either the game has been renamed, which happens now and then, or the game ID has changed. I'm not really keeping tabs on the latter of those two instances, expecting I guess that the game ID shouldn't change.

My checking relies on a Game Title and Game ID combo, checking my existing manifest records.

Just now I bought three new games, and they should have been the most recent additions to my list or pretty close to that if a game or three had been renamed as well.

But for the first time, I've ended up with a lot of my older game names as the most recent additions to my list, so those three new games are buried quite a ways back.

THE FOLLOWING NO LONGER APPLIES AS I HAVE DISCOVERED WHAT HAPPENED. See the end of this post.

I've checked some of them, and found duplicate names in my list, and that would be an indicator that the Game ID for that game has changed.

There is also many old game names that predate when I first started my 'Added.txt' list file. That would also seem to indicate that either the game title or game ID has changed for those games, and I suspect it is game ID.

Have you or anyone else noticed this or been suspicious of it?

Here's my list. The first three (in bold) are my recent purchases. I've not included entries before them, but as you can see there is quite a few new entries after them, though some of those also exist earlier on the list, so are duplicates. I don't imagine that many games have been renamed since my last update a few days ago, so it would seem the game IDs have changed, as the likely reason.

That said, note how the list is alphabetical and that it starts with a 'W' and no lesser leading alphabet character before that. Hence my concern that something possibly isn't quite right.

With that last issue in mind, I am wondering if the issue might be missing Game IDs instead, possibly in the return from the following command. EDIT - This would have no impact I have now realized, as the entries being checked are pipe separated, so a blank ID would just means a match of the title alone.

gogcli.exe -c Cookie.txt gog-api owned-games -p=23

Page 23 being the last page of my games list, which as I recall is alphanumeric based, and so the 'W' entries would likely be on that page or start on Page 22.

WHAT ACTUALLY HAPPENED

Luckily, my GUI creates backups of the files it updates/creates.
Checking those, I discovered an oddity.
My previous update of my games list, resulted in a slightly smaller file ... 76 KB instead of 80 KB.
No idea why that happened, unless there was a glitch at the GOG end.
So also checking the backed up source files, I saw another discrepancy ... 1,196 KB instead of about 1,253 KB.
Examining that smaller file, I see the the content of Page 22 of my games, is missing.

So that explains what happened, and it resulted in my updated games list missing titles, that when checked next time around, meant older listings (from Page 22) were seen as new ones (purchases).

This has never happened for me before, and I hope it doesn't happen again.

It was certainly an oddity, especially as Page 22 data has almost the correct header ... except note the TotalPages of 8 though, which should be 23. All the other pages state 23, including Page 23.

Page: 22
TotalPages: 8
ProductsPerPage: 100
Products:

Just that no games were listed.

So surely this was a glitch at the GOG end, especially as Page 23 was fine.

NOTE - It was somewhere around this time frame (just after), that I got a download error, and appeared to need to update my cookie file. Certainly doing that overcame the download failures. So maybe that had a bearing, somehow ... though that doesn't seem logical, due to Page 23 being fine.
.
Anyway an interesting one for the record.

In regards to that last post above.

Generally I keep tabs on the number of my game titles whenever I do a GET ... update my list of games. But because it takes a while, I usually get up and make a cuppa etc, then come back to a finished process.

Usually it is the last two numbers of the game title count on my GUI, that I am really paying attention to, so if it goes up by the expected number all seems okay.

In this instance, that would have happened, but because a whole page's worth of games was missing it would have resulted in there being 100 games less, and I guess that skipped my notice, especially when dealing with over 2,000 entries in my GOG library. So 2,133 instead of 2,233 did not register with my brain it seems.

In any case, with my latest update, a dialog now pops up after the GET process, showing the Before and After count, and provides some instruction etc, for if the after count is less.

Basically, I recommend running GET again, and manually editing (removing) incorrect entries in the 'Added.txt' file.