Suggestions to increast productivity

Suggestions for future improvements, adding to scripts, or adding new scripts.
Post Reply
Swarvey
Posts: 5
Joined: Tue Jan 19, 2016 4:00 am

Suggestions to increast productivity

Post by Swarvey »

Hi, just suggesting the addition of a cmd line switch to allow Autopatcher to skip hash/md5 checking and go directly to tree generation.

I know this sounds dangerous, but here's my current scenario and how AutoPatcher is holding me back.

I'm currently trying my best to update an MSI "Leader" laptop, running Vista SP1 x86. However the following is/are occuring:

* Some updates need to be installed, then the system rebooted, then the next lot of updates need to be installed (nearly 200 updates in total)
* My AutoPatcher folder contains updates for all my machines ranging from XP, to Vista, to 7. A mixture of x86 and x64 architecture
* After every reboot I have to reload AutoPatcher
* Every time I reload Autopatcher it has to process hash checks and generate the tree

First problem:- Auto patcher asks for me to agree to two separate licenses- Workaround is to use /NOLICENSE cmd line switch, problem solved :)

Second problem:- Due to the size of my Autopatcher folder and the sheer number of updates contained within, between "Loading Modules" (which loads ALL modules inc incompatible modules), "Verifying Release Integrity" (again, verifies ALL modules) and "Generating Tree" I can lose anywhere up to 30 minutes of loading time. (keep in mind this is on a fast machine, loading from HDD not CD or Flash drive, high spec Intel CPU, gaming motherboard, gaming graphics, high spec WD HDD). Also, yes I could use a separate AutoPatcher folder for each separate OS, I've tried this, but it still leads me to the next problem...

Third Problem:- I cannot always simply copy (or xcopy, or dd) my Autopatcher folder from my main computer to other computers (no its not always to the same computer, mostly when I've just done a fresh install of the OS). Roughly half the time I attempt this, I have to redownload the modules again, either they won't install or they fail hash checking or something else. Sometimes the modules successfully pass hash checking, are blue in the download list, yet still download over and over again? In scenarios such as this, it's often quicker to have windows auto-update the conventional way.


First Suggestion:- I propose a new CMD line switch to bypass hash checking to speed the process up. If I'm using the same autopatcher folder on the same computer and rebooting several times, I think the risk that a file might not pass hash checking is VERY minor. Especially on a fresh, clean install.


Second Suggestion:- I would also propose a semi-permanent history. If Autopatcher was to keep a small history / log file in its folder, it could then remember that module X has been hash checked, passed and is ready for installation.

Third Suggestion:- A completely verbose installation routine, as opposed to the default "quiet" install procedure. If I can at least see what the updates are doing when they try to install, I would have a better chance of figuring out why they all freeze at 98%.

Combine these suggestions with another suggestion I read earlier (to not load incompatible modules) Autopatcher would be outstanding.

To further illustrate my frustration, I have spent the better part of three days trying to get this MSI "Leader" laptop back up to date. Between Autopatchers unavoidable loading times, certain updates freezing at 98% (always 98%) and having to reboot between certain updates, only to have to re-attempt certain updates because they have prerequisite updates that must be installed first, I've had to reboot approximately 20 times, recover from hash-checked updates that caused reboot loops (sometimes without BSOD) and other random Autopatcher crashes. Not to mention having to completely erase corrupted SoftwareDistribution and CatRoot folders (which I apparently have to do again right now, after a boot-loop, followed by system restore, and yes, I have chkdsk /F /X /R several times AND I've run memtest multiple times).

BUT, I do have to offer my greatest thanks and appreciation for Autopatcher, it has saved me a lot of time and bandwith.
ChrisJ
Posts: 353
Joined: Sun Oct 27, 2013 3:32 am

Re: Suggestions to increast productivity

Post by ChrisJ »

Hi Swarvey :) Just my $0.02 worth, hopefully someone else will jump in as well.
Swarvey wrote:Hi, just suggesting the addition of a cmd line switch to allow Autopatcher to skip hash/md5 checking and go directly to tree generation. I know this sounds dangerous, but here's my current scenario and how AutoPatcher is holding me back.
There is /fast -- this will skip the md5 check. If you're typing in the commands you may want to create a shortcut to autopatcher.exe and add both switches -- /nolicense /fast. Check out other switches available, /? or /help, then refer to the ap.log file.
Swarvey wrote:I'm currently trying my best to update an MSI "Leader" laptop, running Vista SP1 x86. However the following is/are occuring:

