Total Updater 0.8.6.9 - Total Commander & plugin updater

[EricB]

2Bluestar
ATM I'm creating such a userdb with all entries that are not active in the internal database. I'll send it by mail, since it is becoming a long list

Regards, EricB

[EricB]

2Bluestar

I just noticed that some userdb entries will not download (e.g. DecHex), while the webid is correct. Using the Visit online site or the webid button does link correctly to totalcmd.net item.

Regards, EricB

[Bluestar]

@EricB:
Huge thanks for all of the database entries, going to merge them into the following public version. Great work!

I've uploaded a 4th revision of the current TU version (this is the final for now, I promise ), which aims to fix the problem you just reported (download).
Hope it works fine now, the issue was such a silly problem in the code:

Code: Select all

[...] then Trim( [...] // original faulty code (can't believe i didn't gave any value to the string at all)

-> changed to:

[...] then udbStr := Trim( [...]  // new one 

Regards,
Bluestar

[EricB]

@Bluestar

I can confirm that downloading is now working again for such entries. THX!

Regards, EricB

[Bluestar]

@EricB:
Thanks for checking & confirming the fix.

Regards,
Bluestar

[romulous]

Still - of course - it is very welcomed if you report such faulty-recognized plugins, so the application becomes more and more reliable even in the most special cases.

Thanks. What about this one? HTMLView has a site on Totalcmd.net (which updater recognises), but now the new versions are available from here:
https://sites.google.com/site/htmlview/

So technically the latest version is 1.2.6 (not 1.1), and there should be an 'author homepage' link as well as the Totalcmd.net link.

Also, Choose Media Player is not recognised:
http://www.totalcmd.net/plugring/choose.html

Updater just says "TC2MP", version "1.0" and the rest is unknown.

[petermad]

2Bluestar

If I cancel an ongoing plugin download, then the so far downloaded data is still present in the download directory - but since it will be an incomplete corrupt file, it should be deleted!

If I have deselected all items in the list, and then use the context menu on a particular file to "Confirm updatable items as latest", then TU marks all updatable items once again and asks:
"Are you sure you would like to confirm the marked items (x/x) as latest?"

This is unexpected and "dangerous" since marked items that is not in view could be unwillingly marked as updated, if you don't notice the x/x.

Expected behaviour to me would be either:
1. Auto-mark only the highlighted item and offer to mark only that one as updated.
2. Grey out (disable) the "Confirm updatable items as latest" item - since no items are marked.

Could the "UserDB - Add new..." dialog be made a little wider - there is not enough room for the translation of [CaptionsUserDB] AuthorURL string.

[umbra]

Hi, there are a few more incorrectly detected plugins.

DiskInternals Reader
The lastest version is 1.6.4 for x32 and 1.6.0 for x64, not 1.03 as stated on www.totalcmd.net/plugring/diskinternals_reader.html. However the download link on that page points to the current version.

decFastThumbs
The lastest version is 1.9.0.74, not 1.8 as stated on www.totalcmd.net/plugring/decftumb.html. Again, the download link on that page points to the current version.

VisualDirSize
totalcmd.net contains version 1.2, but the latest version is 1.3.0.160, which is located on http://en.totalcmd.pl/download/wlx/oth/VisualDirSize.

ArchView
The latest version is 0.9.1.2. It's from 14.05.2006. But TU detects it as version 5.51 (which is the version of Total Commander it requires). You can detect plugin's real version either by it's date or from a file "history.eng".

Also, there is an issue with utilities. TU tries to find their updates, which is nice, but it often confuses them with real plugins with similiar names. For example I have a portable PuTTY. TU correctly detects it as an utility called "PuTTY suite" but it still thinks it's some lister plugin located at http://www.totalcmd.net/plugring/PUTTY.html. Maybe TU could search only for TC utilities and not for actual plugins in this case.

And again my question from my previous post. Is there a reason why TU does not detect any plugins, if it's not started from inside TC? Because if I start it from Windows Explorer, it correctly detects TC and utils in its directory, but not plugins.

[petermad]

Here are som UserDB entries for plugins not located on totalcmd.net:

Code: Select all

[filesys]
ProductName=filesys plugin
OriginalFN=filesys.wdx
InternalName=filesys
DirectLink=https://plugins.ghisler.com/content/wdx_filesys.zip
AuthorURL=http://ghisler.ch/board/viewtopic.php?p=253304#253304

[jpegthumbs]
ProductName=jpegthumbs plugin
OriginalFN=jpegthumbs.wlx
InternalName=jpegthumbs
DirectLink=https://plugins.ghisler.com/lsplugins/jpegthumbs.zip
AuthorURL=http://ghisler.ch/board/viewtopic.php?p=47728#47728

[wpdplug]
WebsiteID=
ProductName=Windows Media Audio 2
OriginalFN=wpdplug.wfx
InternalName=wpdplug
DirectLink=https://plugins.ghisler.com/fsplugins/wpdplug.zip
AuthorURL=http://www.ghisler.com/plugins.htm
Description=Windows Media Audio device access

[wmdmplug]
ProductName=Windows Media Audio
OriginalFN=wmdmplug.wfx
InternalName=wmdmplug
DirectLink=https://plugins.ghisler.com/fsplugins/wmdmplug.zip
AuthorURL=http://www.ghisler.com/plugins.htm
Description=Windows Media Audio device access

[CommentsWDX]
ProductName=EmptyWDX plugin
OriginalFN=EmptyWDX.wdx
InternalName=EmptyWDX
Description=Content plugin for checking empty dirs.
DirectLink=http://zpbj4q.sn2.livefilestore.com/y1mtdE2V02IpP6sFh3mzgL_WRjtc-_g48eAyPikbSzhiH2L58Wedxd99qpWYb9sIUhnmf_tKXJz_BmyQ8ITvvQlWQ/CommentsWDX.zip

[mediainfo]
ProductName=Media Info
OriginalFN=mediainfo.wdx
InternalName=mediainfo
DirectLink=http://tbeu.de/forum/wdx_mediainfo.rar
AuthorURL=http://www.ghisler.ch/board/viewtopic.php?p=256900#256900

[EricB]

Hi Bluestar,

After some thinking some more suggestions for the program:

- Automatically start the Search for Updates after start
- Scheduler support (very handy combined with previous request)
- When using Ctrl-Q on an active entry, some properties are shown. When clicking the Active link, the database entry is shown, but some of the fields that were filled in Quickview are not filled in (IN, OFN). When deciding to expand the entry (e.g adding a Description), it is made into a UserDB entry, but none of the existing fields (OFN, IN, PN) are copied. This would be very handy when expanding existing active database entries.
- On the UserDB tab, it would be nice to see more columns, so it is directly clear that if no WEBID exists, there is either an author site entry or a direct download.

Regards, EricB

[Bluestar]

@romulous:
Unfortunately I can't do much about HTMLView - in case a developer change his/her mind and decides not to update a plugin / addon on totalcmd.net anymore on which the given person previously constantly worked on, thats totally up to the author. Totalcmd.net is like a "master key" for the utility, so the queried online version information is handled as the only and most reliable one, nothing can override it at the moment.

I could do two things, though:

a) [the easier one]
Add a plus key to every 'faulty' entry in the database, like "[HTMLView] LatestVer=x.x" - so this way it would then be read directly from the local DB (thus overriding the queried info from totalcmd.net).
The problem with this approach: theres absolutely no assurance that someone is going to notify me if a new version comes out from a given plugin (and as time flies by there can be many entries in the future, I can't always check these external pages & the latest versions of these plugins one-by-one..), and even if some1 does so, it would need a new version to publish to correct it...
b) [the harder & slower one]
Adding the possibility to handle "WebID" keys with any url, on which any version number can be found (assuming that the user is going to fill this field with the actual plugin's correct homepage on which only this version number can be seen). The problem with this approach: currently only two Total Commander-related pages are queried to detect its actual version, plus one script on totalcmd.net, which makes the detection speed relatively fast. Now that speed would be dramatically reduced if we would talk about several page-requests instead of just these three, and we can't even be sure that they are all available (handling unavailable pages / timeouts, etc), and that the version number can be parsed from the page... so its not the way to go I think.

Also, Choose Media Player is not recognised

Thanks, added this external utility into the Internal Database, so it will be correctly detected from the next version.

_________________

@petermad:
Good point, these incomplete files should actually really be deleted. Just fixed this problem in the next release, thanks for noticing me about it.

Your "Confirm updatable items as latest"-related observation is actually meant to be a 'feature', which auto-reselects all updatable items for the user, if he/she previously unchecked all of them - in case at least one of them is selected, this effect doesn't happens. But you're right, maybe the best option would be just to gray out this popup option in such cases, so there wouldn't be any chance of items getting marked as latest accidentally then.

About the "UserDB - Add new..." - from the next version it is going to be resizable (as well as the Internal Plugin Database window), and I also increased its width a bit - the caption seems to fit perfectly this way. =)

Thanks for all of your entries, added them into TU.

_________________

@umbra:
Thanks for the reports, though currently I can't do much about "DiskInternals" and "decFastThumbs", see the explanation above (totalcmd.net is being considered the one and only reliable source of version informations, so nothing is stored inside the utility atm regarding latest versions).

The real bug here is the one you detected regarding "ArchView" (version 5.51, which is TC's version - its author didn't fill any of the PE version infos, and before mentioning the plugin's actual version number, he mentioned TC's one inside the readme file). Thats a problem of the intelligent version detection routine, which I just fixed now by adding the crc32-value of this problematic item.

About PuTTY: well, if the executable name of the applications is the same (and they are), theres no sure way to say that what exact application we are talking about (especially if the ProductName/InternalName/etc fields are unknown). For such items the only option is to right click on it and Exclude it from the list, since its not even uploaded on totalcmd.net, so there won't be a way to find update for it.

And again my question from my previous post. Is there a reason why TU does not detect any plugins, if it's not started from inside TC? Because if I start it from Windows Explorer, it correctly detects TC and utils in its directory, but not plugins.

I've answered to this problem one page before (please check this post). I would greatly appreciate if you could share those informations with me (any special setting/option in your wincmd.ini) to resolve the problem, or feel free to mail me your wincmd.ini file with removing the sensible parts from it (like "MkDirHistory", "RightHistory", "Command line history" etc) - I still can't reproduce the problem, and currently you are the only one who reported such behaviour of TU so far regarding the latest version.

_________________

@EricB:
Hi, thanks for sharing these ideas - I agree with all of them (maybe except the first one), they would surely make TU better.

About making the Search for updates automatically run after start: well that could be easily done, but there may be cases when the user first wants to exclude some items from the list, or check/uncheck some options in the Configuration (detecting TC versions, path of plugins etc), so I think it shouldn't be default. However you just gave me an idea: i could implement a new command line option like "/autocheck", and in case TU is started with this option, it would do this job right after start. What do you think about such a feature / should TU support any more command-line options in the future?

When using Ctrl-Q on an active entry, some properties are shown. When clicking the Active link, the database entry is shown, but some of the fields [...]

Actually thats not a bug, rather an incomplete implementation of the current method: TU actually checks the local file and always shows its existing keys/blocks content inside the PE file, no matter what other entries does exists in IPD / UDB regarding the actual item. I should really change it though, so in the future IPD/UDB entries are going to be considered and be displayed in the Infobox too.

On the UserDB tab, it would be nice to see more columns, so it is directly clear that if no WEBID exists, there is either an author site entry or a direct download.

Absolutely support the idea - somehow I'm going to find some space for them, the UserDB listview component surely needs to be wider for all these fields to fit in correctly. Maybe it wouldn't be necessary to show the full url's, only one extra column named like "Links", and its content could be "A" (standing for author) or "A+D" (author+directlink), or just "D" [suggestions are very welcomed!].

Regards,
Bluestar

(sorry for being a bit late with responses, was away for the weekend & had some other rl-issues too, but now everything is back to normal =))

