I don't, I just use it to download whatever the latest version is and don't notice or care how it's being done.

Frankly, I would be surprised if someone would want to download (and archive) the Galaxy-stub versions. For what purpose? I didn't even realize gogrepo was trying to get them too, I was in fact happy that by default gogrepo would get only the Galaxy-free versions.

But, let's see if someone still feels they want to get (the now unsupported) Galaxy-embedded versions... :)

I prefer the stand-alone installer only as well.
the galaxy-embeddet installer would be outdatet anyway I dont see any reason at all to keep them

Couldn't agree more.

Might be worth a new thread when you post the first v3 update?

This isn't a codebase change gogrepo has supported both for ages, it's a testing change. It's pretty much just a recommendation that you use Python 3 to run it.

I'll do the new thread when I've finished the basic functionality I want to add (which atm is a command to verify that a game is ready 2 go (IE up to date and verified) to go along with the more server friendly default settings, self-updating (Inc a dev channel), making the default include a full manifest update once a month and maybe the Galaxy API support)

I'l look into that first one. (ETA - checked and fixed locally. Thanks for bringing this to my attenion. )

Verify with clean on fail turned on needs to create an !orphaned directory (I'll make it fail more gracefully if that fails though)* and it of course always requires write access to the folder it's in (to update the verification status in the manifest and possibly for logging if that isn't turned off).

*A quick look suggests that delete on fail also fails gracelessly on non-writeable file systems.

I think the most graceful thing to do is to abort when the situation is detected as someone probably doesn't mean to be using clean / delete on a ro file system.

Edit:
Also nearly all functions will sometimes require write access. GOG sometimes changes their internal names for stuff, and gogrepo will change the local stuff to match, to avoid unnecessary downloads. Update can't do that itself (because it doesn't take the storage directory as an argument), but clean / download / verify may all correct the structure before running to avoid inconsistency. Though I should probably handle that gracefully.

Greetings

I'm very new at using gogrepo python script, i ended up trying it out after getting some corruption on random files on the HDD of my 2.7 Terabyte offline archive of my GOG account.

It is indeed quite an impressive and very useful piece of software, and i plan to maybe use it more in the future to manage my library once it is rebuilt, verified and safe.

I have a few questions and also a few suggestions for improvement as well. Sorry in advance if some of it was adressed within this thread but it is 80 pages sized, and i only have the very unpractical search feature of GOG forum (i am not using Adalia fundamental... maybe another thing i should try to check out someday)
I only checked the syntax help on the github page for available options and features...

Questions first:

1) If you have some older versions files of installers and patches, can you add them to the overall manifest and/or force batch md5/integrity check on them ?

2) When you specify two different languages during manifest building, what happens when the installer file is the exact same for each language ? does it try to download it twice ? or once it checks for it and see an existing version that matches, it doesnt bother ?

(i don't ask for games which have distinct different installers for localized versions though, i will assume it download both)

3) If you launch gogrepo from a folder that contains previously downloaded files (from gog downloader, lets say) will it try to redownload existing files and overwrite them, or will it recognize files that are in the correct folder names structure ? (folder name convention and rules being as unconsistent and very tedious or odd at times, btw...)

sub question on that: will it at least create the !info file in each folder then ?

Improvement suggestions: (aka: "things that gogrepo yet doesn't do and that i really missed so far when using it)

1) Option to ignore x64 or x32 versions of installers (when both distinct versions are available), depending on which one you need for yourself

2) Option to set the number of simultaneous/concurrent file downloads threads (so far it's 4 by default)

3) Option to limit/force the bandwith used for download to a given size, aka download throttle management

4) A way to force file priority for downliading (like "installer files first" or "goodies first")

I apologies in advance, if any of those suggestions are already available then i'd be very happy if someone could tell me the exact syntax for them please...

Thank you in advance, and congrats for the good work so far.

Hi, I just have to ask this: are you using Kalanyr's version?
His fork is the main one now, because the original gogrepo was abandoned.

please, where can i see/check which version i am using then ? is it somewhere in the comments or something like that if i open the script in an editor ?

If you downloaded it from here, it's the old version:
https://github.com/eddie3/gogrepo

Kalanyr's version, instead:
https://github.com/Kalanyr/gogrepoc

I don't know where to check the version, otherwise..

it was from the eddie3 github page i downloaded mine

can i safely assume i can download the other version and execute it from the same folder, and that it will be compatible with the manifest generated by the older version ? or should i have to rebuild the entire manifest ?

Use the dev branch of mine for compatibility with the old manifest, the main branch should be compatible but it currently has some issues with fixes that I haven't rolled to the main build yet.

... and your branch would be the kalanyr link one, right ?

or maybe it would just worth rebuilding the whole manifest from scratch ?