Wednesday, May 06, 2009

Retrospect restore failing, network flaky – a hardware problem?

Maybe it’s the incipient dementia, but I’m having a hard time telling hardware problems from software problems these days.

It didn’t used to be this way. Even ten years ago if something went wrong, it was almost always a software problem.  The only exception was the slowly dying drive, but you could usually hear that going.

Now, who can say? Systems can run hot, solder isn’t what it used to be, and quality is an issue everywhere. Software is very complex now, and software changes can make latent hardware issues into active problems.

It’s also true that hardware is much older than it used to be. Moore’s Law failed a while back; my 6 yo XP box just keeps on being useful. I don’t ask much of it since we’re largely an OS X shop, but it’s good enough for basic work.

It all adds up. Oh, and the dementia too. Being an OS X shop means it’s been a very long time since I’ve had to think about BIOS age, memory maps, interrupts, and the like.

My latest experience is a case in point. It began when I replaced my old USB backup drive and enclosure with a LaCie 1TB drive/enclosure. My old XP box wouldn’t boot! It simply hung in early startup. I found I had to turn the drive off to boot, then turn it on again when XP was up. Then it all worked.

Ominous.

Next I started getting oddball network problems. I beat them back and things seemed to settle down, but then a Retrospect Professional restore of a 50GB iTunes Library failed with a typically cryptic Retrospect error code of "-519". I had to throttle my 100 gbps network back to 10 mbps to get the restore to work.

That got my attention. I can’t live with unreliable backup/restore.

In some earlier testing I’d eliminated cabling and my Netgear gigabit switch as contributors. So the problem lay in my 3 yo G5 iMac or my 6 yo XP box. Neither had had major software changes recently, so I bet on hardware. Since some network glitches had required power cycling the XP box I put my bet on that.

So I bought the Intel PWLA8391GT PRO/1000 GT PCI Network Adapter. It came from Amazon in about 2 days (free shipping!) in a plain package with a single DVD. Nothing fancy here.

So I swapped out the old 100 mbps SMC NIC for the Intel and rebooted and got a … turquoise screen.

Nothing. The drives were spinning, the CPU fan was spinning, but the system locked pre-BIOS! I pulled the card, restarted and things looked good.

So then in desperation, I moved the NIC to a different slot, and then rebooted and looked through all my BIOS settings. I made one change. The BIOS had previously been set to manage devices, now I set it to ignore PnP devices and let the OS handle them.

So I did two things at once – but I wasn’t trying to identify the root cause. I wanted the thing to work.

I then restarted with the LaCie 1TB drive attached and … it worked.

I’m really getting tired of figuring this stuff out.

The Intel adapter requires drivers, so I installed from the CD and … wait for it …. found a bug.

Immediately.

It’s a gift.

The installer bombed with a poorly written complaint about my “S:” drive.

Turns out I’d mapped the “My Documents” folder to a (now inaccessible) network share that I’d mapped to the “S:” drive. So of course there was nothing there. Even when I dismounted the “S:” drive, the installer still bombed. I had to reset “My Documents” to the default setting.

So, pretty dumb coding on the installer. On the other hand, once the install completed, I was impressed by the diagnostics suite. The NIC, cabling and network passed every test.

These hardware diagnostic tests are critical in the modern era, so this utility was a definite plus.

I then repeated the restore that had previously failed at the 200MB mark. This time it went easily past 1GB, with a throughput of about 830 MB/min (probably limited by the USB drive).

So I think my problem is solved. Was it really a problem with the IDE slot? Or the old NIC? Or the 1TB USD peripheral causing some problem with the 8 yo BIOS? Was the fix the new card, changing the BIOS settings, or moving to a new slot?

I don’t know.

Don’t care.

My network’s much faster now…

Why I'm downloading Windows 7 RC tonight ...

It works on VMWare -- and it's free ...

VMware: Team Fusion: Windows 7 on Mac with VMware Fusion: A Practical Guide Revisited

... More important, I am excited that the Windows 7 Release Candidate is the easiest way for you to try out Windows on your Mac for FREE (at least until the beta expires). That’s right, you can download Windows 7 Release Candidate through July 1st and it’s free to use until it expires on June 1, 2010...

The VMWare post has more details, but basically the RC works fine with some trivial and standard configuration options.

A very nice surprise for me. I've been tracking Windows 7 from a distance, but primarily as my way to avoid Vista (Windows 7 is Vista 2.0 of course, but I'm good with that). In the meantime I've had Parallels 1.x and Windows 2000 (!) running on my MacBook for about 2 years (man, does Win2K ever boot fast on that machine.) This setup worked for the handful of times I've needed it, and the two take up very little CPU or disk space. Windows 2000, of course, is essentially immune to modern viruses.

That's a good setup and it cost me nothing but Parallels 1.x since I have several unused Win2K licenses. It probably won't work on 10.6 though, and I'm about due for a new iMac.