[umbra]

2Bluestar
Sorry, somehow I missed that post.

I think I know the cause of the the problem. My wincmd.ini is written to be completely portable - there are only relative paths and environment variables in it. And the problem is here:

Code: Select all

7z=735,%COMMANDER_PATH%\Plugins\wcx\Total7zip\Total7zip.wcx

When I run TU from Explorer, there is no %COMMANDER_PATH% defined, so TU probably fails to detect a real path to such plugins. If I replace it with an absolute path, it works. But there might be a solution. TU correctly detects TC's installation directory. So in this case, TU could replace %COMMANDER_PATH% with the installation path (from InstallDir=, maybe, or PluginBaseDir= if it exists). It's not a perfect solution, e.g. it won't work for multiple TC installations that use the same wincmd.ini, but it's at least something.

PuTTY and similar - I understand, there is a lot of guessing. But there would be fewer incorrect detections, if TU tried to match detected utilities only to utilities on totalcmd.net and not to real plugins.

Download directory in the download dialog - well, it's not very useful, since it won't affect the current download queue, which starts automatically into previously selected folder. And either I don't change download locations, in which case setting the path in TU's configuration would suffice, or I do change them, in which case I want to select the path before the current download starts. The latter option seems to be more universal/useful.

[Gerby]

Hi Bluestar!