1* Some updates need to be installed, then the system rebooted, then the next lot of updates need to be installed (nearly 200 updates in total)
2* My AutoPatcher folder contains updates for all my machines ranging from XP, to Vista, to 7. A mixture of x86 and x64 architecture
3* After every reboot I have to reload AutoPatcher
4* Every time I reload Autopatcher it has to process hash checks and generate the tree
1 - Yes, some later updates have a prerequisite before they appear, the prerequisite needs to be installed first, and a reboot is always smart. 200 needed updates, you're way overdue for an updated integrated install disc which would solve most of your issues. There's the /noreboot switch - use with caution for reasons already mentioned.

2 - You've already come across the suggestion for individual folders for the OSes since there are gigs of updates and loading all updates is time-consuming, not sure of a better way just yet. I've suggested AP profiles in the past that is intended to act similiar to the way you mention so as to allow for everything in one \modules folder but only the selected profile will load and verify.

3 - Maybe an option to "start with windows" would help save a few seconds when multiple reboots are needed.

4 - One workaround that is doable, after you've determined all releases are Official, run a scan of \modules and create an md5 or sha1 profile, delete the rti(z) files (save apengine.rtiz)... This will skip verification with the only drawback being AP will warn you the releases are Unofficial, nothing in Release Info. This should speedup load time and you have your md5 or sha1 to run as a check. Updating the releases will grab the latest rti(z).
Swarvey wrote:First problem:- Auto patcher asks for me to agree to two separate licenses- Workaround is to use /NOLICENSE cmd line switch, problem solved :)
Using a shortcut, if you're not already, and adding the switches will save a few seconds over typing at Run every time.
Swarvey wrote:Second problem:- Due to the size of my Autopatcher folder and the sheer number of updates contained within, between "Loading Modules" (which loads ALL modules inc incompatible modules), "Verifying Release Integrity" (again, verifies ALL modules) and "Generating Tree" I can lose anywhere up to 30 minutes of loading time. (keep in mind this is on a fast machine, loading from HDD not CD or Flash drive, high spec Intel CPU, gaming motherboard, gaming graphics, high spec WD HDD). Also, yes I could use a separate AutoPatcher folder for each separate OS, I've tried this, but it still leads me to the next problem...
...As suggested, move the OSes (x64 & x86 together) and maybe .NET (x64 & x86 together) to their respective folders
...Delete rtiz files if releases are Official
...Start AP from shortcut with needed switches
...Hide incompatible items - see Options
...And update the install discs if possible

These simple steps should save quite a bit of time -- I know I'm repeating myself :)
Swarvey wrote:Third Problem:- I cannot always simply copy (or xcopy, or dd) my Autopatcher folder from my main computer to other computers (no its not always to the same computer, mostly when I've just done a fresh install of the OS). Roughly half the time I attempt this, I have to redownload the modules again, either they won't install or they fail hash checking or something else. Sometimes the modules successfully pass hash checking, are blue in the download list, yet still download over and over again? In scenarios such as this, it's often quicker to have windows auto-update the conventional way.
I'm not sure this is an AutoPatcher problem. I along with many users for years have been transporting AP via move, copy, from flash drive, CD, DVD. This particular issue seems to be with your Windows system or the tool you're using to copy. I've even used TeraCopy to move gigs of data without issue, this tool will scan before the move and create md5sums, and after move reverify.

Of course, if a file is corrupted after a bad move or copy it will fail verification in AP, fail installation, and need to be redownloaded.

If I understand the "blue in the download list" comment -- the download list will look for the rti file, if you have the latest it will list the release in blue but this doesn't mean your release isn't missing files or that some files are corrupt after a failed move or copy, verifying against the script determines this. AP logging with verbose mode should also shed a bit of light on problematic updates. An outdated release will be red, all based on the presence of the rti file -- otherwise the release will list in black.

Also, "blue in the install list" will only tell you if an update is installed or not, not about the status of the installer in \modules - it could have become corrupted after an update was installed successfully, and may need to be redownloaded - the script will confirm this -- AP with verbose logging will help find the culprits.

I'm not sure why a file that has passed a hash check, which would verify it is present, would then need to be redownloaded..?

Finally... I know probably not to your satisfaction but Suggestions 1 & 2 have been addressed a bit... some might help :) nothing more than updating your install discs which I know is not always an option.