So I'll put my unused VMWare license on the new machine, install Windows 7 RC, and be good for a year or so. Then I can decide if I want to buy Win 7 or regress to Win2K ...

(I wonder if I need to get more than one copy of Win 7 RC, in case I put it on two Macs ...)

5/26/09: Updated to remove a stupid mistake where I confused 2009 with 2010. The RC1 download is good for one year. That's just fine.

Tuesday, May 05, 2009

iPhone incompatible with old auto adapter? Salvation from Griffin

I like Griffin stuff, so I was willing to take a gamble on the just released Griffin Firewire to USB Charge Converter for iPod and iPhone 3G.

In short, it works. One of the truly infuriating iPhone aggravations has been ameliorated.

The $20 device is a bit bigger than the proverbial postage stamp, about an inch square. It's quite light. The standard iPhone/iPod adapter is the modern friction-only style, no lock feature. (I'd prefer the positive lock for this use, but Apple has moved away from them.)

I plugged one end into my SONY car stereo with iPod adapter cable and the other end into my 3G iPhone. The iPhone began charging. More importantly, the kludgy but useful iPod control software works, and the sound quality really is better through that cable than through the AUX in mini-jack connector.

I did get an error message from my iPhone saying the device was not compatible with the iPhone and offering to reduce audio interference by putting my phone into airplane mode. This is not related to the Griffin converter, I get this message without it. It's different from the "can't charge" message -- it's saying that the radios built into the iPhone can cause interference with many devices not built for the 3G iPhone. In my case there's no hum or other problem in standard mode.

The adapter does make the cable to iPhone connection long and somewhat fragile. It would be easy to whack the end of this longish lever and injure a connector. It would be best used when the iPhone is securely mounted.

It's probably not worth buying this device to extend the utility of a firewire charger -- it costs almost as much as a Griffin USB charger and cable. It's really made for an automotive head unit, and it works on mine.

Note that Griffin makes no claims that the automotive head unit controls and audio inputs will work -- only that charging will work. I took a chance that everything would work, and it did.

Lost phones: advice for everyone

Although this article is written about a lost iPhone, it's really applicable to all phones: Six things I learned from losing my iPhone 3G.

Be sure to read the comments as well. I'd already followed most of the recommended practices, but I hadn't checked with my home owner's insurance to ask what it would cost to insure the phone against loss. One comment mentioned their policy increase was only $10 a year, another said the deductible was prohibitive. Note that most high end phones cost about $500 to replace unless your contract is nearing its two year renewal date. (I think for AT&T in Minnesota they'll provide the new phone subsidy if the renewal date is less than 4 months away).

I didn't realize that under some conditions AT&T will mark a phone as stolen, and may be able to retrieve it if someone tries to use it with a new account.

I photographed a business card and turned it into my wall paper. Dull, but effective. I also implemented the "delete data on 10 password retries", but some of us have young children who may try to hack a phone. If you implement this be sure to have sync regularly.

Monday, May 04, 2009

Apple's iPhoto and MobileMe photo blunder: when full quality isn't.

Adam Engst is far too kind to Apple in this article (emphases mine) ...

TidBITS Media Creation: How to Share Full-Quality Photos via iPhoto

A reader recently sent me email asking why sending a photo via email using the "Actual Size (Full Quality)" option in iPhoto resulted in a photo that was significantly smaller than the size of the photo within iPhoto...

A quick test on my system confirmed his results. My Canon PowerShot SD870IS's test photo started out at 3.1 MB and 180 dpi before dropping to 1.7 MB and 72 dpi. When I opened both the original and the reprocessed photos, Preview's inspector window showed the change in dpi and file size, though the dimensions of the photos were indeed identical.

... iPhoto always compresses photos sent via email to reduce the file size...

... posting the photo to your MobileMe Gallery won't help either, since iPhoto compresses uploaded photos there as well, even when you use the Actual Size option in the Advanced preferences for a MobileMe Gallery album...

... is an EmailCompressionQuality key in the com.apple.iPhoto.plist file that's set to 0.75 ... When I bumped it up, the size of photos sent via email did increase, but when I set it to 1.0, the file size nearly doubled from the original....

Arggghhhh.

Adam is glossing over some key points in an understandable effort to be sweet to Apple.

The problem is not that "iPhoto [always] compresses photos", it's that iPhoto is decompressing the original JPEG (SD870 is JPEG, not RAW), then recompressing it at a severe .75 JPEG compression factor. The decompression/recompression factor is why, when Adam moved the quality index to 1, the resulting JPEG was twice as big as the original. (You'll see the same thing with any image managed this way.)

