Windows 7: Windows Media Encoder: No Specified Device Driver Is Present

I had downloaded Microsoft Windows Media Encoder (WME) 9.0.  I was aware that it was unsupported and otherwise limited in comparison against Microsoft Expression Encoder 4 Pro ($199).  I was trying to use it to do video screen capture in 64-bit Windows 7.  I went into New Session > Capture Screen > Specific Window and Capture Audio from the Default Audio Device > designate the window > name the output file > high quality > diplay information (blank) > Finish.  At that point, I got this error:

Windows Media Encoder

No specified device driver is present.(0xC00D0072)

A search led to a Microsoft webpage that said this occurred because DirectX Media 6.0 was not installed.  Unfortunately, the page to which they directed me for the appropriate download was defunct.  Wikipedia said that DirectX 6.0 was released in August 1998, that the current version was DirectX 11, and that DirectX had been included in Windows ever since Windows 95 SR2.  (I also saw an indication that this problem might arise only when trying to record audio along with the video.  I didn't investigate that; I was only interested in video plus sound at this point.)

My theory was that DirectX had grown and that WME had not been maintained to keep up with it, and therefore I needed to install an older version of DirectX for that purpose.  I was not sure that this would work without screwing up the more recent DirectX.  I made a System Restore point and then downloaded DirectX 8.1 Runtime for Windows 2000, released in November 2001.  I wasn't sure whether that was the right thing; I also downloaded the DirectX Media Platform SDK Redistributable (June 2001).  Both were around 6-8MB.

Before installing them, I looked at a few more posts.  One post said that what was missing was actually a WDM (Windows Driver Model?) driver for the microphone.  The plausible theory in this case was that I would gain nothing by installing a retrograde version of DirectX; instead, I just needed a current driver.  But I was using onboard audio; I had only installed the motherboard recently; and I had made sure to get the latest drivers at that point.  I guessed that the motherboard drivers were no longer attempting compatibility with WME.

There was always the option of using a handheld audio recorder to record sound from the speakers.  Or if I didn't mind risking blowing up my handheld recorder, I could try running a cable directly from the computer's headphone output to the recorder's microphone input.  I would still have the hassle of synchronizing audio with video in a video editor.  That would be more difficult if the video showed lip motion or other things that would become bothersome if they weren't closely aligned.

There was also the possibility of doing further research into who was using WME on Win7 successfully at this point, and what hardware they were using, and buying the appropriate sound card.  I was out of time for this project, but it could also develop that further research would turn up a solution I had overlooked.  But good video capture had been elusive.  I had bought Debut and had been using it with good results; the question only arose because there was a hopefully temporary licensing snafu where Debut didn't work for me in the middle of the night.  Debut was now working again, so I shelved this question for the time being.

Documenting Computer Work Onscreen - Second Try

I had previously used my Shotshooter.bat batch file to capture screenshots once or more per second, and had combined them into an IrfanView slideshow .exe to display a timelapse account of what I had been doing on the computer during a certain period of time.  I preferred to create a regular video file rather than an executable, and I also wanted to be able to add music, narration, or other audio.  So I tried again.

The problem wasn't video capture per se.  I had purchased a copy of Debut for that, after mixed results with freeware alternatives.  The problem was getting from the raw Debut output to the final video.  When I would import the Debut .avi into a video editor like Adobe Premiere Elements or CyberLink PowerDirector, the video quality would be seriously degraded.  It was possibly a problem with a simple setting in the editing program, but I hadn't yet figured out the solution.  At this point, for whatever reason, the resulting video of events on my computer's monitor was so poor as to be unreadable.

But let me back up.  Here's how I started.  I decided to try capturing my work in writing an essay.  It would wind up being a one-page document, so the whole thing was visible onscreen in Microsoft Word.  I had Word set to remember changes, so after hours of editing, I held down the Ctrl-Z key combination to keep undoing changes until I was back at the beginning.  (Before doing that, I saved a copy of the text.  One false keystroke would have destroyed the trail, and my essay would have been lost.)  When I was back at the beginning, I started the screen capture, using Debut.  Then, in Word, I held down the Ctrl-Y key combination to redo everything I had done, at a very rapid pace, while Debut was capturing.  I think I had set Debut to capture at seven frames per second (fps), so as to keep the .avi file somewhat smaller than it would have been at 30 fps.  When it was done, I stopped Debut and saved the .avi.

Now came the hard part.  Adobe and CyberLink weren't the only ones having problems with the Debut .avi output.  Media Player Classic (MPC) would likewise display that .avi in a severely distorted form.  In other trials, MPC played the audio but gave me only a black screen for the video.  QuickTime did just the opposite, playing the video but crapping out on the audio after a few seconds.  But for some reason, VLC and Microsoft's Windows Media Player (WMP) had no problem with it.  It was not clear why.  I would have guessed that my codecs needed updating, but I had just installed the latest K-Lite Mega Pack.

After much playing around, I found that VirtualDub was able to add an audio track, adjust the length of the video to the length of that audio track, and produce a relatively small .avi (but, regrettably, not an .mpg or some other compressed format) that WMP would play.  This video was about four minutes long and, at a 250 kbps setting (Microsoft Video 1, quality 100), it was about 70MB.  That was still huge in comparison to the IrfanView output, but it was nice to have the audio option.  At that bitrate, the video contained fade-like artifacts.  That is, when I deleted or changed some text in the original video, it faded out rather than just instantly disappearing.  It actually wasn't a bad effect, and I didn't want to upload a 700MB video, so I left it at that for now.

There seemed to be some artistic possibilities for this technique.  At some points, the beat of the music would coincide with the disappearance of lines of text, as if there were a rhythm to the editing.  Maybe there was, in some cosmic sense.

The remaining question was whether anyone else would be able to view this video.  I wasn't sure how it would turn out on YouTube.  So I uploaded and tried it.  It looked OK in full-screen mode on YouTube, viewed in Firefox and also in Chrome.  I downloaded it from YouTube, using NetVideoHunter.  The download was in .mp4 format.  It still didn't play right in WMP, but it played better in QuickTime, and it was less than half the size of the .avi I had uploaded.  So I thought perhaps I could have uploaded the 700MB version and used YouTube to compress it for me.

I still didn't have a straightforward process for putting high-quality screen capture video into a format that I could edit in a normal video editing program like Adobe Premiere Elements.  It seemed that, next time, I might try recording my original video in something other than Debut, to explore the possibility that that particular program had saved my video in an odd format that Premiere Elements and other programs couldn't handle.  I could also explore rapid Shotshooter screenshots, at least to the extent that my computer would be able to save multiple screenshots per second.  Then maybe I could also try using Premiere Elements, instead of IrfanView, to stitch those screenshots together into a time-compressed but visually high-quality production to which I could also add audio.

Documenting Computer Work with Screenshots and Duplicate Detectors

I was doing some work in Windows 7.  I wanted to log the changes periodically as I went along.  I had already developed a batch file, which I called Shotshooter.bat, to take screenshots and save them as .png files periodically.  (I think this will work in all versions of Windows.)

Having already done the NirCmd setup required to make that batch file work, I slightly revised it to read as follows.  (If the print is too small, use Ctrl-+ or copy and paste into Notepad.  Batch files are best not edited in a word processor like Word, since they change characters sometimes.)

:: Shotshooter.bat

:: Captures a series of screenshots.

:: See http://www.nirsoft.net/utils/nircmd.html for info on NirCmd.exe.

:: Takes two arguments:  how many shots, and how many milliseconds between shots.

:: Sample usage:  shotshooter 3600 1000
:: That example would take screenshots every second for an hour,
::   assuming the computer could work that fast.

:: To kill the program sooner, use Task Manager (Ctrl-Alt-Del) > Processses > nircmd.exe.
:: IrfanView provides a fast way to play back results.

:: Create Screenshots folder on drive D

D:
md \Screenshots
:: Go to the drive and folder where you put NirCmd.exe

W:

cd "\Start Menu\Programs\Tools\Programming and Scripting\NirCmd"
:: Run NirCmd with the desired settings

nircmd.exe loop %1 %2 savescreenshot D:\Screenshots\scr~$currdate.yyyy-MM-dd$-~$currtime.HH_mm_ss$.png

:: Go see what you've created in D:\Screenshots

start explorer.exe /e,"D:\Personal Projects\View These Weekly"

Having created Shotshooter.bat, now I wanted to run it.  I had already used Ultimate Windows Tweaker (UWT) to install a right-click option to open a command window in any folder I would select in Windows Explorer, so all I had to do was open a CMD window where I had saved Shotshooter.bat, and just type "shotshooter 1200 30000" and hit Enter.

(If I hadn't installed that option with UWT, I could also have gone to Start > Run > cmd and then navigated manually to the proper folder with change-drive (e.g., D:) and change-folder (e.g., cd "folder name") commands like those used in Shotshooter.bat, above.  Note that quotation marks are necessary if folder names contain spaces or possibly if they are too long.)

Those parameters of 1200 and 30000 meant that Shotshooter.bat would use NirCmd to take a screenshot every 30000 milliseconds (i.e., every 30 seconds), and would take a total of 1200 screenshots (i.e., would run for 10 hours).  It would save them in D:\Screenshots, and now I would have to decide what to do with them.

When I was writing up these notes, I didn't recall whether NirCmd could also produce JPGs or other image formats.  It probably could.  But after getting used to IrfanView, it probably would have been easier to just use IrfanView (File > Batch Conversion/Rename) to do a mass conversion of PNGs into JPGs if necessary.

The problem with a straightforward slideshow was that, if I allowed a few seconds for each screenshot, I could easily wind up with an hourlong show that would feature extended periods of no change.  On this particular day, I had gone to the store and out to lunch, so presumably nothing was happening during those periods.  The changes that I would want to see might pop up for only a few seconds in that hourlong show.

It seemed I had better get rid of the PNGs that merely repeated the same unchanging screenshot for long periods of time.  To do this, I tried a couple of approaches.  After making a backup of my Screenshots folder, I started with Awesome Duplicate Photo Finder (ADPF).  I adjusted its settings to examine PNGs and told it to search only the D:\Screenshots folder.  It felt that, out of my 1,200 screenshots, 1,160 were potential duplicates.  Closer examination revealed that, while many of those files were not what ADPF considered 100% identical, hundreds were.  Unfortunately, ADPF did not offer a way to bulk-delete the 100% matches.  I did not take the time-consuming approach of just letting ADPF guide me through the 580 pairs of images comprising those 1,160 alleged duplicates, making manual choices as to whether I should delete one of the two images it showed me.

I tried another approach.  Among the many free duplicate file finders, I had long used DoubleKiller.  (Exact Duplicate Finder gave the same results as one type of DoubleKiller comparison, but offered fewer comparison options.)  For some reason, a CRC and size comparison in DoubleKiller gave me only 161 duplicates.  I suspected DoubleKiller was being too precise.  Doing an unreliable size-only comparison, it still found only 340 duplicates.

Following the advice on a page that recommended five duplicate file detectors, I downloaded and installed Dup Detector.  It was not easy to understand, but some tinkering I was able to get it to work.  The first time I ran it, I told it to search only for 100% matches.  (By default, it was set to search for "Dup if within 98.5% to 100% match.")  The thing that made it work was to go into its Options > "Automatic and Semi-auto delete setup," highlight the "Delete left image" criterion (the only criterion I needed to use in this case) and use the "Swap up" and "Swap down" buttons to make "No delete" come after "Delete left image."  Then, to make it run, I had to start with Get data > Build.  Also, because of the number of files, I thought I had better start with Find > "Find dups setup (method and restrictions)" set to find 9999 pairs.  I still wasn't sure, at the time when I was writing these remarks, whether that was a good number to put there.

When I ran Dup Detector to search for only 100% matches, it found that about half of the PNGs were duplicates.  I eyeballed some of them, using IrfanView to flip through them quickly with just a right-arrow keypress.  There did appear to be a lot of exact duplicates.  I ran an automatic delete to get rid of those dups.  Then I ran a DoubleKiller search for matches that had both identical sizes and identical CRC checksums.  DoubleKiller still turned up 79 pairs of duplicates.  Apparently there had been more than 9999 pairs, first time around.  (If there were more than 100 exact duplicates, then there would be more than 9999 possible pairs.)  To check this, I ran another Dup Detector search for 100% matches.  It found a bunch more.

It seemed, then, that the best strategy would have been to run DoubleKiller first, so as to get rid of one item in each exact pair.  I did that now.  Then I ran Dup Detector, looking again only for 100% matches.  It found none.  I tried again, this time with a search for 99.9% to 100% matches.  Again, it found 9999 pairs.  Some looked identical, in the program's necessarily reduced and imperfect matchup screen, but the differences in others were visible -- more than 0.1% different, I would have thought.  I tried another search, this time adding a decimal point -- looking, that is, for 99.99% to 100.00% matches.

While that was underway, I ran another of the simple comparisons available in ADPF.  It said that, of the 851 pictures remaining (out of the original 1,200), it found 811 similar pictures.  In the bottom pane, I clicked twice on the Similarity column heading, so as to see what it considered the 100% matches first.  I couldn't tell any difference between the ones that I looked at.  I wasn't sure why ADPF had not considered them identical.

Before doing anything with that ADPF comparison, I went back to Dup Detector.  It had completed its 99.99% search.  It was still finding 9,999 pairs.  I had already noticed that, unlike ADPF, Dup Detector was not able to show the right portion (maybe one-sixth) of my widescreen screenshots.  I also noticed that the first line of the Dup Detector report, in the top left corner of the screen, said that it was comparing 99.9% (not 99.99%) matches.  So unless there was a bug in that report, apparently one decimal place was as precise as it got.

I preferred ADPF's visual comparison, so I went back to it.  In the bottom pane, it looked like about two-thirds of its similar pictures were at the 100% level.  That would apparently mean I would have to do hundreds of manual comparisons:  Picture 1 might match Picture 2, and also Pictures 3, 4, 5 . . . I went down to the 99% matches.  These, too, were identical, as far as I could tell.  I had noticed, in IrfanView, that the only thing that had changed since the previous screenshot, among some screenshots, was that the system clock, in the bottom right-hand corner of the screen, had moved ahead by one minute, so maybe that sort of thing kept ADPF from catching them at the 100% level.  ADPF wasn't showing the taskbar or other outer edges of the screenshots, so I couldn't tell for sure.

With hardly any exceptions, I found that even the 95% matches in ADPF were virtually identical.  The only differences that I could detect, in the 50% of less of matches where I did see a difference, was that a different window might be foregrounded -- that, in other words, its title bar would be a different color in one screenshot than in the other.  In other words, the ADPF matching levels seemed more realistic than those in Dup Detector:  this was the kind of difference that I would expect to be detected at the 96% level, well before the 99.9% level.  A 99.9% match, I felt, should involve no more than the tiniest flyspeck of difference.

For my purposes, I did not get regular, visible differences in matches, in ADPF, until I was down at the 91% level.  There were few matches at that level, so I decided to err on the safe side, manually deleting duplicates down to the 95% level.  But in the process, I stopped along the way to re-run Dup Detector.  It seemed I might be able to calibrate it against ADPF.  In other words, I first deleted all of the 100% matches in ADPF, and then ran Dup Detector.  There were about 360 of those, or about 45% of the 811 similar pictures detected by ADPF.  Deleting them was pretty fast, once I got the keystroke combination worked out; it probably took 6-7 minutes.

Rerunning Dup Detector at the 99.9% setting, after deleting ADPF's 100% matches, still produced 9999 matches from the 482 screenshots remaining.  I expected it to produce matches that were extremely difficult to tell apart.  This was not the outcome I got.  There were a number of rather obvious (although still very minor) differences.  It seemed, at this point, that Dup Detector's supposed 99.9% match was not realistic and, for my purposes, not meaningful.  In general, it seemed that Dup Detector had been useful only for purposes of automated deletion of 100% matches, though possibly that function would have been served equally well by an easier DoubleKiller comparison in terms of file size and CRC.  It didn't look like Dup Detector had anything more to offer me at this point.

In the interests of automating future comparisons, I looked around for a free bulk CRC calculator, but ultimately got better results searching for an MD5sum program in CNET.  I thought about FSUM but finally went with the somewhat higher-ranked MD5summer.  Both would do batch work and yield text-file output, but FSUM was command-line.  MD5summer did give me the option of saving its calculated sums as a text file, which I then imported into Microsoft Excel.  Using text parsing functions (e.g., MID, LEFT, TRIM), I extracted the 32-character checksum, sorted, and used a formula to compare cells.  MD5summer had evidently identified only 322 duplicates in 161 pairs.  Possibly the reason the duplicates were found only in pairs was that I had run Shotshooter (above) in 30-second intervals:  there would be only two screenshots per minute, before the system clock changed, producing a screenshot with a different checksum.  That had probably been the case with the DoubleKiller CRC checksum results as well.

One workaround would have been to see if I could conceal the system clock before starting, or I could batch-trim the PNGs in IrfanView (File > Batch Conversion/Rename > Advanced > Crop) before running the checksum, but in this case I wanted the clock to be visible on the output.  (I could also have used cropping, or could have drawn circles and arrows on my PNGs, using something like Photoshop, to narrow the focus to particularly interesting changes on the screen, so as to reduce the percentage match that ADPF or other duplicate detectors would calculate.)  I could have done the batch-trim with a copy of the snapshots backup folder, so as to produce a list of files to be deleted without harming the originals (or, in this case, the copies).  But what if the only thing that changed (in some future application) was a small item in the center (i.e., not at the edge) of the screenshot?  I could use the spreadsheet to identify not only the duplicate pairs but also the time periods during which every minute had a matching pair, so as to lead me toward large stretches of time when nothing would change, and then maybe a manual comparison in ADPF would be manageable for the rest.

So those were possibilities for future projects.  At present, having deleted the ADPF matches down to the 95% level (leaving a few near-duplicates where I could quickly see a difference), I continued on a bit further in ADPF, deleting some additional near-duplicates.  At the 91% level, almost every pair of near-duplicates contained visible differences, so I stopped there.  So I was done with ADPF.

I now had 442 fairly distinct screenshots, out of the original 1,200.  I would have had more if I hadn't abandoned the computer for several hours while Shotshooter was running.  I viewed a bunch of them in IrfanView, again using the right-arrow key to move quickly to the next.  I had already set IrfanView (Options > Properties > Browsing/Editing) to go to the next file after I deleted one -- or maybe it did that anyway, by default.  It now occurred to me that some of my ADPF work might have been faster, and that differences might have been easier to see, if I had just paged through the screenshots (or at least some of them) in IrfanView, using the Delete key (alternately, the X button, up by the menu bar) to delete apparent duplicates.  When I ran into a stretch where there seemed to be many duplicates, I stopped hitting Delete (in case, by deleting too fast, I would accidentally delete one after the screen did change) and instead just selected and deleted many at once in Windows Explorer.

Holding down the right-arrow key in IrfanView allowed me to page quickly through obviously similar or dissimiliar screenshots.  There were still quite a few, requiring as many as 90 virtually duplicate screenshots to be deleted in one case.  It seemed that ADPF may have been fooled, not only by the system clock (which still seemed to be the only thing that was changing, in many cases), but also by relatively complex screenshots (e.g., showing photographic or Google Earth images rather than just text documents, spreadsheets, and Windows Explorer sessions).  That is, to my way of thinking, many of these images were 99% similar, but ADPF hadn't even considered them 91% similar, so possibly its comparison engine was miscalculating similarities in some conditions.

After these other steps, I took a final trip through the snapshots, in IrfanView, and deleted a few more that were very similar to the ones immediately preceding them.  I wound up with 207 snapshots, out of the original 1,200, that seemed to represent fairly well what I had been doing over a 10-hour period.  Again, the number could have been substantially larger -- maybe around 300-350 -- if I hadn't spent a few hours away from the computer.

Now I wanted to put these snapshots into some kind of slideshow.  I rarely made slideshows.  On a few of the screenshots, I decided to use Adobe Photoshop Elements to draw circles and lines to draw attention to changes, from one slide to the next, that might otherwise escape attention.  Then I figured I would use IrfanView (File > Slideshow > Save slideshow as EXE/SCR) to create a slideshow.  (I could also have used something like PowerPoint, except that apparently that would have required me to create 207 slides and then import a photo into each.)  But IrfanView wouldn't let me add circles and arrows or, as seemed increasingly appropriate, a voiceover, to explain what was going on.

I tried using both Adobe Premiere Elements and CyberLink PowerDirector, but neither of them wanted to let me export to a full widescreen format.  Saving it in a reduced format (e.g., 720x480) lost so much detail that it was hard to read what was being displayed.  They also created huge files.  These programs -- especially Premiere Elements -- were also pretty terrible at giving me a simple way of arranging slides.  I wound up just creating an IrfanView EXE slideshow in full-screen mode -- and you know what?  It was beautiful.  Visually, it was perfect.  It looked exactly like the regular computer screen from which I had created all those screenshots.  And it was only 91KB.  Tiny!  The only drawback was that it couldn't incorporate a voiceover and lines and arrows.  So the output side of this project was still in development.

Windows 7: Recording Streaming Audio

I had previously tried, but failed, to get my system to record streaming audio.  The concept, in this mission, was that I wanted to be able to capture, in a file, the sound that I was hearing in my headphones.  Seemed like a simple expectation, and as I recalled it had been almost automatic on my previous system.  But it wasn't happening on my current motherboard, a Gigabyte GA-MA785GM-US2H, so I searched for solutions.

The first requirement seemed to be to use the right software.  Not every audio program is capable of recording streaming video.  The free Audacity program could, so I was using that.  I found a video and a webpage that were supposedly going to help me, and probably I did incorporate some of their suggestions into the approach that eventually worked for me.  The only suggestion that I recall making a difference was that, as recommended, I was using the version 1.3.13 beta of Audacity, not an older one, though at this point I'm not absolutely certain that was necessary either.

Ultimately, I found two ways to record streaming audio.  One was to use a video capture program and convert the resulting file to audio.  I'd had tried a number of video capture programs, with very mixed results.  The only one that seemed to work reliably was Debut, and it cost money after its free trial period.  Ultimately, I did buy a copy of that.  For the conversion, I used Oxelon.

The other approach was to use an audio cable to connect the computer's headphone jack directly to its microphone jack.  Basically, I would be recording what the headphones were supposed to be hearing.  Sadly, this didn't work as advertised, when I used the actual jacks on the computer itself.  But I was able to make it work in a different way.  I bought a Syba SD-CM-UAUD USB-to-audio adapter.  No software required.  I just plugged it into a USB port, plugged both ends of the patch cable into it, and it worked.  Actually, to make that work, I had to set Audacity as follows: the audio host was Windows DirectSound; the output device was Primary Sound Driver; the input device was Microphone.

The Syba device gave me really loud volume.  Later, I had to fiddle with Control Panel > Sound to get all my devices back the way they were before.  But so far, it seemed worth it.

Windows 7: More Tweaks & Fixes

I had installed a customized version of Windows 7, and then tweaked it in a variety of ways.  This post describes additional random issues that needed to be fixed.  Some of these issues are described in separate posts:

• Remove the InstallShield Update Manager.
• Eliminate the "You need permission to perform this action" error message.
• Eliminate the option to speed up browsing by disabling add-ons in IE 9.

Verify That You Have Access to That Directory

I was working along, minding my own business, when Adobe Acrobat 9 Pro decided to update itself.  Then it gave me this error message:

Error 1310.  Error writing to file:C:\Config.Msi\c33075c.rbf.
Verify that you have access to that directory.

I clicked Retry.  The message returned.  A search led to a seemingly comprehensive Adobe webpage on the problem.  (The webpage said that products affected included Creative Suite 4.0, which included Acrobat.)  I had to cancel out of the error message and the Acrobat update to proceed with the steps it advised.  I started by trying the option of changing properties on the folder named in the error message:  Windows Explorer > right-click on C:\Config.msi > Properties > Security tab > Advanced > Owner tab > Edit > select Administrators > click box "Replace owner on subcontainer and objects" > OK > OK.  Now the Properties dialog was closed.  That gave it a chance to adjust itself.  Now I went back into the same right-click on C:\Config.msi > Properties > Security tab > Advanced dialog, but this time I went to Permissions tab > Change Permissions > verify Full Control for SYSTEM and also for Administrators > check the two boxes (i.e., "Include inheritable permissions" and "Replace all child object permissions") > Apply.  I saw that I now had two different entries for SYSTEM and Administrators here, so I departed from the official instructions here to remove the ones that did not have Inherited permissions.  I had to remove them one at a time.  The "Replace all child object permissions" box did not stay checked.  I went back into Acrobat.  It started doing the update installation again.  The error recurred.  Going back to that same webpage, I tried the option of renaming C:\Config.msi to C:\Config.msi.old.  The error recurred.  I rebooted; same thing.  But now Acrobat was seeing that it wanted to install an update, so I let it.  Apparently this was different from whatever it had been trying to install before but had failed; this one succeeded.  It required another reboot.  After the reboot, the problem was gone:  I was able to start Acrobat without having it first try to run that failing update.  I wondered if perhaps renaming C:\Config.msi had triggered the update that apparently solved the problem.  A week or two later, unfortunately, I found that Acrobat was still malfunctioning.  I tried a repair and that didn't solve the problem, so I uninstalled it and tried alternatives.

Revise Robocopy

In a previous tweak, I had set up a Robocopy script to mirror my data drive to another internal drive every hour.  Now I wanted to have incremental backups, so that I would back up changed files every hour or two, with a reset every 24 hours.  Ultimately, my solution to this item was to install Backup Maker (see below) and let it do its thing.  I didn't like its nag screen, though, and felt that more work on a Robocopy solution might have been better.

Running AvaFind in Windows 7

I had bought a license for AvaFind, a file finder utility, but I'd had problems trying to use it in Windows 7.  AvaFind had not been updated since version 1.5, back around 2003.  I had tried using it in compatibility mode for Windows XP SP3, but that hadn't worked very well; it was still crashing.  As a temporary workaround, I installed a shortcut to AvaFind in my Start Menu, and just clicked there to restart it whenever it crashed.
Meanwhile, on a second machine, I was getting an error message when I tried to install AvaFind.  The error message was:

Ava Find Internal Error
Ava Find has detected an internal error and must be closed.  Error information was saved to AvaFindErrorData.zip on your desktop.
Ava Find Version:  1.5.218.040106-1058p

The failed installation left an error log file on the desktop.  I unzipped it and found that the log insisted on being printed as a PDF.  The error message inside that PDF was:

[0x0008062e] Win32Exception 0x80070003: SHGetFolderPath[0x18 COMMON_STARTUP] failed. (0x80070003 The system cannot find the path specified.)

I did a search but found nothing.  Another search turned up some results, but then it occurred to me that AvaFind was functioning correctly on another machine, so what would happen if I just copied over its C:\Program Files\AvaFind folder?  I did that and double-clicked on AvaFind.exe.  It ran.  But getting it to function as a registered copy apparently required installation.  I stored a copy of the AvaFind folder in my customized Start Menu, where I kept all my portables, but I also went ahead and installed it.  As time passed, though, AvaFind was still not working well.  Ultimately, I adopted Everything as a good alternative.

Capture Streaming Video

I was once again looking for video capture freeware.  I had previously tried Camstudio, but had audio problems and poor quality, and TipCam, which seemed temperamental.  I found a list of programs and tried several.  Among these, GetASFStream would only work with a URL, which wasn't helpful for my purposes because the video I was trying to download would pop up in a separate window without its own URL.  I had previously found Debut to be excellent, but it had stopped working after a trial period, requiring me to spend $30 to continue.  Not an unreasonable expectation, but I was not doing much video capturing and had just decided to do without, at that price.  aTubeCatcher had some pretty good reviews on CNET, so that was one option.  Other options included StreamTransport (significantly less praised on CNET), Coojah (not listed on CNET), Orbit Grab Pro (a Firefox extension) and Orbit Downloader (heavily downloaded and fairly well liked on CNET), and the RTMPDump command-line option.  I had previously used Orbit; I saw some remarks about bugs on the CNET page; I decided not to start there.  The CNET review said I would need a URL for aTubeCatcher, so I didn't start there either.  There seemed to be another option, involving some technical adjustments.  Before trying it, I wondered whether maybe Debut had changed their licensing policies or had forgotten me -- it had been a year or more since I had last tried them out.  When I closed this post, this was still an area in development on my system.

Internal Incremental Backup

I had previously used a Robocopy script to mirror a hard drive to an internal partition, and had used the built-in Windows 7 Task Scheduler (taskschd.msc) to run it.  There were several things not to like about this arrangement.  First, I had the script running in a batch file, and I couldn't figure out how to teach batch files to run minimized.  So I would be working along, and then suddenly this thing would pop up and start running.  Second, Task Scheduler didn't have an option to run every two or three hours, and that was what I was needed, because otherwise this script was popping up every hour and running for a good chunk of that hour.  I wasn't sure whether it was actually slowing the system down that much; I just didn't want it running that frequently if it was going to be so visible.  Third, my Robocopy settings were doing a mirror, whereas I decided what I really needed was incremental backups, so that I would have multiple copies of files that I was working on, going back in time.  I came to appreciate the value of this once again, as if I had not learned it many times before, when a file I was working on got corrupted and then got backed up, overwriting the last good copy, so I lost several hours' work.

I decided to scrap the Robocopy approach and go with a more traditional backup program.  For right now, I decided to start with the built-in Windows 7 backup program (Control Panel > Backup and Restore).  But it didn't have an hourly option.  I found a webpage that said I could set up an hourly backup by going into Task Scheduler > left pane > Task Scheduler Library > Microsoft > Windows > WindowsBackup.  This didn't give me the options they were seeing, so I assumed I first had to have the built-in Backup and Restore program set up.  So I went back into Control Panel and finished setting up a backup.  But now I wasn't sure if the built-in backup program could do incremental backups.  I found one of the invariably useful Gizmo webpages.  It recommended Backup Maker.  German homepage, but mostly English download page.  Backup Maker was not my ideal, but it worked.

Adobe Acrobat 8:  Comment & Markup Toolbar Reverts to Default

I was using Acrobat 8.2.6 in Windows 7.  I had a problem that I had also encountered when using Acrobat 8 in Windows XP.  The problem was that, when I would start Acrobat, often it would start with what was, I guessed, the default set of tools in the Comment & Markup toolbar.  I would select the tools I wanted, lock the toolbars, shut down Acrobat in an orderly way (i.e., File > Exit), and yet the default set would reappear when I opened certain documents.  It seemed that the desired set of tools had to be set manually for each PDF document -- that those that I had not yet opened in Acrobat 8 would favor the default set of tools until otherwise instructed.

I ran a search and found a thread with a few suggestions.  I tried the one about deleting my preference file.  I wasn't sure where to find that.  As I poked through another search to locate it, I saw that deleting the preference file seemed to be common advice for fixing random problems with Acrobat.  It took yet another search to find a post that seemed to address the topic.  The advice here was that I could automatically delete a preference file in some Adobe products by holding Ctrl-Alt-Shift as the program starts.  Just click the Acrobat icon, he said, and immediately hold those three keys down until the program finished starting.  This did not work for me, regardless of whether I started holding those keys down before or immediately after clicking on the Acrobat icon.

I decided to search for the preferences file and delete it directly.  As advised in one thread, I tried looking for it in C:\Documents and Settings\All Users\Documents\Adobe PDF\Settings.  Unfortunately, I was not able to open that folder.  Attempts to do so gave me an error message:

Location is not available
C:\Documents and Settings is not accessible.
Access is denied.

In Windows Explorer, I right-clicked on the folder and used the nifty "Take Ownership" context menu option that I had previously installed via registry edit.  Now I was able to go in.  I had to repeat that step for the Documents subfolder.  But Adobe was not in there.  I had a general sense that, in Windows 7, the "Documents and Settings" folder was just a placeholder or shortcut to a different folder, but I didn't yet know clearly where that other folder was, and right-clicking on the Documents folder itself gave no clues.  Searches for pref*.dat gave me only Adobe Updater preference files.  It was possible that the problem was due to a flaw in the registry rather than in a preferences file, but I wasn't sure how to find a registry problem either.
At the time when I closed this post, this problem was still unresolved.

Do You Want to Allow This Webpage to Access Your Clipboard?

For some reason, I suddenly started getting this question whenever I tried to copy and paste something in Win7. It may have been the result of an upgrade to Internet Explorer 9. The solution was to go into Control Panel > Internet Options > Security tab > Trusted Sites (green checkmark) > Sites > Add this website to the zone. (This seemed to be the more conservative approach; I guessed that the more adventurous approach would have been to do these same steps under the Internet icon rather than under the Trusted Sites icon, so that they would apply to all websites.) I added the website in question. To do it, I had to unclick the "Require server verification" option. Then I went to Trusted Sites > Custom Level. In the Scripting section, not far from the bottom of the long list of settings, I checked Enable under "Allow Programmatic clipboard access." 

Schedule Defragmenting

I thought I had already taken care of this, but it appeared I had set up automatic defragging for use with a third-party program that I no longer had installed.  Third-party programs may well have been superior for this purpose, but I was OK with just average defragmenting for the time being.  With guidance from a Windows 98 webpage that came up in response to a search, I automated the Win7 defragger by going into Start > Run > taskschd.msc > Action > Create Basic Task.  I went through the wizard to set it up.  When I got to the Action step, I said Start a Program.  The program I wanted was Defrag.exe, and it was to "Start In" the C:\Windows\System32 folder.  In the "Add arguments" space, I typed "/c /u /x" from among the possible options.  At the end, I checked the option to go into the task's properties.  There, under the General tab, I checked "Run with highest privileges" (not the same as high priority) and "Configure for" Windows 7.  Under the Settings tab, in addition to whatever was already checked, I checked "Run task as soon as possible after a scheduled start is missed."

The problem with those settings, as I soon discovered, was with the /c option, which would defrag all volumes, and perhaps also with the /x option, which was much slower than I had expected.  Even though I had this scheduled to run during the night, I would sometimes find that it was continuing on into the daytime.  I had a choice:  set up different defragmenting tasks to run on different nights, or switch to a different defragging program.  Microsoft said IOBit's Smart Defrag was compatible with Windows 7, as it had been with Windows XP, and it still had great ratings on CNET, so I decided to download and use it after all.  I decided not to go with the option of using Security 360, which IOBit offered as another freebie after Smart Defrag installed.  That decision was based on criticisms I saw in several posts I viewed about it.  Anyway, with Smart Defrag installed and configured, I disabled the Defrag.exe scheduled task described in the previous paragraph.

Downloading Video from Canon ZR800 MiniDV Camcorder

I got a great deal on a used Canon ZR800 video camera. I went out and shot some video, and then came home and tried to download it to the computer. That's where the fun began.

Canon provided no drivers or other software downloads to use with the camera.  The manual (p. 46) provided very little information in its "Connecting to a Computer" section.  It said you would need a Firewire cable and a Firewire (IEEE1394) connection on your computer, as well as video editing software and "the appropriate driver."  The manual said, "A driver is preinstalled on Windows operating systems later than Windows 98 Second Edition and Mac operating systems later than Mac OS 9, and will be installed automatically."  It also said, more disturbingly, "The video transfer may not work correctly depending on the software and the specifications of your computer."

The camera had a Firewire port, but Canon did not include a Firewire cable in the box.  That would have cost around $10, but I already had one.  I had used it with my previous camcorder, so I knew the cable and the computer connection worked.  The camera did not have a USB port, so the only other way of getting data from the tape inside the camcorder to the computer (other than buying or borrowing (from a friend or library) some other camcorder or tape drive) would have been to connect the camera to the computer with the supplied video and audio analog cables (for TV connection).  That would have given me a lower-quality analog copy, and would have done so at 1x speed, i.e., with the tape playing in the camcorder while the computer copied what it was receiving.  So it would have taken an hour to download an hour's worth of recording.

I had previously found Firewire connections to be rather flaky.  I realized that Firewire would transfer data much faster than USB 2.0, and that this was probably necessary for people who wanted to use the camcorder for live streaming video.  But since most people use a camcorder to go out and shoot video of places and events, a USB connection seemed like a good idea.  To me, that is.  Not to Canon.

I plugged in the camcorder's power cable, so that it would not have to rely on its battery for whatever came next.  I put the camcorder into Play mode, pulled off the plastic plug covering the several jacks along the side of the unit, and plugged the Firewire cable into the Firewire port under that cover.  I looked at the LCD display on the camcorder.  In the top center, it was flashing the letters "DV-IN."  The manual provided no indication of what this flashing might mean.

On the computer, using Windows XP SP3, I started Windows Movie Maker and clicked on "Capture from video device."  I got an error:  "A video capture device was not detected."  I tried again in Adobe Premiere Elements 7.  It said, "No DV camera detected."  I looked at Windows Explorer.  It did not show the presence of any new disk drive or partition.  In classic view, Control Panel > System > Hardware > Device Manager reported no problems for the IEEE 1394 Bus Host Controller.

There seemed to be a lot of people who had had problems getting their video from the ZR800 to the computer, and a lot of different possible solutions.  Cari suggested making sure that I had installed the Firewire drivers when I installed the computer's motherboard.  Unlike Hugo, though, in my case the camcorder was not listed under Imaging Devices in Device Manager.  I tried 3banana's suggestion of uninstalling the 1394 device in Device Manager (with a right-click) and then plugging in the Firewire cable and (still in Device Manager) choosing Action > Scan for hardware changes.  It added back the 1394 controller and also added a 1394 adapter under Network Adapters.  But unlike 3banana's outcome, mine still didn't detect the video camera.  Attempting to apply his/her suggestion nonetheless, I right-clicked on the 1394 controller and chose Update Driver > Install from a list or specific location > Next > Include this location:  C:\Windows.  But it wouldn't accept that location.  GavHendo recommended using a VGA to USB adapter, but that seemed unnecessary if not impossible.  Someone pointed toward a Microsoft webpage that said a Vista update solved the problem; but I wasn't using Vista.  AtomicProductionsNZ recommended a registry edit for those who were using 64-bit Vista.  Sharkbyte had a non-registry solution that involved copying files named 1394 from WinXP to Vista.

In a post that sounded like it might apply to my WinXP situation, CMahendra observed that his/her Sony Handycam's manual instructed the user to use only a 4-pin to 4-pin Firewire cable.  I hadn't known there was more than one kind.  Checking the jacks and the cable ends, I confirmed that my pins were not bent (unlike those of Brainstrain).  But -- surprise, surprise! -- my cable did have four tiny pins on the camera end, as needed to fit the camera, but it had six contacts, three on each side, on the computer end.  And that's what my computer's motherboard's Firewire connected needed.  So if the Sony and Canon were using the same Chinese manufacturer of Firewire-related hardware, then possibly a more helpful Canon manual would have said what Sony's manual said about using four pins on both ends.  I didn't have a 4-to-4 Firewire cable or jack.  A search for that kind of cable confirmed that it existed and could probably be had for about $7-10 total.  It would have the same kind of small male plug on both ends.  Another possibility was just to buy a 6-to-4 adapter.  I decided that adapters, sticking out, can sometimes serve as a lever to break a jack, and also that sometimes adapters introduce new issues, so I thought the cable would be the better way to go.  For the four-pin jack on the computer end of the cable, I already had a Rosewill RC-501 adapter sitting around, and it had both the larger 6-pin and the smaller 4-pin jacks.  So all I really needed was the cable.  But Battman540 said that the four-pin approach did not solve the problem for him.  In an approach that wouldn't work for me (because my Firewire connector was on my motherboard), Reedvideo said s/he removed the Firewire card, restarted the computer, uninstalled the controller from Device Manager, shut down again, reinstalled the fireware card, and start back up, and then it worked.

In my playing around with it, I noticed something else.  When I connected Firewire to the WinXP desktop, I got the DV-IN indicator flashing at the top of the camera's LCD viewscreen.  But when I connected Firewire to a Ubuntu (Linux) desktop (also to a motherboard Firewire port), it wasn't flashing; it was solid on.  I dusted off a two-year-old post I had written when I was first discovering dvgrab in Ubuntu.  Following its advice, in Ubuntu's Applications > Accessories > Terminal, I typed "sudo chmod 666 /dev/raw1394" and then "dvgrab."  And just like before, it started capturing video right then and there.  I killed Terminal, used the controls on the camera to rewind the tape to the start, and tried it again.  As it had done two years earlier, dvgrab saved the camera's output into a set of 1000MB files, each not quite five minutes (4:51) long, named dvgrab-001.dv, dvgrab-002.dv, etc., in my Ubuntu home folder.  It hadn't previously occurred to me to check out dvgrab's options, but now typing "man dvgrab" in a separate Terminal session revealed that I could have told dvgrab to start a new file whenever a new recording started.  It looked like I could also have specified the length of the files as well as their format (avi, mpeg2, etc.).  There was a boatload of options, actually.  (Those without an Ubuntu installation might be able to do this with an Ubuntu Live CD.)

Anyway, as suggested in another two-year-old post, I didn't bother investigating the current state of Ubuntu video editing tools at this point; instead, I moved the .dv files over to the Windows machine, converted them to .avi with VideoDub, and combined and edited them in Adobe Premiere Elements.  So Ubuntu's dvgrab was the answer for the moment; it worked with my 4-to-6-pin cable where Windows XP would not.  This posed the question of whether there would have been a way to use dvgrab on a Windows machine, if I hadn't had an Ubuntu machine.  I discussed that question in a separate post.