One nice non-critical feature would be the estimation of the remaining download time, especially for these cases where you have lots to download.

Since the script already tracks the download speed and the remaining amount of data to be downloaded, I presume it would be pretty easy to add, maybe calculated against the average download speed over a longer time...

So this is a relatively new thing:

It appears that GOG is now sometimes silently changing existing patch files reasonably frequently, this can result in orphaning failing on Windows due to the destination file already existing (this hasn't been a problem in the past because chances are you'd nuke your orphaned files long before this happened).

Thoughts on appropriate actions ? Deleting the older orphan ? Sequentially renaming the existing orphan (to something like filename _old1 ,_old2 ,_old3 etc with the largest number being the oldest ), renaming the new orphan (to something like filename (1) , (2) , (3) with the highest number being the newest) ?

For those wondering: Yeah something is broken with the exanima windows installer at the moment. The XML for the md5 chunks and the data being sent from the server are different. It's not you. Hopefully GOG fixes it soon.

Uh.. doesn't the filename include a different version number?
I think it's better to delete obsolete files.. why keeping them around?

Sometimes people want to keep some older files around, could be a number of reasons, e.g. the old version being better in some way, like some easter egg thingie missing from the newest, ScummVM-based, version of Riven; that is why I've kept the old CD and DVD versions (GOG installers) around as well.

I personally do it manually, ie. if I detect some "orphaned" GOG file I want to keep, I just rename that whole game subfolder under the !oprhaned directory, like adding _KEEP_ in front of the game installer folder name, just to remind myself not the delete it from the !oprhaned directory (and the leading "_" also makes sure those directories are first on the list by default).

Dunno how the script should handle it, frankly all the renaming suggestions from kalanyr sound fine to me. Maybe just adding that _(n) at the end of the filename is the easiest to make? With the other suggestions, I presume the script would have to keep renaming the older orphaned files too, not just the newest orphaned file?

Well, I thought the whole point of !orphaned is to keep all your old (obsolete) files, until you decide to remove either some or all of them manually. That is why it was originally designed to move the orphaned files to a separate directory, and not just outright deleting them.

It would be a principle change that the script would start to automatically delete some older files (because they happen to have the same filename as another old file), without the user even realizing it.

You could just append ISO 8601 datetime string to filename.
That way there's no need to check for old files to determine the new number to append.
I use that for lgogdownloader.
https://github.com/Sude-/lgogdownloader/blob/9804215/src/downloader.cpp#L2745-L2754
It appends ".iso_8601_datetime.old" to filename where iso_8601_datetime is in format YYYYMMDDTHHMMSS (T is date-time separator).

I guess something like this should work
newfilename = '{}.{}.old'.format(oldfilename, datetime.datetime.now().strftime("%Y%m%dT%H%M%S"))

Who knows if this would extend to other installer files at some point as well. For now GOG has kept some kind of version numbering in the filenames, but it is plausible to think that at some point they decide not to do that anymore, but each installer would have only one filename which doesn't change even if the version changes.

The point of orphaning (at least for me) is to keep things temporarily while you verify that you haven't lost anything (eg if a new file on GOG is broken in someway or if an extra is removed or if a new way of doing emulated games changes stuff, you can then resolve the issue by moving the orphan into a subdirectory of the original game). It's not really intended to store stuff for long periods of time (which is just a monumental waste of space).

How many times has gog actually removed something, though? Not saying it won't happen or something, but i'm curious if i should be a bit more conservative with my orphans.

Actually deliberately removing something is very rare (sometimes manuals are removed but that's usually in the case of games that are undergoing development and the manual has become hilarious outdated and thus harmful). Sometimes soundtracks change format (I admit to not having checked if it's ever been to an objectively worse format) as do images (such as wallpaper). Sometimes a different version of a game is used which may have pros / cons (GOG *usually* preserves the previous version as an extra in cases where there is a loss but sometimes they don't realize. They'd probably fix it if notified. Someone who does follow that should probably make a list and send an email. ).

Breaking stuff by accident (bad installers, broken links, etc) is reasonably common, and seems to happen probably a couple of times a month in a collection the size of mine. This generally just requires holding on to the previous version of the file set in question until it's fixed.

Fair enough: It seems to be getting worse and worse. I'm suspecting hardware issues that aren't getting fixed. A few weeks ago, it was the OST of crypt of the necrodancer.

Yeah, but even then, if the script would automatically delete/overwrite stuff (just because they happen to use the same filename) without user's content, then the user wouldn't necessarily have the ability to check if he wants to keep the older file (and remember to move it outside of the !orphaned directory, before running clean again).

To me sude's suggestion actually sounds quite good, time-stamped filenames.

Hmmm.

Seems like a bunch of Galaxy Intallers (in English) and some very old patches have failed to be uploaded are are 404ing when you update. This probably bothers no one since Galaxy installers are only useful if you're some kind of every version of a piece of software archiver and the missing patches are super out of date (like 1.4 - 1.60 for Starpoint Gemini Warlords which is currently at version ~2.20).

But noting here for anyone who is having issues and wants to know if its gogrepo (it's not , they are just missing on GOG.com).

Sidenote: I think I need to rethink how clean works. Clean as it currently works is well suited to be run after a Download / Before a verify but not really After an Update / Before a download, where you may want to keep a mismatched file because it's similar enough to the replacement file that the MD5 resume function would actually patch it quickly (though in such cases you may still want a preserved *copy* (rather than it moved preemptively) in case the new file is broken.

Sidenote2: This is becoming sufficiently complex I should probably look at some kind of default command that does the stuff a normal user would expect automatically with maybe some basic prompts.

ETA -
If you have Exanima (Windows , English) be aware that while GOG has fixed the installer issue this week, they also silently altered the base exe file, while not changing name / file size. This will be caught when verifying (because MD5) but not when cleaning (because MD5 hashing is prohibitively expensive on large collections which have not had a full verification being done*), so you may want to preemptively delete that file yourself.

*it can take over a day to do a first pass verification on a big collection.

I may consider adding a switch you can enable that will clean based on MD5s that are known to have changed since the last verification of the file to avoid this situation (though it's rare).