Zunepocalypse

The maker of the beloved HD DVD format is also the maker of the original 30 gig Zune device. That is the Zune 30 was based on the Gigabeat player. I mistakenly thought it was a Samsung product. Regardless, because the Zune hardware was a rebranded Gigabeat, it goes without saying that the Gigabeat players had the same issue.

I have some friends in the data services industry that told me some server products suffered the same issues. So despite the despite the visceral opinions of Appletell, this wasn’t so much a Zune or Microsoft related screwup as it was a technical glitch suffered by multiple hardware devices and server products. Accordingly, this was just a common programming glitch - an infinte loop error.

Thanks Gizmodo

Yesterday, on ZUNEPOCALYPSE, one of my three Zunes, the original 30 gig model succumbed to the infinite date loop error. This morning, as prescribed by the Zune team doctors I drained the battery and then hooked it up to my PC and whaddya know … it works.

Zunepocalypse averted.

 

IMPORTANT UPDATE! Now that ZUNEPOCALYPSE is over, I guess there is no more reason to post on this page. The past 24 hours have been a whirlwind of activity … waiting patiently for the infinite loop error to end. Well it has. Its been fun.

itsnotabigtruck over at the Zuneboards forums has explained what the problem is/was. Its really not that big of a deal and understandable that it was missed (the original Zune hardware was outsourced).

Source

After doing some poking around in the source code for the Zune’s clock driver (available free from the Freescale website), I found the root cause of the now-infamous Zune 30 leapyear issue that struck everyone on New Year’s Eve.

The Zune’s real-time clock stores the time in terms of days and seconds since January 1st, 1980. When the Zune’s clock is accessed, the driver turns the number of days into years/months/days and the number of seconds into hours/minutes/seconds. Likewise, when the clock is set, the driver does the opposite.

The Zune frontend first accesses the clock toward the end of the boot sequence. Doing this triggers the code that reads the clock and converts it to a date and time. Below is the part of this code that determines the year component of the date:

Code:

year = ORIGINYEAR; /* = 1980 */

while (days > 365)
{
    if (IsLeapYear(year))
    {
        if (days > 366)
        {
            days -= 366;
            year += 1;
        }
    }
    else
    {
        days -= 365;
        year += 1;
    }
}

I’m not a programmer, but I understand that all electronic devices do some kind of math to figure out what the date is. In fact Blackberry had to release a patch at the beginning of last year to account for a similar error. Although its unfortunate it is entirely understandable that this kind of thing could be overlooked. I guess its better than exploding batteries.

On December 31, 2008 at 12:00 a.m. PST All Generation 1 Zune 30s went dead. This was THE ZUNEPOCALYPSE. Unfortunately, that is an overstatement as the error, which was hidden in a driver in a piece of hardware which controlled the internal clock will disappear as it came at 12:01 a.m. GMT on January 1, 2009.

That is it. That was the Zunepocalypse.

Click here for the offical Zune statement

Click here for the official Zune Team fix.