Your 3rd suggestion has somewhat of an answer but you may not like it - edit the apm files and remove /quiet. This will allow the dialogs to appear. There might be an easier way, creating a script to install updates -- bypassing AP altogether has worked for some users. I've done this in the past, using AP only to download the updates.

There have been numerous issues with Microsoft updates, including freezing. The only thing you can do is minimize problems at your end and select fewer updates in a single run. As well, determine what MS updates are problematic for your system and avoid installing them. If you know what updates you've attempted to install, and those that have installed successfuly, can you determine those that failed by consulting their log file?

Anyone else have ideas :)
Swarvey
Posts: 5
Joined: Tue Jan 19, 2016 4:00 am

Re: Suggestions to increast productivity

Post by Swarvey »

There is /fast -- this will skip the md5 check. If you're typing in the commands you may want to create a shortcut to autopatcher.exe and add both switches -- /nolicense /fast. Check out other switches available, /? or /help, then refer to the ap.log file.
Damn, now I feel noobish. I've been using AP for years and believe me I searched and searched for cmd line switches, but all I could find was /auto, /log and /nolicense, so I made the post :(

/FAST now added to my cmd line shortcut :)

I don't mind doing one batch of updates, reboot then another, that's the way it's supposed to be :) I was just having a hard time with the looooong delays while checking hashes etc.
...As suggested, move the OSes (x64 & x86 together) and maybe .NET (x64 & x86 together) to their respective folders
...Delete rtiz files if releases are Official
...Start AP from shortcut with needed switches
...Hide incompatible items - see Options
...And update the install discs if possible
Yeah, that's pretty much what I'm already doing :) Except for updating the install media and deleting rtiz files. AP is freaking awesome, but due to all the bugs I'm finding with it, the less I screw with its file system the better.

Plus, the majority of the time I integrate the updates into the install disk, I still get prompts to install some (not all) of the same updates again through Windows Automatic Updates, it's as if they were never integrated in the first place. So I end up falling back to AP to install the rest. This alone has made me shy away from integration. Maybe I'm using the wrong tools, but nLite for XP, vLite for Vista, RT7Lite for 7, it happens across the board. Integrate the updates, some of them still keep coming from WU. Including the time it takes to extract, mount, integrate and burn the install disk, it's actually faster for me to do a fresh install then use AP.

