I’d been working quite happily with VB6 and Windows Vista for several days, when, this morning, I ran head long into a very disturbing problem

I had a class open, and was trying to enter:

Private myvar as Boolean

but as soon as I hit SPACE after the AS, long pause and CRASH.

Every time. Completely consistent.

Poking around in the Application Even log yielded this:

Faulting application vb6.exe, version 6.0.81.76, 
time stamp 0x3592011f, faulting module OLEAUT32.dll, 
version 6.0.6000.16386, time stamp 0x4549bd95, 
exception code 0xc0000006, fault offset 0x0000d921, 
process id 0x17e4, 
application start time 0x01c7cade79735543.

Which seems to clearly point at OLEAUT32.DLL and, I’d guess, the TypeLibrary loading and handling stuff that VB6 makes heavy use of for Intellisense purposes.

My first thought at this point was, holy crap! I’m gonna have to go back to XP to be able to get a stable VB6 environment!

I googled a bit and came up empty.

Then, I heard this voice in the back of my head (no, not those voices, one of the rational ones<g>) that suggested checking the SP level of VB6. Sure enough, I hadn’t installed SP6 (remember, I just repaved this machine a week or so ago).

Interestingly, MS’s update gizmo hadn’t suggested SP6 as an update. Guess their most popular language doesn’t rate high enough on the important scale.

At any rate, I installed SP6 and tried the same coding, worked perfectly.

Lesson of the day, always make sure you snag all the SPs when repaving.

Well, at least that’s one minor panic attack avoided!

And now, from the world of unbelievably arcane email minutia, comes this:

In GroupWise 7.00, create a new message, enter some text and bold a few bits, thus making the message HTML format.

Now, add an attachment, say a bitmap.

And finally, add another attachment, this one an HTML file called Text.htm.

Don’t send, but rather, just close the mail window, at which point GroupWise asks if you want to save the draft. Save it to some folder.

Now, go to that folder and open the email. Your Text.htm attachment has evaporated! The other attachment should still be there.

Same thing happens if you were to just send the email, which is quite handy when the file you wanted to attach is actually called “Text.htm”.

Turns out, this would appear to be a bug in the way GroupWise handles attachments and HTM emails. Internally, they save the HTM body of the email as a FILE attachment called, you guessed it, TEXT.HTM. In some cases, as when you simply send the email directly, GroupWise properly HIDES that Text.htm attachment from attachment enumeration. But in other cases, such as when you open that saved draft message and send it, GroupWise fails to hide the attachment properly.

Which means that if you’re enumerating attachments in an outgoing GroupWise email, you need to be aware of that or you might end up processing the body of the email as if it were actually an attachment. That may or may not be something you want to do.

At least with Outlook, the HTML body of the email is flagged in such a way that it doesn’t show up when enumerating normal attachments. You have to go out of your way to retrieve the HTML or RTF body text of a message.

Gotta love those gremlins!

I’d been meaning to upgrade/backup my TIVO hard drive for ages now (it’s actually more than 4 years old, and has been running almost continually in that time).

The prospect was a tad daunting, esp after looking through the Hinsdale How to Guide. I’m not a huge Linux gearhead, but I can find my way around in a pinch. Still, at 26 pages, there’s a lot to absorb there.

In the end, after a good weekend of various false starts, I’m happy to say I now have a 370 hour Tivo with a nice, fresh, cool-running, ultra quiet Western Digital 320gb hard drive. And I was able to preserve all my existing recordings to boot! I probably should have taken the time to setup the FTP daemon or telnet access while the drive was out, but I’ve just run out of time for now.

However, for those considering attempting this, I thought I’d document a few of my false starts to hopefully keep you from traveling down those same paths.

First, the Hinsdale guide contains great info on removing the cover of the TIVO, removing the hard disk, what hard disks you might want to use to upgrade (I happen to prefer the newer Western Digital drives), and the commands you’ll need to move TIVO drive images around.

Also, I’m writing this from the standpoint of upgrading a single drive Tivo with a new, BIGGER single drive. If you’re dealing with a dual drive Tivo, or just want to add a second drive to your Tivo, this page probably won’t help you much.

Steps 1-6

These steps are all spot on and will get you to the point of having the TIVO drive in your PC. Make sure you have a bootable CD of MFSTools (or copy it to a bootable USB drive like I did).

