Windows 7
GIMP 2.8.10
G'MIC 1.6.0.0 for Win 64-bit

This morning my GIMP was running perfectly, but like an idiot I clicked that innocent-looking "update filters" button and G'MIC reverted to 45 filters (not 390-some).

I grabbed the current 64-bit Windows compile from sourceforge, but after installing it I still had 45 filters (and yes I tried "update filters" again).

Next I tried the sourceforge 32-bit installer. I got the "unable to start correctly" error at GIMP startup, and now I have no G'MIC at all.

Then I went into my Downloads folder and found a month-old Win-64 zip and tried to re-install it. Now I am missing a .dll file and still no G'MIC, although perhaps this is progress.

What happened to G'MIC? Do I have to enter the minefield that is GIMP 2.8.14 (or 15)? When, oh when will I learn never to update G'MIC filters?

Thanks for your help. Is anyone else experiencing a problem with the G'MIC filter update?

Thanks, good point about online G'MIC (I need to try that sometime). I just did a system restore which brought G'MIC 1.6.0.0 back in all its 64-filter glory (thanks to Sallyanne who mentioned this on another thread as a last-ditch way to fix a broken GIMP). Tried another "update filters" and this time it restored all the missing filters and everything seems to be in good working order again.



Was my timing bad, clicking "update" at the exact instant someone was uploading new code?

For future reference, and I've asked this before but nobody seems to know: Is there a way to undo the "update filters" click? Is there a file we can backup beforehand, just in case? Because "update filters" is a great thing to do... except once in a while when it goes spectacularly bad. Never a dull moment, eh?

Not strictly on topic, but I've just realized my entire lifetime GIMP experience is an endlessly repeating cycle of

Well, that is very strange indeed.
I've just tried and the update run well. I would be really interested to see the content of your update1601.gmic (or update1600.gmic) located in %APPDATA%.

I've uploaded my most recent update file here: https://dl.dropboxusercontent.com/u/151 ... e1600.gmic

However, this is the file I downloaded after the system restore and after I hit "update filters" again. This version works ok. My previous update file (1590) is from 8/21. I no longer have this morning's problematic file -- either System Restore deleted it, or it was overwritten by my last "update filters" command.

My gmic update files are not located in AppData. I'm running samj's portable GIMP, and I found the files in the directory: gimp_2_8_10-64bit_portable/GMIC_Filters
Maybe directory location is part of the problem?

That is very helpful advice about the update files. Thanks.

Bit late in the day for computer forensics, but I enjoy the sport; that's why I like to code software bugs, so I can stay up until the wee hours trying to figure out exactly what I did and spend the rest of the day with my mouth tasting of sand.


This issue is pretty easy to emulate. In this case, I just arbitrarily deleted about two thirds of my update file. My conjecture is that Acmespace's internet connection burped at an inopportune time and a partial download was obtained. [Well, yes, but it comes down the wire as a compressed file and should it be partially truncated, decompression would reject the entire download. If the file was damaged, still a possibility, some other mechanism would have to be found - GRO] The Gimp-G'MIC plug-in reads updateXXXX.gmic whenever it starts and posts what it finds in the way of filters. There is no "global file integrity checking" that I'm aware of; G'MIC parses filter definitions as it finds them, atomically, and posts those that seem complete. If only about a third or half of the file finds its way to disk, then that's the gmic definitions toward the front of the file and maybe forty or fifty or so gimp filters. And, if on waking up, the Gimp-G'MIC filter finds only forty or fifty filters in updateXXXX.gmic, well then, that's all there is.
It's a pity that events like these leave people chary about hitting the update button. That means missing out on new toys, especially since it is becoming my wont to throw new toys into the pot now and again. Could it be that no one here has blurred-by-color for fear that hitting the update button will induce a re-install of Windows? Heaven forefend.
I wonder if it would be useful to educate -_update about -file_mv? Perhaps, before grabbing the latest and greatest, -_update does '-file_mv update@..gmic,lastupdate@..gmic' or some such. This doesn't solve the partial download problem, but if someone in userland notices a dramatic change in filter counts, or discover broken filters that they really-really need, they'll have a backup to which they may revert. I suppose this suggests a counterclockwise button which removes (assumed broken) latest and greatest update files and un-renames lastupdate... back to update (if the backup update file exists).

Hello Grosood, thanks for the detective work. Love that image you're editing: *!!!* pretty much sums up my initial reaction.

Bugs do brighten up a dull day and give us something to do in those wasted overnight sleep hours, don't they? I am not a programmer, but I am a tech writer (which is akin to saying I am not a doctor, but I play one on TV.)

My list of filters looked different from yours. I had all the categories down through "Testing" -- but it was the old categories from many versions ago. Within the categories, only a few filters appeared. I figured it might have something to do with filters that use certain commands, but I am woefully unknowledgeable about this. Or it was just an old file posted in the wrong place on sourceforge. I should have taken screenshots.