This is a big deal for photo geeks. Try putting an image through four sequential JPEG 0.75 save/edit cycles and you'll get a mess. When I put "full quality" images on Picasa Web Albums or SmugMug one of the things I get is a high quality backup of my image. We now know that's not true of MobileMe -- it only looks that way.

The discovery that "full quality" images posted on MobileMe are being put through the same decompress/recompress cycle, while being sold as "full quality", ought to be red meat for a lawyer. Anyone know of a hungry lawyer taking charitable contributions for yet another Apple lawsuit? I don't care about winnings, I just want them to suffer.

For my part I'm going to give this a try with Google's Picasa Web uploader and see what I get back. I don't use MobileMe, and I'm not likely to start now.

Incidentally, a more subtle version of this stupidity occurs in Aperture. If you import a JPEG image into Aperture, don't apply any edits, then export it from Aperture using a standard JPEG setting with quality 1 you'll see the same (pointless) decompression/recompression at work.

Update 5/26/09: Apple doesn't apologize, but it effectively confesses to the blunder. No promises of a fix, however.

Sunday, May 03, 2009

Yikes! Disastrous iTunes 8.1.1 AppleScript bug!

Wow.

This iTunes 8.1.1 bug is probably the nastiest bug that's bitten me in years.

I have long used an AppleScript to delete the first 'n' characters from an iTunes column string for all selected columns.

In iTunes 8.1.1 it ignores the selection, it processes all the items in a playlist.

So about 300 items have lost the first few characters of their name.

I'll have to restore from backup.

Update: Well, isn't that sweet. My backups appear to be good, but my restores are failing with a Retrospect error code of "-519", which means network error. I have reason to suspect this is actually a hardware error on the old Windows XP machine that runs my Retrospect Professional backup server.

Looks like this is going to be one of those days.

Update b: I dropped the XP to 10mbps and rebooted the XP box and the iMac. The backup is now crawling along; it will take about 12 hours (!) to complete if it continues. I'll delete all the AppleScripts associated with iTunes and see if can figure out if this is a known bug.

As for the networking issue -- it's not the first odd networking problem I've seen lately. Sad thing is this is just as likely to be hardware (switch, XP box, iMac) as software! If Retrospect 8 were in better shape (still no PPC version!) I'd probably buy a modern iMac and get rid of the XP box.

Update 5/4/09: The 45GB restore at 10 mbps took about 12 hours, but it worked. Interesting lesson about modern apps -- the script bug only knocked out a few bytes of data distributed across about 300 MB of music, but I had to restore all 45GB.

So now I have to address the network problem that blocked restores at 100 mbps. In the past I'd have been confident this was a software bug in either the iMac or the XP box. Nowadays nothing's so simple. It could be an emergent bug. It could be an XP BIOS problem triggered by the 1 TB external USB drive, a drive that's far out of spec for that old system. It could be a subtle motherboard problem on the iMac -- the G5 iMac line is notorious for mb failures (one of Apple's crappiest products).

I've already ruled out switch or cable problems.

I'm going to take a semi-informed gamble and install a new 1 gbps Intel NIC in the XP box and retest. If that doesn't work I'll have to start testing the iMac for a motherboard failure.

Update 5/6/09: New NIC worked, but not exactly sure why.

Thursday, April 30, 2009

Testing Firefox 3.5b4

Firefox 3 has been very slow on a single CPU PPC G5 iMac. It quickly pegs my CPU.

Happily Safari 4beta has been a great improvement over Safari 3, and Google's Safari (4) support is finally respectable. So I've been using Safari -- really for the first time. (Camino runs into too many Google oddities, otherwise I'd use it over FF 3. We do use Camino on an ancient G3 iBook running 10.3 -- and it's marvelous there.)

Now, however, James Fallows reminds me that FF 3.5b4 is a real option. I've started testing ...
Welcome to Firefox 3.5 Beta 4

... This release is being made available for testing purposes only. You should read the release notes before getting started.

We want to hear all of your thoughts about this beta, especially if you encounter broken sites or other web weirdness. Drag this feedback button onto your bookmarks toolbar and click on it when you have something to tell us...
I know how to test it.

First impressions? It's fast and responsive so far, and my CPU is running at about 35-50% -- which is about the same as Safari. The mouse wheel scrolling is particularly smooth, and Macintosh copy/cut shortcuts work in the rich text editor (not sure that's new, I switch platforms so often it's all a bit automatic).

The release notes mention ...
  • There are Gmail oddities, fix by refresh
  • Uses Tracemonkey - so faster Javascript, maybe fewer memory leaks
  • Location aware browsing (I'll turn it on of course)
  • HTML 5 offline storage (like webkit and chrome)
Updates to come, but this feels like a good one.

Update: Google Gears is not compatible with the beta (unsurprisingly). So you'll lose offline Gmail if you install. Also I found one bug. In a multi-user OS X machine the install reports a privileges error if another user is active, even if FF is not in use in the the other session.