Of course, having a whole step like:

Buy a Tivo

and

Buy a Torx Screwdriver

is a tad overkill, but at least they’re clear on the subject.

Step 7

This is all about making a short and sweet backup of your original TIVO disks. DO THIS!  A VERY IMPORTANT POINT TO NOTE is that when mounting your existing FAT32 drive (that you’ll use to write the backup to), they indicate to use the commands:

mkdir /mnt/dos
mount /dev/hda1 /mnt/dos

Take special note of that hda1. That’s hugely important! I accidentally entered /dev/hda (missed the “1”), and totally trashed the drive I wanted to use for the backup. I had to reformat it to get it back.

The backup command in Step 7 worked just fine for me, but be sure you attempt Step 8 (Restoring the MFSTools backup) before assuming it is a valid backup! See below.

The backup command I used (with a Series 2 TCD24004a Tivo) was:

mfsbackup -f 9999 -6so /mnt/dos/tivo.bak /dev/hdX

where X is the drive ID of the original Tivo drive you hooked up to your PC, typically “hdc” or “hda”.

FALSE START: I originally wanted to try performing the backup on a scratch drive I had lying around. Ie, backup and restore a scratch drive AS IF it was a Tivo original drive, just for practice.

Attempting to use MFSbackup on a non-Tivo drive will just end up giving you a read-block error, so that was no go from the start. Then, I came across the dd command a little later on in the backup section, so I tried it:

dd if=/dev/hda of=/dev/hdb bs=1024k

That ran for hours and hours and never completed. I stopped it after about 8 hours. One reason is that the “source” drive was a FAT32 formatted 120gb drive. Apparently, the dd command is very slow with large drives like that.

Step 8

As I mentioned above, you definitely want to verify that the backup actually worked. It failed once for me (because I didn’t get the command quite right), but it didn’t tell me it was a bad backup.

One point that the guide mentions and I’ll stress is to unmount (using umount -f -a -r) before rebooting and then powering off the machine.

You’ll want to test the restore of the quick backup using the command:

mfsrestore -r 4 -s 127 -bzpi /mnt/dos/tivo.bak /dev/hdX

where X is the letter of the NEW drive that will be going into your Tivo.

FALSE START: there is a paragraph in the guide that starts with “Note for those with already tested image” that basically indicates you should be able to perform a particular restore and automatically expand the Tivo in one shot, if you’ve already tested restoring the image. This didn’t work for me. The command they show to use is:

mfsrestore -s 127 -xzpi /mnt/dos/tivo.bak /dev/hdX

Note the missing -r 4 and the -xzpi instead of -bzpi.

I’m not sure what the difference is, but I do know that the Step 10 instructions below DID work properly.

Step 9

Put the new Tivo drive (that you just restored a backup onto), into the Tivo and try to boot it. This is just to verify that the backup and restore worked.

After working with PC’s so long, it’s a bit strange to work with a device that has no OFF button. To turn on the TIVO, you plug it in. To turn it off, you unplug it!

Step 10

I wanted to preserve setup and recording so I browsed through to the proper spot in Step 10.

Once I hooked the Original TIVO drive AND the new Upgrade Drive (had to take it back out of the Tivo box from Step 9), I rebooted to MFSTools and used this command:

mfsbackup -Tao - /dev/hdX | mfsrestore -r 4 -s 127 -xzpi - /dev/hdY

where X is the letter of the original TIVO drive and Y is the letter of the new Upgrade drive.

Note that the -r 4 is here from the part of Step 8 above that worked. I’m not sure of the difference between -xzpi and -bzpi. ANy ideas?

This command took a LONG time (for a 40hr Tivo, it took about 8 hours), but it does show progress (unlike the dd command), so I knew it was working the whole time).

FALSE START: I thought it might be good to grab a backup of the WHOLE Tivo drive and then restore that, so I tried this command, after remounting my FAT32 disk I was using to save backups:

mfsbackup -Tao /mnt/dos/all.bak /dev/hdX

It ran for a while but then failed for no apparent reason. I probably just don’t have the flags right, but it was 12:30am, so things were getting bleary.

Summing up…

In the end, the single step backup from original disk->restore to new disk worked just fine. Put it back in the Tivo, booted, and now I have plenty of space for Sesame Street and Stargate.