Good to know, thanks for the explanation.

Update #2: I continued testing the games that had XML failures on a daily basis. After more than two weeks, of the 16 games that had failures for me, 12 "corrected" themselves, 4 not yet.

Hi. I got some messages that files are orphaned. But they shouldn't have been as they are genuine game files that are listed on GOG web page for download and not some old games files that were later updated:
19:39:51 | orphaning file 'gabriel_knight_2_the_beast_within\setup_gabriel_knight_2_-_the_beast_within_1.1_(20239)-1.bin'
19:39:52 | orphaning file 'il_2_sturmovik_1946\setup_il-2_sturmovik_1946_4.10m_(14392).exe'
19:39:52 | orphaning file 'il_2_sturmovik_1946\setup_il-2_sturmovik_1946_4.13.4m_(14395)-2.bin'
I do not think this is a gogrepo.py problem, because only some of the game files (for example 2nd file of 3 files; always the same files on multiple tries) are moved to orphaned. But I have nowhere else to report the problem so I am writing it here.
Best regards, D.

Thanks Kalanyr for all of your great work! No need to dig up the script. The "dryrun" mode of the "download" command was sufficient to give me the main thing I was looking for - the total size of my library.

Fortunately, my library was small enough to fit on the spare hard drive I had, as long as I limited the content to English, Windows, non-galaxy installers.

I was successfully able to perform the download. I ran into some sort of issue about a quarter of the way through where the download process stopped (wasn't making progress). However, I ran the command again, and it was able to continue without having to start all over, and ran for many hours uninterrupted until completion. I had set my Windows power settings to NOT put my computer to sleep beforehand.

Thanks once again!

Hi Kalanyr,

Thank you for your great work, really appreciated!
I have a feature request to create a switch / switches that will allow only single architecture downloads, e.g.: -singlearch_prefer_x86 and -singlearch_prefer_x64
- or -
-singlearch with -preferx64 (default) and -preferx86.

I think these are self explanatory, but just in case:
I'd like gogrepo to avoid downloading both x64 and x86 installers - I prefer x64 only (Win7 fan here), but just to make this tool versatile it would be nice to also have x86 preference option (for XP lovers, I guess).

BTW is there a way to donate?

Cheers!

I'm not sure if Gog can differentiate them in the xml.
Btw I avoid duplicate 32bit versions with this:
-skipfiles setup_*_32_* setup_*_(32bit)*

Yeah, you're correct. GOG doesn't flag these, you have to use heuristics like these (I wouldn't necessarily recommend that first one as something you use passively (it may catch some build identifiers) but the second one should be fine 99.9% of the time).

Update #3: I continued testing the games that had XML failures on a daily basis. After more than three weeks, of the 16 games that had failures for me, 13 "corrected" themselves, 3 not yet.

Many thanks for the link. This thread is imposing enough without searching the whole thing to try and find the "current state" (I've no idea what happened to the OP).

Hmm... interesting. A definite Windows user here and not a Python guru, but... with 288 games on GOG this could be quite interesting indeed!

Thanks also to Kalanyr, of course, for forking and updating from the original gogrepoc

Thank you phaolo, very good idea indeed! I have manually confirmed that both these filters match what I needed from my 825 games sample.
That being said, I also realized that these files constitute only 48 GB out of my 2,58 TB collection, so I gave the idea up entirely - just in case anyone else is concerned about it.

If I understood the discussion right, there are issues with various installers to get valid md5 checksums from GOG servers, which are needed for e.g. verifying your GOG installers (with "gogrepoc.py verify")?

Has anyone yet tried to verify their GOG installer collection by using innoextract? By experimenting with it yesterday, all that is apparently needed is that all the .exe files in your GOG collection are tested with "innoextract -t 'the_name_of_the_installer_or_patch_file.exe'. If it doesn't give an error, then that installer/patch file (the .exe file and related .bin files) are fine.

That way one doesn't have to rely on GOG's md5 checksums which may or may not be valid or exist at all, at least for the verification.

I think I have both a bash script (for Linux) and a bat file (for Windows) for recursively doing such verification of .zip files in all subdirectories, I think those scripts should work the same for testing the installers (using innoextract)...

I tested it yesterday manually by both deleting one of the .bin files, and flipping one bit on either the .exe file or one of the .bin files, and in both cases innoextract seemed to give a clear error. I don't think it points out which .bin or .exe file exactly is faulty though, that you have to find out some other way, but at least you find out which installer is not working.

Yes, I tried and it works . But innoextract is slow as molasses and I can not recommend to use it for verification.

It's open source so I can have a look at least, maybe I can reimplement it's checking. It's still only a solution for Windows though, but Linux / Mac wouldn't be worse off.

Yes, only Windows installers use innoextract, though the tool itself runs on Linux it seems (if you want to manage the backup of all your installers including windows ones from a Linux box): https://constexpr.org/innoextract/