Zune 30s Will "De-Brick" Themselves January 1st, 2009

[Jason Dunn]

<div class='os_post_top_link'><a href='http://forums.zune.net/408989/ShowPost.aspx' target='_blank'>http://forums.zune.net/408989/ShowPost.aspx</a><br /><br /></div><p><em>"Early this morning we were alerted by our customers that there was a widespread issue affecting our 2006 model Zune 30GB devices (a large number of which are still actively being used). The technical team jumped on the problem immediately and isolated the issue: a bug in the internal clock driver related to the way the device handles a leap year. The issue should be resolved over the next 24 hours as the time change moves to January 1, 2009. We expect the internal clock on the Zune 30GB devices will automatically reset tomorrow (noon, GMT). By tomorrow you should allow the battery to fully run out of power before the unit can restart successfully then simply ensure that your device is recharged, then turn it back on. If you're a Zune Pass subscriber, you may need to sync your device with your PC to refresh the rights to the subscription content you have downloaded to your device."</em></p><p>There you have it, straight from the official support thread on this problem. So for those of you who were about to take screwdrivers to your Zune and open them up, just wait until tomorrow and it should start working again. This confirms that it was in fact caused by this year being a leap year, and thus having 366 days. I'm shocked and disappointed that Microsoft allowed this bug to go un-checked - they have some of the longest and most grueling test cycles in the industry for their software, so I'm stunned that the Zune team allowed this to happen. The Zune is struggling enough as it is, this is a black eye it really didn't need. We'll discuss that issue in a couple of days...I have some thoughts about it.</p>

[priesmeyer]

http://forums.zune.net/408989/ShowPost.aspx


"they have some of the longest and most grueling test cycles in the industry for their software, so I'm stunned that the Zune team allowed this to happen.

Working for a software company, I can completely see how this error might go undiscovered. Yes, the Zune has a long and grueling test cycle - but for a device that's only been out for a little over 2 years and in development for LESS than 3 - it's kind of hard to simulate something that doesn't happen but every four years. And while it's easy to say "they should have thought of that and simply changed their clock" it's very easy to miss that.

Would you have thought about it before today? I dare say that most wouldn't.

And yes, this is a black eye the Zune doesn't need. But any rational person (read: no one who posts in blog comments) would acknowledge that this doesn't detract from the features of the device or of the Zune Pass service which has made great strides this year.

Please keep up the good fight against the iPod fans. This is a black eye the Zune doesn't need - but also one it doesn't deserve.

[NathanScott]

Well you know this is one bug that all of Microsoft will be testing for in the future! I still have to wonder if the Zune team will even bother fixing it...

Actually, it'll probably be placed on their to-do list just above Unicode support. :D

[Jason Dunn]

...it's kind of hard to simulate something that doesn't happen but every four years. And while it's easy to say "they should have thought of that and simply changed their clock" it's very easy to miss that.