My first reaction was to hit the "update" button again, but I got the same result. Is there a check that prevents G'MIC from re-downloading the same update file? Because if it were a one-time download burp, then I would think hitting "update" again would initiate a second download attempt, and how likely is it to get the same burp at the same point?

Great idea to give users an update backup and the option to easily revert if something goes haywire. The "Undo" button is history's greatest advance in user interface design.

Hm. Hmph. Hummm.
Seems that, for a while at any rate, you were running off of an antique update file. That would explain old categories, but not quite a filter count as low as forty five; It seems on day one there were around a hundred. I don't think the count was ever as low as forty five. That suggest an antique file which was also incomplete - an anomality indeed.

Only fools believe in foolproof, but as you may have gathered from my previous post, I've backed away from the idea of 'transmission burps.' It goes down the wire as a compressed zip file, which is just as valuable as an integrity checking tool as it is a traffic minimizer. Once the unzipper on your computer notices that its computed CRC differs from what sender computed, it declares failure and that is that. So, updateXXXX.gmic either arrives whole and sane or it doesn't arrive at all. There is a vanishingly small chance of a corrupt file getting through the gamut, but I'm rather more inclined to bet that the next Pope is Protestant.

There is the thought that maybe somebody momentarily put the wrong file on the server, and before they went OOPS! and put the right file on the server, you timed your update to get a broken file. Well, there's certainly a possibility of that -- far more likely than an Episcopalian Pontiff -- but still, I think, with a probability in the range of a fraction of a percentage. I base this on the fact that updateXXXX.gmic is built by scripted automation, and while it may have started out life buggy, that was a few years ago. Its obvious gaffs were observed and fixed a long time ago, and that leaves the not-so-obvious gaffs which don't happen that often. I suppose that's why it is a pity that no one had a chance to look into the update file which gave you such a curious result. I'm sure there was a story in there to be told. But it's gone and you can't be blamed for deleting it, since getting rid of a (possibly corrupt) filter definition file is probably a good first step toward getting Gimp and G'MIC back on track. If all else fails - Internet connection, update file integrity - there are built into the gmic-gimp plug-in a text section that contains the filter definitions that were extant when the plug-in was compiled. They're not the most current, but they work, and if, in start up, the plugin can't find a filter definition file anywhere, those are the filters which populate the tree. That's why a freshly installed gmic-gimp plugin has filter definitions before the first refresh request happens.

So we'll probably never know why you only had forty five filters that day. Maybe if lightning strikes again - you or somebody else - that the weird update file gets saved for forensics. One fear that I hope to dispel is this especially pernicious one about never -- never -- hitting the Refresh button. If that gains a common currency (and I fear it has gained a common currency), then the newer, more experimental filters never get tried out. And that stymies G'MIC's growth.

Now, I can appreciate the fact that when one has all of the pieces working together - Gimp, G'MIC, scripts, plug-ins - one can be especially chary about doing anything that brings the whole house down. That said, the aggregate effect of Gimp-G'MIC becoming frozen on peoples' machines is that the New Stuff doesn't get exercised. Put another way, the New Stuff doesn't get a chance to bring the whole house down. Now how can those of us who fix stuff can ever fix stuff without forensics? There is a price to Free and Open Source Software -- it just isn't monetized. The price you pay is the cost of taking a risk -- hitting the Refresh button -- and having the whole house come down. And, after the smoke clears, then paying the price of time and getting on Gimp-Chat or whever else the Gimp-G'MIC communities intersects and saying what happened and going though the cycle that you so elegantly illustrated: -- the debugging process. As unpleasant as it may seem at the time, it is as vital a contribution to the open source community as anything else, because it forges the New Stuff into Good Stuff.

So whatever else you do, hit the Refresh button - then duck.

GRO

Thanks, GRO. I will certainly keep hitting the update button... and installing beta builds and all that other fun disaster-prone stuff. But I do think it's best to wait until an afternoon when I'm not busy on deadline!

Some folks enjoy a little adventure with their software. I think most of us here on Gimp Chat do. Most users don't, however. It is an interesting question what the GIMP and G'MIC communities can do to help them.

A way to lock the current GIMP install, or back it up for easy reversion, would help a lot. It takes only a few minutes to install an update... and sometimes it takes all day to correct the damage. I swear, those missing .dll files will be the death of me.

Most of the time you will find it isn't a missing DLL file. Usually it is a duplicate DLL file. GIMP has all the DLL files it needs to run in it's "bin" folder located in the main program directory.
GIMP will see any duplicate DLL files and count both as absent. Thus the error dialog window "missing dll file"

Running a search in the user/.gimp-2.8/plug-ins folder will normally find the duplicate DLL. Most of the time these are downloaded with other plug-ins. However sometimes a duplicate will be placed (or installed) into the main lib/gimp/2.0/plug-ins directory. Simply re naming these duplicates will remove the error in most cases.