I should have been clearer about the "Blue in install list", what I mean here is if I copy the AP folder (with or without un-necessary OS's) to a fresh-install PC, I'll launch AP, click Download Updates, tick the boxes for AP, the OS in question, office if required, and any adddons I may require, just to make sure I got them all in the copy, and even though they show up in blue as already downloaded, sometimes AP will re-download them anyway.

When I copy the AP folder from computer to computer, it's usually through a network (as a mapped drive, or shared folder), I've used the built-in windows "copy" and "xcopy" in the command line, or the "Copy" right-click menu for Windows Explorer. Occasionally when I do this copy, Windows and/or my cmd line will say the copy has been done successfully, yet when I launch AP it still finds more to download. So I've even tried using a live Ubuntu USB with "dd" to copy the folder from my main PC to the USB and then from the USB to the fresh-install PC. Same thing happens. I dunno, maybe the module is updated by the creator real quick between copies? who knows. I've even tried simply running AP from a Mapped Network Drive, which is painfully slow, even on gigabit ethernet or N-spec WiFi.

Example:
Launch AP on my main system, download all updates
On second computer (fresh install), copy AP folder through network from main PC to fresh install PC
Launch AP on fresh install PC and it wants to download the same updates again. Usually the updates that re-download are DotNet updates.
4 - One workaround that is doable, after you've determined all releases are Official, run a scan of \modules and create an md5 or sha1 profile, delete the rti(z) files (save apengine.rtiz)... This will skip verification with the only drawback being AP will warn you the releases are Unofficial
I have to giggle here, that's not really a problem. Every time I laucnh AP it's ALWAYS got "unofficial" in the upper-right corner. Yes I update it all the time. Not a problem, just funny :P Just to be clear though, I could just execute AP with the /FAST switch to avoid the hash checks? Meh, bugger it, gonna try that switch right now lol. Nope, doesn't really help, it's still "verifying release integrity". :(

Just to be clear about my suggestion here, if I launched AP, installed a batch of updates, rebooted, relaunched AP to do a second round, "verifying integrity" is just an un-necessary delay, they "verified" five minutes ago, before reboot, do they REALLY need to verify again?
I'm not sure why a file that has passed a hash check, which would verify it is present, would then need to be redownloaded..?
I have no idea either, I'd almost be willing to record a video of my screen to illustrate this, but it happens, on a regular basis. It's come to the point where if I'm sure I have all the updates I need, I stay away from the Download Modules section, as it's just wasting time and bandwith downloading updates I already have, over and over again.
...Hide incompatible items - see Options
I tried this yesterday for something new, there was a Vista KB I was trying to install, a security update that was causing Vista to go into an infinite boot loop (which required system restore to recover). After recovery, launched AP again, right clicked on the update, told it to hide it, but it's still there, even after a reboot, it's still in the list, automatically selected to install :(

I'm gonnna leave it here before my post becomes too messy and complicated. Not enough coffee yet this morning. I'll try the /FAST switch again, but so far it doesn't seem much faster. Thanks for the help :)
ChrisJ
Posts: 353
Joined: Sun Oct 27, 2013 3:32 am

Re: Suggestions to increast productivity

Post by ChrisJ »

Hi Swarvey :)

What version of AutoPatcher are you running, sorry if I missed it. I'm assuming AP 6x, 6132 and up.

I didn't figure much of this would be sufficient for you, AP isn't as intuitive as it should be by now IMO, it is still very analog (I've used this term before). It isn't that SMART in the technological sense, still has a lot of room to grow. I hear ya, I have a hard time keeping posts pithy, they become short stories no matter what I do.

Here's a few responses to your comments - hopefully someone else will chime in

:arrow: /fast is a relatively new switch, I don't believe it was in the AP 5x line. /fast only skips md5 checks, AP will verify size. The only option is to remove the rti files to skip all checks. This shouldn't be a big deal with official releases. To see the release status start AP - click Install Updates - About - Release Info. Also, if you've never used Sweeper, run it against your AP setup to see what it finds. I use /test /verbose. Consult the Sweeper log. Update the problematic releases, when Official, now it's safe to remove the rti files and speed up load time.

I forgot about the "arguments" file that can be used in place of a shortcut - run AP with /help or /? - see the AP log.

:arrow: Integration using nLite is good but for some files, the way nLite integrates is different from the way WU|MU verifies, best to see the nLite or RyanVM forums for more info and other tools besides AP that might help you update your system, or point out those updates that will continue to appear when using WU|MU.

:arrow: Assuming you're running AP 6x, at the releases list screen blue should mean you're up-to-date and... you have the latest rti file - the release will show blue but... you may still have missing or corrupted files in \modules from a failed copy or move... If the release is truly Official and up-to-date you will not need to download any updates - only the releases.list file and any scripts (releases) you select, and they get deleted after closing AP.

Next time you copy a confirmed Official release, afterwards run Sweeper /test /verbose against the copied release, it will let you know what files are missing or corrupt! This is strange indeed but is a PC thing not an AP thing - something is wiggy when copying files at your end. Also, I'm not too familiar with running AP from mapped or networked drives, it has been an issue in the past. As far as updating goes I prefer to have AP present (usually on root) on the system being updated, much faster.

What I'm saying is, a truly (confirmed) Official release, up-to-date wont need to download anything except a few files - the releases.list and the selected scripts, that's it. We have for a long time recommended users run AP twice on a fresh download, the second run will produce a much smaller log file, hopefully "Files To Download = 0" will print to the log :)

.NET is huge, you need to get it Official, it should be..? Run AP and select .NET only - twice! If it's failing post an unedited second run log in the .NET section so it can be looked over for problems. A verbose Sweeper log might help as well.

Download links die, this can cause a release to be incomplete if an update can't be downloaded. If a new link can't be found the script is edited, and the release resigned. Users should run AP and update the release.

In fact, you should update your releases now! Then click Install Updates - About - Release Info... what releases remain Unofficial..? Update again selecting only the failing release(s) - fewer scripts make for easier to sort thru logs! Post an unedited second-run log file so someone can see what's keeping your AP setup Unofficial??? A single file corrupted, missing, or extra files will flag the whole lot as Unofficial.

:arrow: I agree, verifying every startup is tedious, at this point simply remove the rti files from your official release. There is supposed to be a folder that can be used that will allow for custom updates, when used will not cause AP to get flagged as unofficial - it never worked for me. Searching for 'custom' or 'custom folder' might bring up something. Also, I think hiding compatible updates only grays them out, it doesn't make them invisible, they will reappear after reboot or restart - IIRC? There is a blacklist file but it also only works per session - IIRC? The best thing to do if you know a file is causing serious problems - remove it and the apm before updating. It might help others to mention what is happening with certain updates on your system, Vista updates, post in the Vista forums etc, KB #s help...

These are my suggestions, no doubt others will have a different take :mrgreen:
Swarvey
Posts: 5
Joined: Tue Jan 19, 2016 4:00 am

Re: Suggestions to increast productivity

Post by Swarvey »

What version of AutoPatcher are you running, sorry if I missed it. I'm assuming AP 6x, 6132 and up.
Using curent version v6.1.32 as updated by AP itself not long ago. (Curiously it still says Unofficial/Unsupported release)
I didn't figure much of this would be sufficient for you, AP isn't as intuitive as it should be by now IMO, it is still very analog (I've used this term before). It isn't that SMART in the technological sense, still has a lot of room to grow. I hear ya, I have a hard time keeping posts pithy, they become short stories no matter what I do.
Bit it just WREEKS of awesomeness. Even with it's occasional hiccups, it still rivals the invention of sliced bread, except the only way to eat it would be to swallow an SD card lol

/fast is a relatively new switch
Probably why I never found it before :) working as good as can be expected, even though it's still "verifying" all releases, it seems to be doing it much faster.
Also, if you've never used Sweeper, run it against your AP setup to see what it finds. I use /test /verbose. Consult the Sweeper log. Update the problematic releases, when Official, now it's safe to remove the rti files and speed up load time.
Last time I ran sweeper, approximately 80% of the modules went missing and I had to redownload again :( But I then read about how AP runs it automatically, so I just leave that bit up to AP. My intentions are to download less updates, less often, basically I'm not gonna risk wiping out my downloaded modules again.

I'll suss out RyanVM, but I RARELY have to touch an XP disk these days, I pretty much only run it in a VM inside W10 and only when I need to. 4Tb storage total in my workshop PC, so plenty of room for VHDs.
Assuming you're running AP 6x, at the releases list screen blue should mean you're up-to-date and... you have the latest rti file - the release will show blue but... you may still have missing or corrupted files in \modules from a failed copy or move... If the release is truly Official and up-to-date you will not need to download any updates - only the releases.list file and any scripts (releases) you select, and they get deleted after closing AP.
Yeah I don't rely on it ever being official / unofficial, 90% of the time it has big bold letters "Unofficial/Unsupported Release" Even after I tell AP to download the latest AP, which I try to only do once a month, but on occasion I've had to completely wipe out AutoPatcher and redownload it from the site through a browser and it will STILL say Unofficial/blah blah blah, it seems to be very hit and miss.
What I'm saying is, a truly (confirmed) Official release, up-to-date wont need to download anything except a few files - the releases.list and the selected scripts, that's it. We have for a long time recommended users run AP twice on a fresh download, the second run will produce a much smaller log file, hopefully "Files To Download = 0" will print to the log :)
Hahahaha, This Vista machine is about to finish the updates after another (third) clean install (all working this time, even though I maintained the same AP folder I was working from mere hours ago.... weird) But they're working :D :D :D BUT I would almost bet lefty that I'll go into the original AP on my main machine, proceed to downloads and it'll tell me files need to be downloaded, or it will just download them LOL if it happens I'll screenshot it and double check the log to see what's going on.
Download links die, this can cause a release to be incomplete if an update can't be downloaded. If a new link can't be found the script is edited, and the release resigned. Users should run AP and update the release.
Hmmm this laptop did originally have a bug with it's MPCIE WiFi card, probably borked the whole folder on me. Interestingly as of this last fresh install, that buggy card doesn't seem to be showing in dev mgr, not even as an unidentified device, that dodgy card could explain the non-BSOD Bootloops after security updates, they've been known to be interfered with by drivers, it's the update itself, not a buggy driver. Most people suffer loss of "Aero" or other issues with graphics chips, specifically Intel graphics chips as a result of certain updates on certain OS's. Anyhoo, with no card being detected, I think it's safe to assume the driver for the Atheros AR5007EG MPCI-E WiFi card was faulting the updates and bootlooping. Your quote above instantly made me think a faulty network could be causing any level of corrupted data. 2+2 :)

These are my suggestions, no doubt others will have a different take :mrgreen:
[/quote]
Think you hit the nail on the head there though LOL. My simple suggestion seems to have turned into a bug hunt, which is pretty much solved :D So big THANKS :D for that!

I think the /FAST cmd line switch pretty much answered my original query in the OP. It still verifies the modules, but it's absolutely NOWHERE near as slow as it was before. I think I can handle waiting that extra minute, at least it's not 30 now :D On the days where the new updates usually roll out I'll just run switchless so every once in a while the files can be hash checked and verified etc to keep the AP folder clean.

While I will most likely have the issue of modules still requiring download after my next copy, I'll try and report back what modules require re-downloading, maybe I'm missing something. All I know is when I "copy c:\Autopatcher d:\autopatcher" or "xcopy" it never reports any errors, copying via the Windows GUI never shows any problems, using the "dd" command in Ubuntu Live never says anything either. USB drives are always ejected or dismounted. Maybe it's just some ghost in the system somewhere f*@king with me lol.
ChrisJ
Posts: 353
Joined: Sun Oct 27, 2013 3:32 am

Re: Suggestions to increast productivity

Post by ChrisJ »

Hi Swarvey - I'm offering a final thought as I read your comments, paragragh at a time - yes I will repeat myself :) :) :) :)

Find out which releases are unofficial -> About -> Release Info. Get it Official, don't leave it broken. Get it Fixed!
:ugeek: wrote:AutoPatcher is one of the best tools for updating working systems - it's portable, reusable, & free.
AP verifies both size & hash, /fast will remove the hash verification, AP still verifies size. More files<=>More Time.

The tools are there to help & inform. Sweeper used to automatically delete bad files, now it asks for confirmation - not sure which version this started. I'd grab the latest Sweeper in the ap6140.7z too. I have 1.3.10 & 2.0.15.
... /test = will inform (won't delete), /verbose = a more robust log. Running Sweeper when AP starts is time consuming on large collections of files, I would untick starting with AP. Oh, Sweeper needs the rti files to work.

RyanVM forums are about updating an install disc thru integration, and last I looked XP thru 8 - different from updating a working system, which is AP's main focus. Check em out -> http://www.ryanvm.net/forum/ ... There's a member here who I think is very familiar with the RyanVM process, maybe he'll chime in should he read the thread.

Again, no need for an Unofficial setup. The Unofficial warning could be about any release, or all the releases, not just AP itself! See About - Release Info. Red is Unofficial, if all are True (Official) you have extra files somewhere which Sweeper should have already taken care of. If you could post a screenshot of your Release Info Screen - use Alt+Prt Scr. Also, this requires the need for the rti files being present as well, they're how the releases are verified.

Finally, rerunning the scripts a second or third time shouldn't be problematic, in fact it usually zips thru the releases, verifies everything, and writes a smallish log file with "Files To Download=0" I do this all the time. The fact you need files every run says you have a problem at your end, this needs to get fixed. Running the scripts regularly is the way AP stays updated, it shouldn't be causing you angst, really -> this is how it's supposed to work. We can help but we need unedited log files from AP, Sweeper, the Release Info screenshot might help too - we need to see something at this point, details about the contents of YOUR \modules folder.
Swarvey
Posts: 5
Joined: Tue Jan 19, 2016 4:00 am

Re: Suggestions to increast productivity

Post by Swarvey »

Hi Chris, sorry I must have misunderstood you. When I launch AP and goto the install modules section, it nearly always says Unofficial Release in the upper-right corner.

However I've just gone into release info and it turns out that Whatacrock's XP registry tweaks and Admin Tools packages were the unofficial ones.

I'm really sorry about the confusion there, but when it's saying Unoficial Release up in the top corner (nowhere near the modules list itself really), my instincts told me something was wrong with AP, since it was in the blue bar in the top-right (it really could be put somewhere more useful, say beside the unofficial modules themselves in the list? Eg [Admin Tools (Unofficial)], or [Registry Tweaks (Unofficial)], maybe even an addition to the colour coding AP uses to distinguish modules yet to be installed (black), from modules that are installed (blue) and modules that are incompatible (greyed out). AP is a bit too anaolgous here, as it's not until I went into release info that I found it was something else. I'd been ignoring it thinking it was an unofficial release of AP itself, I'd always figured it was a BETA or something.

Since I don't need them on this Vista machine and all the updates available through AP have been successfully installed as of last night, I'll delete the RTI(z) files for the two unofficial modules and run sweeper. Since the Vista machine is up to date, I don't have to worry about losing the majority of my modules folder like last time I manuall ran sweeper (it took out a vast majority of modules).

I had already manually deleted the modules folders for the above mentioned unofficial modules (leaving the RTI(z) files ) so they couldn't be installed anyway, sweeper seems to have removed the rest of the clutter after deleting the RTI(z) files. It now says "Official Release" in the upper right corner. Again, if I was to see this, If I didn't know what I know now about the application, I'd think it was AP saying it in and of itself was an official release. In fact looking at it now, even knowing what I've learned, it STILL says to me that AP itself is now an official release.

This confusion is compounded by the knowledge that there are unofficial versions of AP floating around out there that are more than likely malware. Again, I'm really sorry for the confusion, but here are some points to consider:

*There are "bad" versions of AP out there aimed at infecting victims computers - This is exactly why I thought AP was referring to itself when it says "Unofficial Release", either that or that it might have been a BETA release of AP (it's never once used the plural, only the singular). Honestly, I believed it was AP telling me either I was using a safe application, from a safe developer, or an unofficial update contributed by the community and not yet fully tested. I've ALWAYS thought this.

*There were two unofficial releaseS in my modules, not one, so when it says unofficial release, I still think ONE package is unofficial, but since they all came from AP scripts, downloaded via AP itself, I had NO reason to think the downloaded MODULES would be Unofficial "release(s)"

*The "Unofficial Release" message appears in AP itself, not in the list beside the ACTUAL unofficial "release" (module), go into release info and there they are, in bold, red letters

*Modules / Updates should be referred to as EITHER Modules OR Updates. From a programming standpoint a "release" is a version of an application. Not a module / update associated with the application. Example BETA or ALPHA Release refers to an application, not a windows update. (we're talking scripts and packages here, not actual applications)

*Plural vs Singular can be very confusing as can be modules vs releases vs packages, eg, two or more unofficial "modules" are considered to be a single Unofficial "release" by AP

Anyway, all updates available for Vista through AP have now successfully installed <--- Problem solved by using a different Wireless adapter and re-running AP without switches on a new clean install of Vista.
The "Unofficial Release" message is now gone <--- Problem solved by removing Whatacrocks modules, then running sweeper
My original suggestion for a cmd line switch to speed up the process has been answered <--- Solved by using the /FAST switch

On a side note, my AP folder is completely up to date, all the updates installed successfully yesterday, however Windows Update is just now installing 82 more updates. Maybe it's time I started delving into module / script creation, I've been wanting to get into that for a long time now.

Thanks again Chris, you've been a wealth of knowledge :D :D :D
ChrisJ
Posts: 353
Joined: Sun Oct 27, 2013 3:32 am

Re: Suggestions to increast productivity

Post by ChrisJ »

Swarvey wrote:Hi Chris, sorry I must have misunderstood you. When I launch AP and goto the install modules section, it nearly always says Unofficial Release in the upper-right corner. However I've just gone into release info and it turns out that Whatacrock's XP registry tweaks and Admin Tools packages were the unofficial ones.
No problem :)

This makes me laugh. Years back when we were assembling releases a bit differently than we are now, I had a release that was unofficial for maybe 2 years - annoyed me to death, it was a single stray file hiding away. We found it by creating an md5 on a known official release, and on mine. By comparing the 2 md5sum files using a comparison tool, within a minute the extra file was spotted, and removed. Most unofficial issues are fixed that easy, Wac just solved a similiar issue for 7x86. Stuff happens. These issues are easily remedied now by rerunning the script and Sweeper, and sometimes an edit to the script. Following these steps will point out missing, failing, and extra files.

BTW, XP Tweaks and Admin Tools, no need to delete them. I have the Tweaks, downloaded it recently as a test, it was official. I don't use the admin tools, I already use many of the tools, but portable versions.
Swarvey wrote:Snip...I'm really sorry about the confusion there, but when it's saying Unoficial Release up in the top corner (nowhere near the modules list itself really), my instincts told me something was wrong with AP, since it was in the blue bar in the top-right (it really could be put somewhere more useful... I'd been ignoring it thinking it was an unofficial release of AP itself, I'd always figured it was a BETA or something.
No problem, AP has a learning curve that varies from user to user. I'll disagree here with you overall, though the unofficial message could be made more intuitive. You're given a warning straight-away something is wrong, going to the Release Info screen will give you details. There has been a need for a help file - this is true, but we've always had a forum that would have cleared this up long ago. Now, I'm not referring to you when I say this but to be pointed, you're asking to completely idiot-proof AP IMO - not realistic. Some folks are still having troubles with Red, Blue, Black, & Gray. BTW, the dev of AP may agree with you and I'd be fine with that, as I've wanted for some pretty extreme changes in the past, when I had expected a serious change in AP's look & behaviour. I have no expectations at this point, I just want AP to be stable and usable on older as well newer OSes - I'll adjust.
Swarvey wrote:Snip...I'll delete the RTI(z) files for the two unofficial modules and run sweeper.
Just remember Sweeper will view all files not associated with an rti as extra and will delete em - this is why I use /test, in case I forget something I may have done, including removing an rti to speed up load time. Just a reminder :)
Swarvey wrote:Snip... the knowledge that there are unofficial versions of AP floating around out there that are more than likely malware. *There are "bad" versions of AP out there aimed at infecting victims computers

This Is Important! :arrow: It IS Malware :!:
As far as AutoPatcher & Microsoft is concerned :arrow: They Are Illegal Pirated Software :!:

When you download from autopatcher.net, you get files pertaining to AutoPatcher -- the software itself, the apm files, scripts, etc - see the scripts for details - the details are there and public. All MS OS updates, software from Adobe, Java, etc - all come from their respective servers directly - AutoPatcher hosts only software it has developed.

Years ago we used to create single sfx-type archives consisting of all updates for a particular OS release, XP, 2K, etc, hundreds of megs in size - hosted by various member's servers - we were asked to stop by Microsoft - we did so - this is why APUP was developed.

If you download from anywhere an archive of AutoPatcher_for_WhatEverOS_Oct_XXXX.exe - this is malware & is Illegal - period. It may now be a .rar, .zip, .sfx - all are Illegal - you've been warned, Again.
Swarvey wrote:This is exactly why I thought AP was referring to itself when it says "Unofficial Release", either that or that it might have been a BETA release of AP (it's never once used the plural, only the singular). Honestly, I believed it was AP telling me either I was using a safe application, from a safe developer, or an unofficial update contributed by the community and not yet fully tested. I've ALWAYS thought this.
Swarvey - you're over-thinking this whole ordeal. When you get the Unofficial warning see the Release Info screen, fix any release that is False (Red). If all are True you have a stray, runnning Sweeper should find it. It may take a bit more investigating using the log files from AP or Sweeper but most any problems get fixed. It appears most of your issues were in part your lack of understanding of AP messaging (the Unofficial message) and your problematic hardware that was borking your downloads. If you have issues start a thread, posts some logs, maybe a pic, we'll get it figured out - or you'll get a refund on your purchase - JK :mrgreen:

BTW, I really do understand that AP is not for everyone, have you tried WSUS Offline Update :?:
Swarvey wrote:Thanks again Chris, you've been a wealth of knowledge :D :D :D
I hope you were helped, and it was not a bother at all, it helps me too. I also agree there's still room for improvement.
Post Reply