I previously wrote a basic command line tool that scans your GOG directory and easily allows you to update MD5 values for your games in an SQLite database file (and check your game collection against the values stored in that database file at a later time).

Mainly did it to proof my collection against future hard disk defects (to easily know if one of my redundant copies is corrupted).

Keeping a single database file updated and distributing it seems more straightforward then keeping single MD5 entries updated in an adhoc manner in a thread.

If there is an interest in this, let me know and I'll update the project I opened for it with a more up to date version.

There is, for 2 reasons.
1) I currently use fciv.exe which stores them in an base64 encoded xml file, which may or may not be ideal.
2) If you can also have the tool print out a text file in the format of GOGWiki's Template:InstallerInfo, it would make updating the wiki much easier, doubly so if you added support for single directories (so one could add the new installer only, and not everything).

Ok. In this case, I'll give the code a refactoring pass, add a facility to output in the wiki format and update the sourceforge project.

Yay! Should you need any test subjects (or volunteers), feel free to PM me (or reply here).

What's the point of MD5s for GOG downloads? It's not like GOG uses mirrors, and if the Downloader uses HTTPS as I assume it does, no need to fear a man-in-the-middle attack.

Are you so worried that GOG site will be hacked and trojans placed in the installers?

2 points.
1) Data corruption prevention. If you have your backup safely stored in the dvd, but the hash isn't what it's supposed to be, something's gone wrong with your backup, and in case of a hdd backup, best to replace the disk.
2) If you are not using a downloader with a hash checking feature, ability to verify that the download is correct.

There was a 3rd, now defunct, which was to see if you had the latest setup, though since all v 2.x installers also include the installer version, this should no longer be a problem.

That is true for installers, but not for bonus content. That's why I list them too in the files in the OP.

Been updating my code on my spare time (basically rewriting it from scratch copy-pasting useful bits from my old code).

I must say I was a bit ashamed of how the original version looked (glad nobody commented on it when I originally released it), but the current version is presentable (not "work of art" presentable mind you, but that's the best current time constraints will allow).

I'm optimistic for a release sometime this week.

Here you go:

http://sourceforge.net/projects/gogdwnmanager

I crammed quite a few commands int here. It almost has everything but the kitchen sink.

I did not test it with Linux yet, but it should work with Linux as well.

I did not yet port the feature to extract GOG soundtracks to your music folder from version 1.5, but I'll get around to it eventually.

I did a cursory round of testing on all the features, but I'm sure there are still a handful of bugs creeping in there somewhere so let me know if you encounter problems.

I'll slowly populate the database info with my games (I have quite a few), but you can do the same (the feature is integrated in the tool and fairly user-friendly, it deduces everything, except the game's title and whether or not it requires a CD-key).

Thank you, grabbed it, will compile it tomorrow. I'll also update my collection tomorrow, and probably get it parsing during the weekend.

It's Python, you don't need to compile it. You can just grab the interpreter and run it ;).

Everything is described in the usage.txt file.

Interpret, compile, same thing :P Getting the code to execute is what I mean, no matter what you call it.

You clearly haven't tried to make enough C/C++ source code projects work to make that claim :P.

Compared to that, interpreted code is a breath of fresh air.

But yes, I get the just of it ;).

True, only C++ I mess with is JA2, and it's still a pain.

But enough derailment, on to updating!

You are very brave to mess with C++ that was probably coded as throwaway code on a deadline.

Wait a bit longer before updating, I'm currently fixing a potential problem where installers with different versions (different file names) might be dubbed to be different games.

Back when I originally coded the tool, installer names were unique and unchanging and as such, a good metric to identify games.

They still are, but I need to factor out the version numbers.