Ahh, yes. There's an error where uncompleted downloads are moved despite the message saying they aren't. I'll fix that and upload a fix soon.

Fix uploaded now. That actually revises my heuristics false positive rate to 0 since the one I encountered was a result of this bug negating the heuristic completely.

Thanks for that report. It went unnoticed before since the error message for the result had a typo and the error that resulted stopped this bug, when I recently encountered and fixed that error it caused this one to manifest.

I also do really strongly recommend using verify and after the initial thorough scan it's pretty fast. It catches things like this since the pre-allocated file will fail the md5 verification (for obvious reasons).

PS - You need to update kingdom_come_deliverance before you redownload it, the manifest / xml mismatch either means there's an error on GOG.com or your manifest entries are outdated for that game (the xml for doing download resumes is downloaded fresh for each download and it's saying your manifest file size is wrong).

As a headsup for those who have their own scripts

The next build will go back to doing everything in the manifest for download/import/backup wrt to lang/os. This is to restore some older backwards compatability.

However the following two things will break backwards compatibility but I think the benefits are worth it.

The uodate default will also make a guess at your OS and Language are rather than defaulting to Windows/ English , so if your system OS / Language differ from Windows/English and those are what you want to download you should be prepared to adjust appropriately. The default language if everything falls through will still be English but the default OS will be linux (since I figure if python can't accurately detect your OS chances are it's a weird POSIX compatible distro of some kind and Linux is your best bet).

And I'll probably be implementing the previously mentioned defaults for updates as well (defaulting to a combo of update / skipknown and having a gamecheck command) in order to soften the load on the GOG servers (it will still do a full update if no manifest exists of course). The full update will still be available it just won't be the default.

I'm also considering adding a config file where you can set your defaults for OS / Lang / Installers and maybe some other stuff.

I won't officially release this version until I've updated the readme though. It's just part of the few bits and pieces I needed to clean up.

I may release it as a test stream, after I make a dev repo branch so I can do a built in updater for GOGrepo.

I tried to duplicate this error in order to fix it but I can't. Could you verify that it still happens on the latest version of gogrepo and if it does let me know the exact command you're using and what commands you used to create your manifest.

It doesn't look like this error is a result of having filtered manifest content to zero (which would result in an empty work queue and terminate before calling any workers) , rather it looks like the page object has no context-range entry in it's header.

It's hard to diagnose this further without info from a later version since the use of the requests module has actually replaced the code in question. Especially since this outcome should be impossible using requests as it should error out safely before this happens.

For those feeling daring, the dev branch can be found here:

https://github.com/Kalanyr/gogrepo/tree/dev

I recommend checking the commits for details at the moment. I'll update the readme eventually but that will likely be the last thing I do before I roll to the master branch , since it doesn't make sense to update it until things are fairly solid.

Edit - I'll see about adding the built in updater for my next trick.

Is anyone familiar with how to prevent system suspend until a script is complete on Mac / Linux from Python ?

I've got a method for Windows which is pretty ugly but the methods I've seen for Linux/Mac are even uglier.

What ugly trick are you using at the moment? O_o'

Btw, I don't know much about python, but I searched in Google and found this page (with also a solution for Linux?):
http://trialstravails.blogspot.it/2017/03/preventing-windows-os-from-sleeping.html

Otherwise this for Linux:
https://stackoverflow.com/questions/14854131/how-can-i-prevent-system-from-suspending-locking-python-c-bash

And for Mac:
https://stackoverflow.com/questions/14215960/prevent-os-x-from-going-to-sleep-with-python

You will have to judge all these yourself, though..

The Linux solution replies on DBus, and a python library and binding that isn't always present (the dbus python module is also outdated and pydbus is preferred). This was the best solution I came up with in my searching as well (apart from the tweaks to use the new module), I think all I can really do here is make a good faith attempt to do power management , list pydbus as an optional requirement for Linux power management and let people sort it out for themselves otherwise. None of this likely works on eg FreeBSD or other BSD derivatives because it all implicitly relies on systemd.

Mac requires running a subprocess to run caffeinate and then terminating it at the end.

Windows requires using the Win32 API from ctypes , and the way Microsoft treats SetThreadExecutionState has been wildly inconsistent over the last 2 years , though it seems to be behaving as a sane person would expect at the moment (which is nice).

And of course pydbus is not yet compete and can't handle the current way of doing system level inhibit locks meaning I need to use python-dbus (which will be obsoleted eventually) because of course it is. Sometimes *nix makes me want to hurt things.

ETA - I'm seriously thinking about just faking keyboard input in a loop.

ETA - I could also use pyQT or GLib and the python object bindings.

Does anyone who uses *nix in an environment where suspend is likely to matter have much of an opinion on the cost of installing the additional stuff ?

(Remote shell servers and such usually don't suspend , so this isn't an issue for those. I assume since no one has mentioned problems that's the case for most linux users. But I'm guessing someone must be using this for management on a desktop/laptop. )

ETA again - I apologize for the venting on this. Should be mostly done with now. This was just supposed to be a bit of cleanup to remove gogrepoawake.py and then I figured for consistency it should handle suspend on Linux / Mac too then I descended into Linux power management hell.

Mm.. that's dangerous.. please, check that the script terminal is on focus every time. O_o
And\or maybe find some harmless button to press every 10 mins like.. uh.. Num Lock?
Could you add this only as an option, anyway?

No problem about the venting, we can understand the frustration :P

I'm going to do my best to find a proper solution first. And yeah if I did keyboard presses or mouse wiggle I'd make that optional. I was just frustrated by how difficult it is to something simple like "don't suspend the computer until this program is done" in a cross platform fashion.

I'm looking to rename the fork to go with the new thread. Anyone have any name suggestions ? I want something simple and that acknowledges wooly's gogrepo as it's origin. I'm thinking of gogrepo gamma (for community) but if someone has a better suggestion I'm listening.

Dunno.. gogrepo 2 or gogrepo K.
lol

gog-repo v2.0 - definitive edition :D