Discussion in 'other software & services' started by Kyle_Katarn, Dec 20, 2011.
Is anyone using SUMo in Windows 11 ?
I'm on Win 11 Dev and Sumo seems works perfectly
May I have your SUMo log in debug mode (in PM) ? In particular regarding OS identification (likely identified as Win10 still...)
I hope I have sand you the info you need via PM
Thanks. Bug logged here : https://www.kcsoftwares.com/bugs/view.php?id=6617
Let's continue in PM
Wrong signal for Total Commander:
I' m here Kyle if you need more test on Win11, simply PM me
On my ToDo list for next week.... Thanks for your help (i'll contact you for SURE )
Looks like a leftover from previous version. Right click > Open containing folder on this one to find out the culprit. Let me know if further assistance is needed
You were right. I copied out the license key and the configuration files, plugins, everything that was absolutely necessary and deleted the whole thing and reinstalled it. Now everything is OK. Thank you!
@Kyle_Katarn How do I transfer 1 of my 4 SUMo licenses (all in use) from an old laptop to a new laptop?
On the old one, go to the ?>About menu in SUMo and click on "Remove licence". Then just use the same code on the new laptop
(and nice that I can do this myself using the App)
You're welcome. It's a feature added recently following several user requests. Happy to see that it helps !
I've often notice that SUMo often misses picking up updates during scans or even if checking manually. I.e Filezilla. If you go the the website for that app, the update is listed. Doing another check after visiting the web-page then flags the app as needing an update. What is the cause of this?
Also, Examdiff is no longer listed, just the plugin exe files . You are assuming there is no need to check the app directory if an appinfo.ini is present. Examdiff doesn't have a portable app, so I made my own for it. I can only update the appinfo.ini when I know a new version is available.. This kind of problem will apply to anyone making their own portable app using the portableApps.com format.
First point (Filezilla) : Not aware of this... is it systematic ? Do you have a precise case occuring now ?
Second item : No change on my side... May I have more info ? Regarding the custom paf format, how are you proceeding ? if appinfo.ini is there, does SUMo work well ?
Filezilla and recently Thunderbird portable. Only flags it after visiting the website for that app. It's occasional. Checking for updates doesn't always find any, even when listed as available on the web-page.
If I rename the examdiff appinfo.ini so it's not recognized, Sumo will list the files. If I leave the ini. it will not list them and only the portable app launcher. This is even true for the official portable apps. You seem to be only relying on the .ini which points to the launcher, ignoring the actual app.
1st : Opening the web page forces the server to recompute the current version (which may come from the cache beforehand). This kind of issue should be super rare.... let me know if it happens again and i'll instrument my cache refresh.
2nd : Please give me your exact initial configuration so that I can reproduce here.
As I said, the problem I'm having may happen to any of the official portable apps if the .ini doesn't get updated . Download Firefox portable from portableapps.com Check with Sumo and it will only list the portable launcher. Rename the appinfo.ini and then Scan files. Now you will see the actual 32-bit and 64-bit firefox.exe files listed and not the launcher. Easy to reproduce. This is normally not a problem because the ini files from portableapps will always reflect the current version of the actual apps.
OK... i'lll see how I could improve, but I see no obvious solution... and as you say, relying on appinfo.ini is usually a robust source for PA packages.
The .ini in the Launcher folder lists the actual executable and folder under ProgramExecutable= and ProgramExecutable64= These are the main files and are the ones to analyze and list to avoid the problem I described.
OK, i'll analyse. Thanks for letting me know
FYI: A new Kaspersky thread has been opened that discusses the alledged incompatibility of Kaspersky products with SUMo and some other apps:
I'd like to offer a suggestion that I think would accomplish two things:
1. It should dramatically cut down on the number of emails sent to Kyle by users regarding beta/error issues.
2. It should also dramatically cut down on the time wasted by users checking developer web sites for updates.
Now, not being a software developer I have absolutely no idea if what I'm going to suggest is a "gee, that sounds like an easy fix" type of thing, or a "are you freaking kidding me!" type of thing. But here goes . . .
Long time registered user of SUMo and love the product. But one thing that I think could make life easier would be to allow the user some input (by way of a user option) as to the "update available" threshold. If I go to the SUMo web site via right click on "get update" and take a look at the number of users on each release of the software, it seem to me that the threshold for triggering an "update available" message to the user is a simple mathematical formula (remember, not a developer, so I'm just simply interpreting what I see). As I see it, here's the issue though. Many times I don't think the threshold trigger takes into account what could best be called a "typical" user of the software.
Case in point, and this one comes up ALL the time, Dropbox! SUMo will run, and a "Major Update" for Dropbox will be triggered. Go to the Dropbox web site and the stats will say the the version of Dropbox reported by SUMo is a beta, and was released less than three hours ago. Go to the SUMo web site and you'll find that 17% of the Dropbox users are using the beta version. In no way could this 17% be referred to as "typical" Dropbox users. There's no way, serious users, corporate users, and even home users, with valuable data stored on Dropbox, would be using a beta version that was released less than three hours ago.
Now here's the fix. Add an "option" to SUMo to allow the user to select whether the trigger setting for the "update available" comes from the SUMo web site, or "local" via a user setting. So, if the SUMo web site threshold for Dropbox is 15%, and I find that that setting is continually triggered by beta users, I could check a box that transfers the trigger threshold setting for Dropbox to the local user and (via a sliding scale or some other input) set my local threshold to 20%, or 30% or whatever % I choose based on my experience with SUMo and that particular piece of software. In the case of Dropbox (and I'm including this based on history) simply setting the trigger threshold to 30% would have eliminated 90% of the "update available" messages.