Honestly? With the all the time-based DRM on the Zune (Zune Pass primarily) I would have thought that all sorts of date-based scenarios would have been tested in their Zune software emulators (which I'm sure they have). Leap years happen every four years, so I'd also have thought that they'd be part of any software development test cycle. And with all the focus around clocks and time with Y2K, you'd think serious checks and balances would have been put into play for all date-related issues.

I know what you mean - that it's easy to point fingers in hindsight - but the Zune team simply couldn't afford for something like this to happen. They need to execute better and faster than the competition.

At least no Zunes have shipped out to customers with viruses yet, like iPods have. :rolleyes:

[Chris Gohlke]

Confirmed, mine works fine this morning. Leap year testing is one of those obvious things you test for any time you have a date calculation, so it seems VERY sloppy for them to have missed it.

[David Tucker]

priesmeyer I understand what you're talking about since I'm also a software developer. While I completely understand how it was missed I disagree that it wasn't something they should have thought of. When you're developing software that deals with time, leap year scenarios should always be one of your primary tests since they tend to be the strangest behavior.

Bottom line is that they were careless and they're lucky it wasn't worse.

[Ed Hansberry]

Confirmed, mine works fine this morning. Leap year testing is one of those obvious things you test for any time you have a date calculation, so it seems VERY sloppy for them to have missed it.

But usually it involves making sure Feb 29 in handled properly, not Dec 31.

[David Tucker]

Not true...I ALWAYS have tests for the year rollover. They messed up, plain and simple. While it seems to be an obscure issue...its something encountered often in writing software.

[doogald]

I haven't written software in a long, long time, and it was never my primary responsibility. But if there was ever any kind of date calculation, etc. involved, I ALWAYS tested. I even included the fact that years like 1900, 2100, 2200 and 2300 are not leap years.

They just plain screwed up.

[Chris Gohlke]

But usually it involves making sure Feb 29 in handled properly, not Dec 31.

That would be one test, but honestly, I'd expect them to be using some automated test scripts that would run the bootup sequence using all potential variables. One variable would be date, probably using every potential date for the reasonable lifetime of the product.

Also, I'd expect failures to be a little more elegant. Just causing everything to stop is not an elegant failure. But until we know some more details on the exact nature of the failure (if it is publicized) we are just guessing.

[Janak Parekh]

Cause of Zune 30 leapyear problem ISOLATED! - Zune Boards (http://www.zuneboards.com/forums/zune-news/38143-cause-zune-30-leapyear-problem-isolated.html)

The problem occurs if days == 366 and IsLeapYear(year) is true.

Does Microsoft unittest this code? :(

--janak

[Rocco Augusto]

You want to know what annoys me the most about this situation? The Zune has a darn internal clock! Why can't we get that clock on the homescreen!?!?!? ;):p

I kid of course and my Zune is working again though my screen is still broken :(

[Jason Dunn]

Why can't we get that clock on the homescreen!?!?!? ;):p

You know that you can now, right? Just go into the options and turn it on. :)

[twinkyman90]

Confirmed, mine works fine this morning. Leap year testing is one of those obvious things you test for any time you have a date calculation, so it seems VERY sloppy for them to have missed it.


right. i'm sure you would have thought of this. C'mon people give the zune team a break. Nobody would have thought of this. Now they know to test for this sort of thing in the future. Like it's been said the 30's have only been out for a few years.

[David Tucker]

Yeah, I would have (or at the very least ensure that its in the test scripts) If I missed something like this on some of the systems I work on we could have delays which means money. I expect proffessionals to do their job correctly. Doctors can't afford to make 'little' mistakes. Lawyers can't. Not the good ones. Same rules.

[Janak Parekh]

right. i'm sure you would have thought of this. C'mon people give the zune team a break. Nobody would have thought of this. Now they know to test for this sort of thing in the future. Like it's been said the 30's have only been out for a few years. Sorry, I agree with David on this one. Where I work, code like this would absolutely be extensively tested. Date handling in particular is an area traditionally rife with problems. If you look at the link I posted, it's an elementary infinite loop problem. Good unittesting practices emphasize testing loop and conditionals to make sure all code paths work.

I've heard MS is good on testing in general, so all I can guess is that this slipped through the cracks. But I don't think even Microsoft would excuse themselves on this one.

--janak

[Chris Gohlke]

right. i'm sure you would have thought of this. C'mon people give the zune team a break. Nobody would have thought of this. Now they know to test for this sort of thing in the future. Like it's been said the 30's have only been out for a few years.

Yes I would have. I can surely understand that someone not in the computer industry might not think it is obvious. But if you are at all involved in programming/testing, it is standard practice to test for leap years when you have any date related calculations.

[Rocco Augusto]

You know that you can now, right? Just go into the options and turn it on. :)

Really? I pick the worst time ever to break my screen. Now I can't even utilize the one feature I wanted :(

[Ed Hansberry]

Seems the Toshiba Gigabeat had the same problem. http://www.engadget.com/2009/01/03/y28-zune-quirk-really-a-freescale-bug/

I wasn't aware the Zune was base, partially at least, on the PMC.

[Chris Gohlke]

And here is an article looking at the code block itself and provides an analysis showing exactly where the infinite loop occurs on the date check. http://www.toddhpoole.com/2009/01/02/a-look-behind-the-mass-zune-freeze/

[Jason Dunn]

I wasn't aware the Zune was base, partially at least, on the PMC.

Oh yeah, you bet - it's not a coincidence that the V1 Zune software looked and worked virtually identically to the PMC. It's all the same code base, though obviously since Zune V1 it has evolved since then...