View Issue Details

IDProjectCategoryView StatusLast Update
0005515SUMoBugpublic2019-06-26 00:35
ReporterwolfAssigned ToKyle_Katarn 
PrioritynormalSeverityminorReproducibilityrandom
Status acknowledgedResolutionopen 
PlatformOSWindows 10OS Version1809
Product Version5.9.1 
Target Version5.9.5Fixed in Version 
Summary0005515: ImageMagick detection and current determination
DescriptionSUMo 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 (7.0.8.44). and claims availability of an update (to version 7.0.8.46). 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 7.0.8.37 as current with 50 % having that version installed and NO SUMo user having that update 7.0.8.46 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 7.0.8.46 has been released but also versio 7.0.8.47. So I updated on that device to the 64 bit edition of ImageMagick of 7.0.8.44 to 7.0.8.47. 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 7.0.8.47 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.)
TagsNo tags attached.

Activities

wolf

2019-05-30 11:16

reporter  

sumo.magick.20190530.png (166,142 bytes)
sumo.magick.20190530.png (166,142 bytes)
magick.20190530.png (34,105 bytes)
magick.20190530.png (34,105 bytes)

wolf

2019-05-30 19:32

reporter   ~0003413

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 5.9.0.420 to 5.9.1.421 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 6.8.9.0 to 6.8.8.0 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 6.8.8.0 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 6.8.8.0 to 7.0.8.37. 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 7.0.8.47. 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?

wolf

2019-05-30 19:37

reporter   ~0003414

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.

wolf

2019-06-11 21:26

reporter  

sumo.magick.20190530.I.png (165,314 bytes)
sumo.magick.20190530.I.png (165,314 bytes)

wolf

2019-06-11 21:26

reporter   ~0003476

Repeating the above mentioned trial of attaching these screenshots promised a few days later as the previous trials weren't successful.

Kyle_Katarn

2019-06-11 22:02

administrator   ~0003477

Thanks

wolf

2019-06-11 22:08

reporter  

sumo.magick.20190611.png (185,336 bytes)
sumo.magick.20190611.png (185,336 bytes)

wolf

2019-06-11 22:08

reporter   ~0003478

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.

Issue History

Date Modified Username Field Change
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