I've just had a small detection problem with the MhtUnPack plugin (hosted on totalcmd.net). Total Updater detects both the version of the installed file (1.7.0.0) and of the new one on the net (1.7.1) correctly. However, the status shows OK instead of indicating an available update. See also screenshot.

About the download directory (if Total Updater is installed in a path with read-only rights): This works fine now. However, I'm not too happy about the default location (i.e. [face=courier]C:\Users\UserName\AppData\Roaming\TotalUpdater\Downloads[/face]) which isn't easy to access (of course I can change it manually, though). If the download option is just planned as an interim solution and later this download directory is used for actually updating the plugins, this is ok for now. Otherwise I would prefer the current user's Downloads directory as default (if this is detectable in any way).

Greetings
Gerby

[EricB]

@Bluestar

First of all I can confirm Gerby's observation on MhtUnpack, I am seeing the same behaviour.

On command line /autostart parameter: suits me fine, could also be accompanied by a configuration tab checkmark. CL parameter would already be enough to put TU in the Windows scheduler and have it start detection automatically. Currently I have no use for other CL parameters, but maybe some other users would? One could think of TC path (to resolve Umbra's problem described above) or a download location.

Showing more field content in the Infobox would be great, especially when this info can also be copied to the UserDB entry if one is adding extra information (like an alternative direct download link). This way, if someone is submitting back a UserDB entry, it is already as complete as possible.

The UserDB listview could indeed be expanded with two columns for Author (or A) and Direct (or D). Clickable link would not even be necessary, all info is already in the infobox when editing the userDB entry. To obtain some extra space in the listbox you could also choose not to show the webid itself, but only a checkmark to show its presence. Same for the other two link types.

Regards, EricB

[Bluestar]

And the problem is here:

Code: Select all

7z=735,%COMMANDER_PATH%\Plugins\wcx\Total7zip\Total7zip.wcx

Oh, now that explains everything. I did a small change in the code just as you suggested, and from the next version TU is going to create a local environment variable "%COMMANDER_PATH%" (if it doesn't exists yet) with the path of TC's correct directory - of course strictly for its own process. Well, if a user has many TC's installed into different places (and some of them) set to use the same wincmd.ini, theres no correct workaround I guess; in such cases the best option is to run TU directly from the active Total Commander.

PuTTY and similar - I understand, there is a lot of guessing. But there would be fewer incorrect detections, if TU tried to match detected utilities only to utilities on totalcmd.net and not to real plugins.

You're right - such a feature just got implemented in 0.7.1; though atm I'm only trying to match executables & dlls with their online ID & filetype, 'cause there are several cases when a package contains wfx & wlx too (or other kind of plugins), and they are only classified into one single category.
(so if i would try to match all the item's filetype with their online one, they would got "filtered out" and be shown in the list as "Unknown")

About the download directory, my main goal from the start was to make the whole process as quick as possible, and without any necessary user interaction - thus I decided to autodetect the possible dl-directory, and automatically start downloading the files into it (for most of the users its just fine this way). Maybe I should change the current behaviour into showing a directory selector on the first start (and when downloading files for the first time) of the utility, so then the user could give a custom path or confirm that the detected directory is fine, then this extra dialog would never be shown, and the DL-path could still be modified in the config file (and later somewhere on the Configuration tab too).

Hi Gerby, I can confirm this detection 'issue' (which EricB also reported below your post), and I put quotation marks around the word 'issue' since it is actually caused by a feature of TU: PubDateDiffCorr=1 (in TotalUpdater.ini, which makes the utility assume that by default the new versions of a given plugin aren't coming day after day (which is really the case for 99% of the plugins), so by default if an author compiles a plugin/addon on 12-03-2013 22:55, he/she may only publish it on the next day - hence the name of this feature, PublicationDateDifferenceCorrection).
By default it automatically adds "1" to the actual (PE compile / last modification) date of the current files (if the online version seems to be newer and UpdateDateCheck is set to "True") to avoid false positive detections.

You can simply change this line in the configuration file to "PubDateDiffCorr=0" if you'd like to, but beware, as it may result in some false "Update available!" states (e.g. for me 3 plugins are affected atm).

@EricB:
Done in the next version ("/autostart"), I would gladly add some more cl parameters, so waiting for other user's suggestions too & in the meantime I'm thinking on what should be handy for TU regarding this topic.

Going to prepare the UserDB listview and add the extra column(s), however I think the WebID field is necessary to be shown with the exact content of it, as one may decide to sort the list so the blank fields would be in the top of it - and I think its just better to see them all in one place.

Edit: the case is the same with MhtUnPack's actual 1.8 version which just got released - if someone has 1.7.0 (or older version) installed, it will show up correctly as an update (since its PE TimeDateStamp is "12/03/2013" - TU adds "1" because of "PubDateDiffCorr=1" so it becomes "13/03/2013", but since today its 14/03/2013, it shows the item as updatable) [screenshot], but in case you already have 1.7.1, it shows up as "OK." in case of PubDateDiffCorr=1.

Regards,
Bluestar