View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005515||SUMo||Bug||public||2019-05-30 11:16||2019-08-15 12:07|
|OS||Windows 10||OS Version||1809|
|Target Version||5.9.6||Fixed in Version||5.9.6|
|Summary||0005515: ImageMagick detection and current determination|
|Description||SUMo detection of ImageMagick (64 bit) detection seems randomly. While it was working deterministic and correct on all my Windows operating systems (Windows 7 and 10), it suddenly isn't detected correctly on my most used device with Windows 10. SUMo still detects the GUI (IMDisplay) of ImageMagic while no longer detecting ImageMagick itself, see attached screenshot of SUMo.|
While I got some issues with starting some programs off the start menu probably due to some too radical cleaner program, I don't have that issue with ImageMagick. It still can be started on that device via start menu. When asking ImageMagick its version via GUI, it provides the version of the GUI and of ImageMagick itself. It's not an error of SUMo of reporting it differently as long as refactoring and grouping as of feature request https://www.kcsoftwares.com/bugs/view.php?id=5442 is not yet implemented as the GUI and the main program of ImageMagick are different binaries with different versions. It's known that SUMo usually reports the main program and some of its components. But why does it detect and report only its GUI correctly now and no longer the main program anymore while still working on another device as expected with the same operating system version, same ImageMagick version and 64 bit edition and same SUMo version and (Pro) edition?
(It's both 64 bit edition of Windows 10 on both devices but nevertheless different Windows 10 editions, Home versus Professional.)
A second issue with SUMo detection of ImageMagick I don't understand. On the device working as expected, it determines the local version of ImageMagick correctly (184.108.40.206). and claims availability of an update (to version 220.127.116.11). When looking at SUMo server for this entry, it reports some SUMo users having installed ImageMagick and indicating my version correctly with the user flag. But opposed to SUMo client, SUMo server reported version 18.104.22.168 as current with 50 % having that version installed and NO SUMo user having that update 22.214.171.124 installed although SUMo client has reported as available! (A day later SUMo server reports 25 % having updated to that version now reported.) How may this happen?
Doesn't SUMo design imply that a version of any program can only be reported as available update if any SUMo user has this particular version of that particular program installed and how may it happen that SUMo server doesn't then report that version at all?
While I don't understand the situation of the above sentences, I know that the situation of the 2nd sentence of this paragraph for user and current flag is correct while incorrect and inconsistent for claimed update availability.
When looking around for ImageMagick on SUMo server, another issue can be observed. It seems that more users have the 32 bit edition of ImageMagick installed than the 64 bit edition. It further seems that those SUMo users with the 32 bit edition never get informed about available updates and almost none performs such an update while those of the 64 bit edition get informed and do update. (ImageMagick is updated and released by its publishers more frequently than SUMo.) Hence SUMo server reports more recent versions of the 64 bit edition as current and changes it of time to time while its determination of current of the 32 bit edition doesn't seem to change at all. The publishers release the 32 bit edition and the 64 bit edition at the same time. They're all built in various sub-editions in the same build with different linking and different graphic resolution.
Due to SUMo client reporting an available update of ImageMagick on a properly working small device I verified if an update was really released and available on my larger device where SUMo no longer reports ImageMagick, but still its GUI as installed. And I found that not only version 126.96.36.199 has been released but also versio 188.8.131.52. So I updated on that device to the 64 bit edition of ImageMagick of 184.108.40.206 to 220.127.116.11. Then I queried SUMo again via its check action request if the strange behaviour of SUMo detection of ImageMagick did change. The result is that it still does report the unchanged version of its GUI while still not reporting the changed version of the main program. Consequently, SUMo server has no chance to report that I'm a SUMo user having version 18.104.22.168 installed, still claiming that NO SUMo user has such a version installed!
So I thought that another SUMo scan action followed by a check action might fix this strange behaviour on that device. As shown with the attached screenshot, it didn't change. (SUMo report increased by about 20 components detected to 964 while still detecting the GUI and no main program of ImageMagick.)
|Tags||No tags attached.|
I've to add some clarification. I found out that this random behaviour is a consequence of running SUMo with standard detection configured.
I usually don't run it in that configuration. But due to reinstalling SUMo, I didn't realize that I either forgot to change the SUMo default configuration to my SUMo default configuration on this option or that an autoupdate of version 22.214.171.1240 to 126.96.36.1991 did reset it. So when changing the SUMo configuration to deep detection, SUMo behaviour gets back deterministic. It then automatically updates SUMo server as expected for 64 bit edition of ImageMagick. SUMo server reports the version of ImageMagick detected locally correctly and sets its user flag correctly. So the 1st symptom reported above happens only with SUMo (Pro) set to standard detection!
But what I still don't understand is the behaviour for 32 bit edition of ImageMagick. I didn't install it. All 32 bit editions detected are coming as components of several other applications, none of portable edition. That also explains why the update rate of SUMo users with 32 bit edition of ImageMagick is so slow. The check report of SUMo itself is inconsistant for the 32 bit edition of ImageMagick. And it does not get fixed by changing SUMo configuration option to deep detection. It even gets worse with this configuration option. SUMo server updated the current version determination of version 188.8.131.52 to 184.108.40.206 with 22 % having this version of the 32 bit edition installed. You can see that SUMo client detects FOUR different versions of ImageMagick in 32 bit edition installed. Version 220.127.116.11 is the version that SUMo server claims as current and tags it with user flag while claiming that the other three versions of the 32 bit edition are installed by NO SUMo user! Even worse you see that although SUMo server reports that version as current, SUMo client reports an available update of that very same version 18.104.22.168 to 22.214.171.124. SUMo client does so too for a lower version not installed by ANY SUMo user. SUMo client does further report any version higher than the highest known by SUMo server as up to date although there are TWO different versions installed locally with higher version. And as reported by email, the publisher releases all 32 bit editions and 64 bit editions with the same build and hence with the same version number. The published translates the editions into the installer file name. That means that NO SUMo user has yet updated to the latest release 126.96.36.199. But how does it happen that SUMo client has a different understanding of current version as the SUMo server?
And how does it happen that SUMo client reports different versions as up to date while SUMo server claims that NO SUMo user has these versions installed?
What happened to the screeshots attached to my above note this afternoon?
Why did MantisBT report them as being uploaded while I couldn't find them attached after submit?
So I try again to attach the two screenshots already attached a few minutes ago and refered to in the above note.
||Repeating the above mentioned trial of attaching these screenshots promised a few days later as the previous trials weren't successful.|
And now the new observations with this strange current determination. As already reported, a check operation lasts now between 7 and 9 minutes. When several instances of ImageMagick in several editions are detected, SUMo server doesn't take all of them into account nor SUMo client as you can see with these new attachements.
It seems that SUMo server looses information about installed and detected editions and versions too quickly. I've installed SUMo and ImageMagick on all my Windows devices. That's more than SUMo server knows. Even on this single Windows device, there are is the same number of 64 editions installed as shown by SUMo server and SUMo server doesn't report any SUMo user with the oldest version detected on this device which has even a lower major version number not known by SUMo server!
And the current flag switches too quickly too to a lower version.
I've updated it this morning to the most recent release. The other software products have it as a component and SUMo didn't report that an update of those products already exists (although reporting that for that component an update exists, and to another version as reported as current, why?).
And as you can see on the screenshot too, SUMo client reports having detected the GUI component of this product for which it didn't detect the main component and vice versa detected main component for which it didn't detect its GUI component. Only for the most recent and updated instance of the 64 bit edition, SUMo client detected both components which is stored at standard location. The other locations are either also standard as a side-by-side installation typical for products with such third party components or found via additional folder setting in SUMo (custom folders). Neither of these contexts should affect detection nor reporting nor current determination.
It seems that SUMo server should be more reliable for 32 bit edition as for the 64 bit edition of ImageMagick as it seems that more SUMo users have a 32 bit edition either installed or installed another product with this 32 bit edition found as a component.
If you take a closer look at SUMo server, why should the user count for GUI and main component of 64 bit edition be different with more then twice the count for GUI as for main component?
For the 32 bit edition it detects much more main components as GUI components but the difference isn't that large factor as for the 64 bit edition. The GUI component didn't change version for a long time while the main component changes frequently with short update and release cycles.
And as you may see at the publishers web site, there are many different editions of the main component, not only distinguished by 32 bit and 64 bit edition but also portable and installer edition, statically linked and dynamically linked edition, 8 and 16 bit resolution edition, standard colour and high colour space edition. SUMo doesn't make this distinction, neither on server nor on client side. The installers are different as well as the file size. But version info doesn't reference the edition even not in the original file name attribute. That explains why its not reported as different by SUMo client nor server. That raises the question what is considered a version resp. edition by SUMo as different file sizes should indicate different editions if the version number and release dates are identical.
My assumption on SUMo users having 32-bit edition of ImageMagick installed versus 64-bit edition doesn't seem correct. Now I see the opposite reporting within minutes of SUMo server lookup. And one screenshot shows what the publisher reports as current release which NO SUMo user currently seems to have installed yet.
And I can't find my notes already posted for a proposal how to redesign the SUMo server algorithm for determining the current version. With detected tool ImageMagick you already get these strange behaviours now documented with the new screen shots attached. The screenshots show server lookup about 45 minutes after client check operation on the most populated device.
In order to change of this aleatory SUMo current determination behaviour to a more consistent and reproducible behaviour, you need to fundamentally redesign this algorithm while you may keep your fundamental design decision of using SUMo client data.
ImageMagick gets updates every few weeks. I didn't monitor where this typical update cycle resides between 14 and 28 days. When this update happens, there happens often not just one update but two within few days. With Mozilla FireFox the update cycle is somewhere in the order of two months. Most products have an update cycle of about a year and also a significant number of products of about half a year like Windows 10. If product updates didn't happen for more than 5 years, these products may be considered without active development which may have two distinct meanings (either abandoned resp. [possibly unannounced] EOL [end of life]) or turned into security bug fixes only). Especially the observation on the update policy of ImageMagick may have an impact of some plausability tests of the current determination algorithm of SUMo server. And as this product is open source, the internal algorithm may be strengthened by publisher lookup, still considering your design decision that publisher announcements may be unreliable and outdated (more on roadmap of expected future releases then on already happened releases).
I still don't know the expiration window the SUMo server algorithm currently uses for determination of current version. It is something in the order of some minutes guessing an order of 10 and less than 30. I strongly recommend to increase this order to something in the order of 15 months with at least more than 12.5 months. So this order takes into account usual update cycles of products.
When turning this time window so long, you cannot handle every SUMo client uniformly the same but have to weight their contribution instead and need some adjustements too. Your current weight of older SUMo clients contribution turns of 1 to 0 after those few minutes. With a changed algorithm this should instead decrease logarithmically of 1 to 0 within about 15 months. An alternative idea is to use some other algorithm for observation interval per tool requiring more database resources on server side, determining the usual update cycle of every detected product and using twice that update cycle or 1.9 times that update cycle as duration of interval for logarithmic decrease of SUMo client contribution. The logarithmic decrease corresponds to some determination of active SUMo users, weighting stronger more active users versus less active ones. As far as I understood you, your recommendation is that the SUMo users perform a SUMo check action once per day (hidden into another subject in the forum).
Finally, a revised algorithm for current determination may expire SUMo client contributions more quickly if SUMo server knows that no more contributions resp. updates are to be expected because the SUMo client informed that it is uninstalling.
Such a revised algorithm has to be prepared by another change at SUMo server. Its database may no longer expire its old tool data so quickly but keep it for the duration of the desired new interval, even before changing the productive implementation of the algorithm on server side. You may want to implement a prototype on a third server and compare volatility and results expecting less volatility and more reliable results for much more detected tools with the new algorithm after the length of historic data increases to more than half a year.
And such monitoring may help to decide some other aspects of fine tuning of a redesigned algorithm: There is no requirement that the algorithm be mathematically continuous and uniform. With increasing age of data, there might be downward steps factored in too.
||I don't know what happened to my new screenshots. So I'll try the attachement again.|
magick.20190812.png (365,987 bytes)
||And the attachements of the SUMo server.|
|2019-05-30 11:16||wolf||New Issue|
|2019-05-30 11:16||wolf||File Added: sumo.magick.20190530.png|
|2019-05-30 11:16||wolf||File Added: sumo.srv.magick.20190529.png|
|2019-05-30 11:16||wolf||File Added: sumo.srv.magick.20190530.png|
|2019-05-30 11:16||wolf||File Added: magick.20190530.png|
|2019-05-30 11:55||Kyle_Katarn||Assigned To||=> Kyle_Katarn|
|2019-05-30 11:55||Kyle_Katarn||Status||new => acknowledged|
|2019-05-30 11:55||Kyle_Katarn||Target Version||=> 5.9.2|
|2019-05-30 15:01||Kyle_Katarn||Target Version||5.9.2 => 5.9.3|
|2019-05-30 19:32||wolf||Note Added: 0003413|
|2019-05-30 19:37||wolf||Note Added: 0003414|
|2019-06-08 14:39||Kyle_Katarn||Target Version||5.9.3 => 5.9.4|
|2019-06-11 21:26||wolf||File Added: sumo.magick.20190530.I.png|
|2019-06-11 21:26||wolf||File Added: sumo.srv.magick.20190530.I.png|
|2019-06-11 21:26||wolf||Note Added: 0003476|
|2019-06-11 22:02||Kyle_Katarn||Note Added: 0003477|
|2019-06-11 22:08||wolf||File Added: sumo.magick.20190611.png|
|2019-06-11 22:08||wolf||File Added: sumo.srv.magick.20190611.png|
|2019-06-11 22:08||wolf||File Added: sumo.srv.magick.sum.20190611.png|
|2019-06-11 22:08||wolf||Note Added: 0003478|
|2019-06-26 00:35||Kyle_Katarn||Target Version||5.9.4 => 5.9.5|
|2019-07-26 16:50||Kyle_Katarn||Target Version||5.9.5 => 5.9.6|
|2019-08-12 12:01||wolf||Note Added: 0003667|
|2019-08-12 12:03||wolf||File Added: sumo.magick.20190812.png|
|2019-08-12 12:03||wolf||Note Added: 0003668|
|2019-08-12 12:04||wolf||File Added: magick.20190812.png|
|2019-08-12 12:05||wolf||File Added: sumo.srv.magick.20190812.32.png|
|2019-08-12 12:05||wolf||File Added: sumo.srv.magick.20190812.64.png|
|2019-08-12 12:05||wolf||Note Added: 0003670|
|2019-08-15 12:07||Kyle_Katarn||Status||acknowledged => resolved|
|2019-08-15 12:07||Kyle_Katarn||Resolution||open => fixed|
|2019-08-15 12:07||Kyle_Katarn||Fixed in Version||=> 5.9.6|