Slashdot Log In
Microsoft Issues Workaround For Zune Freeze
Posted by
kdawson
on Sat Jan 03, 2009 02:28 PM
from the discharge-before-you-leap dept.
from the discharge-before-you-leap dept.
UnknowingFool writes "As a followup to the Zune New Year's Eve meltdown, Microsoft has issued a workaround for what some users have correctly guessed was a bug caused by a leap year. To recover from the problem, let the Zune drain the batteries and restart it after noon on January 1, 2009. Many sites are reporting that Microsoft has 'fixed' the issue, but technically all Microsoft has done is to ask users to wait out the conditions that triggered the bug. Unless a software patch comes out, Zunes will suffer the same problem again in four years." Reader ndtechnologies adds, "According to posts in the Toshiba forum at anythingbutipod.com, the same bug that shut down millions of Zune 30's also affects the Toshiba Gigabeat S. The Zune 30 is based off of the Gigabeat S series and was co-developed by Microsoft with Toshiba."
Related Stories
[+]
IT: Microsoft Zunes Committing Mass Suicide 785 comments
jddeluxe writes "There are multiple reports springing up all over the internet of a mass suicide of Microsoft 30GB Zune players globally. Check Zune forums, Gizmodo, or other such sites; the reports are spreading rapidly, except apparently to the Microsoft official Zune site."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
It probably won't last another 4 years (Score:5, Funny)
Re: (Score:2)
After all the hell that people give Microsoft for not supporting a 9 year old OS? Yeah, right.
Besides, I know people who still have first generation iPods.
Re:It probably won't last another 4 years (Score:4, Insightful)
And if they broke, would they expect apple to fix them?
Suppose instead of this being Zune's firmware it was a microwave you bought 5 years ago. Would you have any claim to have it fixed (out of warranty, etc).
Parent
Re:It probably won't last another 4 years (Score:5, Insightful)
Parent
Re:It probably won't last another 4 years (Score:5, Informative)
My microwave has a firmware bug. After I heat something, if the next button on the keypad I press is anything other than "Reset", it locks up. It's incredibly irritating (since I'm usually putting something else in and trying to enter a new cooking time). That said, the microwave cost under $50...
Parent
Re: (Score:3, Insightful)
If I bought a microwave and it did that, I would probably never buy from the manufacturer again. Maybe if they apoligized for making such a crappy product and it was shown they now don't make defective products anymore. Though even then, if it was the exact same product as another mfg with the same chance for defects and such, I would buy the other guy's product.
Your bar is too low. If you bought it as a charity case or because you want to help out local / new businesses I could understand, but putting up
Re: (Score:3, Insightful)
Because software does not wear out?
Re:It probably won't last another 4 years (Score:5, Insightful)
This is software, the fault was there when it was purchased.
Parent
Re:It probably won't last another 4 years (Score:5, Informative)
In UK law at least this is a significant difference... you can never tell in the US though.
Parent
Re:It probably won't last another 4 years (Score:5, Insightful)
And if you look at the bug in the code [pastie.org] (line 259) it's atrocious. Something a junior programmer would be embarrassed about.
When days is 366 it causes an infinite loop. And also note that simply changing line 263 to use 365 causes a different bug. So the whole approach is wrong. It ought to simply be
while (days > daysInYear(year))
{
days -= daysInYear(year);
year += 1;
}
Parent
Re:It probably won't last another 4 years (Score:5, Informative)
It ought to simply be
while (days > daysInYear(year))
{
days -= daysInYear(year);
year += 1;
}
Hey, c'mon now; programmers are almost universally judged by their bosses by the number of lines of code they produce. The (buggy) MS code used 16 lines to do what you did in 5 lines. Therefore, the original (buggy) code is considered more than 3 times better than yours. No programmer interested in a good professional career would write code so simply and obviously correct.
This isn't really a joke. One a project a few years ago, I fixed several bugs by doing rewrites like yours, resulting in fewer lines of code. My record actually had a note indicating that I had negative productivity during that period, and my superiors had a real problem giving me a good review because of it.
Yes, I did find another job soon thereafter. But that wasn't the last time something like that happened.
(And I would probably save the first call of daysInYear(year) in a local variable, which would make the code a bit faster. But I could declare the local on a separate line, incrementing the line count, so it would look good to the line counters. ;-)
Parent
Re:It probably won't last another 4 years (Score:4, Informative)
Nah; most code-size measurements exclude comments, on the grounds that comments aren't executed by the computer, and thus aren't code. This puts subtle pressure on the programmers to not write comments, since this just takes time that leads to being behind schedule.
It's hard to imagine any rating system that's more screwed up than the system used in most companies to rate the output of their programmers. If they were consciously trying to sabotage the software, they probably wouldn't come up with any schemes nearly as effective as judging programmers by lines of code produced.
Parent
Re: (Score:3, Funny)
That's ok; since I am an American you could have used grams of fairy dust and it would have meant as much to me as pounds and pence.
Re:It probably won't last another 4 years (Score:5, Insightful)
You can get the microwave (or a tape recorder, or a VCR) fixed by a third party (or do it yourself) depending on what part has broken.
Only Microsoft can fix these firmware issues. If the source code for the firmware was publicly available, someone could fix the problem and distribute the fixed firmware for free or for money, but since it isn't, only MS can patch it.
Parent
Re:It probably won't last another 4 years (Score:5, Insightful)
Why are consumer electronics any different than any other product? Let's talk about items costing less than a laptop, so less than 2000.
Would you accept if your 5 year old ___ broke , was unfixable, and needed a new replacement?
You get the picture. Why are electronic manufactures exempt from shoddy products that don't have some sort of reasonable lifespan? Not wear and tear or dropping a product, just the product becoming unusable due to the product having some bug/feature to break it outright like the Zune.
As to a microwave, a 5 year old whirlpool oven broke on me and they no longer had replacement circuit boards. Whirlpool expects their products to have at least a 10 year lifespan. They pro-rated my equipment and sold a new unit, installed, for 33% of the cost. Now that's an acceptable solution for shoddy workmanship.
Parent
Re:It probably won't last another 4 years (Score:5, Insightful)
Because collectively we accept this. Sad but true.
Parent
Re: (Score:3, Interesting)
I think that at least part of the reason we collectively accept this has a lot to do with the idea that these devices are generally obsolete are at least significantly out of date after five years. If refrigerators and bicycles were making the same kind of advances as these other products, most people honestly wouldn't care if they junked out in five years. If your fridge was doubling in performance every 18 months, wouldn't you want to get a new one every six years or so to take advantage of the cost savin
Re: (Score:3, Informative)
If the microwave was only 5 years old and it broke down, you are covered in England and Wales by consumer protection laws if it less than six years old and it break down. Just as long as you can prove it was not accidental damage, your covered for a free repair. :)
Just something for the UK readers here. Covers anything electronic.
I'm not your average joe MS basher (Score:2, Insightful)
But I've got to say: this is just typical.
Re:I'm not your average joe MS basher (Score:4, Insightful)
I'm not your average joe MS basher
True enough; nowadays, the average Slashdot-dwelling MS basher will try to make some kind of reasoned, evidence-backed argument instead of just huffing loudly and saying "this is typical".
Parent
Nice! (Score:2)
Re: (Score:2)
Testing!?! (Score:4, Insightful)
You would think that a company the size of Microsoft would have the resources to have a few Zunes in QA with their clocks set ahead. But hey, there were no lessons to be learned from Y2K, right?
Re: (Score:3, Funny)
What's Y2K? Isn't it 1909 now....?
Re: (Score:2)
Clocks set ahead? Leap year is a really well-known edge case. There's no acceptable reason that setting the date to the boundaries in a leap year (including February 29, and the day before, and the day after) shouldn't be part of the standard tests.
Re: (Score:2, Funny)
Well, judging from the number of Zune owners who couldn't listen to music on new years eve, it probably should be.
What, all three of them?
The Source Code (Score:5, Informative)
Re: (Score:2)
Ok, it's been posted on every website and every forum about this issue on the entire Internet...
Is there any verification at all that this is actually the buggy code? Or did someone just pull it out of their ass? (I mean, obviously this code has the same bug, but is it the same code the Zune uses?)
Re:The Source Code (Score:4, Insightful)
Look through the function starting at line 249: this causes the infinite loop.
Assuming proper code management and version control they will probably branch off a release sometime for release in 2007, and in the meantime continue writing the next version, which may have been mostly finished in 2007 already but maybe only pass quality control in 2008 for release then.
And this piece of code had not been tested/reviewed properly apparently.
Parent
Cause of the Zune crash? Third party drivers (Score:2, Informative)
A quote from the ZuneBoards forum:
Amazing.. (Score:5, Funny)
The first step to fix any microsoft problem - reboot.
Instead of bothering with a fix (Score:5, Funny)
Wouldn't it be faster for Microsoft to simply give each of the 8 users a call and walk them through the work-around? If their numbers change in the next four years, they can simply notify Zune support.
Re: (Score:2)
[posting to undo moderation... I chose the wrong post]
Draining battery all the way (Score:3, Insightful)
Can't be good.
I've seen this in laptops leading to drastically decreased storage capacity.
My Experience (Score:5, Funny)
I hadn't turned on the Zune before I read about the problem, so I just left it off and turned it on the morning of Jan 1 and everything worked fine, no need to drain battery or anything.
The above is not an admission that I own a Zune, just what I theoretically would have done and the theoretical results, based on heavy pretend observations.
Out of curiosity... (Score:3, Interesting)
Why does a music player need to know the date or time at all?
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
Anything from month-to-month media rental (for example, the Zune Pass) to simply displaying the time like a watch (how many people do you know who pull out their cell phones to check the time? I know at least 4, and it amuses me to no end, but in any case a "current time" display was one of the most-requested features for the Zune 3.0 firmware).
All they've done (Score:4, Interesting)
... all Microsoft has done is to ask users to wait out the conditions that triggered the bug.
And considering that the bug only came to light two days ago, that's pretty good.
I speak from experience. I'm a tech writer, and I've written literally thousands of bug summaries for customer support web sites and release notes. (In 1999, I did almost nothing else.) Finding the problem, identifying a workaround, and getting it out to the public in such a short time is pretty impressive.
Presumably they're working on a patch, but they won't say they anything about it until it's ready to go. It's an ironclad rule that you never talk about these things before they're ready, not if you want avoid vaporware lawsuits. It should be obvious to anybody that creating, testing, and staging a software patch takes a lot longer than writing up a workaround.
Re:Can anyone explain this bug? (Score:5, Funny)
if (year % 400 == 0) hard_crash()
else if (year % 100 == 0) boot()
else if (year % 4 == 0) hard_crash()
else boot()
Parent
Re:Can anyone explain this bug? (Score:5, Informative)
Here's the actual buggy code [pastie.org].
The error is infinite loop in ConvertDays(), starting at line 249. The first loop does not cope with "IsLeapYear() == true" when "days == 366"
Parent
Re: (Score:3, Insightful)
Re:Can anyone explain this bug? (Score:5, Funny)
Typical MS. They're copying Apple again but this time too literally. :P
Parent
Re: (Score:2)
Here's the actual buggy code [pastie.org]. The error is infinite loop in ConvertDays(), starting at line 249. The first loop does not cope with "IsLeapYear() == true" when "days == 366"
Wow, that was pretty cool. Thank you.
Re:Can anyone explain this bug? (Score:5, Informative)
The function iteratively converts days into years. If there are more days left in the days variable than there are days in a year (365), then the days in that year are subtracted from the days variable and added as 1 year to the year variable.
It starts with year=1980, because the RTC counts days since 1/1/1980 (inclusive). For normal years, it subtracts 365 days and adds a year. After the first iteration, year is 1981 and days is the number of days since 1/1/1981 (inclusive). If the loop is currently looking at a leap year, then 366 days are subtracted from the days variable and 1 year is added to the year variable. So far the code looks like this:
while (days>365){
if (IsLeapYear(year)){
days-=366;
year+=1;
}else{
days-=365;
year+=1;
}
}
The crazy thing is that someone must have looked at the edge case in that code: The last day of a leap year. On that day, the above code fails by incrementing year once too often, because at the beginning of the last iteration, the loop test indicates that there are more days in the days variable than there are in a year, but there are not, because a leap year has 366 days. That edge case is caught by the second if:
while (days>365){
if (IsLeapYear(year)){
if (days>366){
days-=366;
year+=1;
}
}else{
days-=365;
year+=1;
}
}
The loop goes into the last iteration because of the loop condition which is on day short, then the IsLeapYear test selects the first branch, and instead of blindly incrementing the year and subtracting 366 days, there is an extra check if there are really more days left to make a full year...and then it fails to handle the only case where the code fails without that extra check. It should simply break the loop:
while (days>365){ // days==366 && IsLeapYear(year): end of calculation
if (IsLeapYear(year)){
if (days>366){
days-=366;
}else{
break;
}
}else{
days-=365;
}
year+=1;
}
(Matt's code always reduces the day count by 366. 1980 was a leap year.)
Parent
Re:Can anyone explain this bug? (Score:5, Informative)
{
if (IsLeapYear(year))
{
if (days > 366)
{
days -= 366;
year += 1;
}
}
else
{
days -= 365;
year += 1;
}
}
source code that caused the bug.
Parent
Re:Can anyone explain this bug? (Score:5, Informative)
In case you can't see how this fails: On December 31st in a leap year, days is counted down to 366 like it's supposed to, and then the IsLeapYear() test is true, but days>366 is not, so the loop body does nothing and the while becomes an infinite loop.
This code can not possibly have been accepted in any kind of code review. Someone would have pointed out that there are O(1) formulas for calendar calculations.
Parent
Re:Can anyone explain this bug? (Score:4, Insightful)
For that to happen, MS would have to follow standards. You know where this discussion will go.
Parent
Re: (Score:3, Informative)
Re:Zune 80 (Score:4, Informative)
Q: Why is this issue isolated to the Zune 30 device?
It is a bug in a driver for a part that is only used in the Zune 30 device.
Parent