Software Foibles: Once Again The Timestamp Causes Troubles

Some of you might recall, as contributing blogger Steve Leibson pointed out last New Year’s Eve, that Microsoft had a ‘bit’ of trouble with its first-generation 30GByte Zune portable multimedia players a few months back. The realtime clock driver code (reportedly obtained from Freescale) didn’t correctly handle leap year transitions, thereupon hard-locking up the Zune during the New Year’s Eve boot sequence…a problem that magically repaired itself one day later, and that Microsoft fixed for good via a subsequent firmware update.

The Motorola/Verizon Droid handset, which I recently mentioned as being Google’s latest-and-greatest Android operating system ‘poster child’, seems to have taken a page from Microsoft’s playbook. Many owners of the Droid, which has sold impressively well so far, complained about the system’s shoddy, erratic autofocus camera performance:

Here’s another example clip:

Some folks thought that vigorously cleaning the lens might mitigate the issue. Others, after experiencing a mysterious resurrection of proper autofocus behavior, put on their paranoid tinfoil conspiracy hats and theorized that Verizon had sent the handset a silent over-the-air update without first obtaining their permission. The real answer, alas, wasn’t particularly controversial. Here’s the scoop, direct from Google engineer Dan Morill:

There’s a rounding-error bug in the camera driver’s autofocus routine (which uses a timestamp) that causes autofocus to behave poorly on a 24.5-day cycle. That is, it’ll work for 24.5 days, then have poor performance for 24.5 days, then work again. The 17th is the start of a new "works correctly" cycle, so the devices will be fine for a while. A permanent fix is in the works.