Woke up this morning to a FROZEN ZUNE, fell asleep listening to music, when I awoke after midnight Zune was FROZEN.
Ne0Striker wrote: Melissamusic wrote: KarboMusic wrote: Melissamusic wrote:Please forgive my ignorance, were is it getting an illogical time/date stamp? KarboMusic wrote: Melissamusic wrote: KarboMusic wrote: Melissamusic wrote:I agree. Why would the Zune Player care what time or what day it is without any way to check the correct time? I would understand that the device could fail if there were a conflict in the times if connected to a computer but for it to fail on its own sounds kind of fishy. I think M$ is just buying themselves some time to come up with a fix. Believe it or not... There was a time when a device could contain an internal clock all by itself... Thats not fishy... So it has an internal clock, so if that clock is wrong then it would just show the wrong time. not crash a system. Not really, if a single line of code attempts an operation (dealing with dates/timestamps) and gets back a time/date that isn't "logical" there is going to be an unexpected result. (IE: Freeze) I'll try once more... There could be hundreds if not thousands of functions in the zune code and drivers that reference times and dates. It may be last modified timestamps on files, driver version times/dates, DRM, security, the list goes on and on. It only takes a single "operation" where a conversion, comparison etc. says "take the current time date and compare it to ____". When the code does this and there is suddenly a date that it doesn't expect to be possible, you have an error. Yes its simple to add code to prevent the freeze (could have been missed) but the scenario is completely plausible, more than plausible, its now a reality. Thanks for trying to explain it to me. Maybe I am just not getting it. But if the code is asking for a time check then what is it checking against if not the internal clock itself. And if you are saying is correct, which I am not disputing, then waiting one day will not fix it. The internal clock apparently doesn't know how to handle the extra day in a leap year. So when the internal clock reaches this 'strange day' it throws an error in the form of the freeze. once the internal clock goes back to a day it will recognize i.e. Jan 1 20XX then thigns to go back to normal operation
Melissamusic wrote: KarboMusic wrote: Melissamusic wrote:Please forgive my ignorance, were is it getting an illogical time/date stamp? KarboMusic wrote: Melissamusic wrote: KarboMusic wrote: Melissamusic wrote:I agree. Why would the Zune Player care what time or what day it is without any way to check the correct time? I would understand that the device could fail if there were a conflict in the times if connected to a computer but for it to fail on its own sounds kind of fishy. I think M$ is just buying themselves some time to come up with a fix. Believe it or not... There was a time when a device could contain an internal clock all by itself... Thats not fishy... So it has an internal clock, so if that clock is wrong then it would just show the wrong time. not crash a system. Not really, if a single line of code attempts an operation (dealing with dates/timestamps) and gets back a time/date that isn't "logical" there is going to be an unexpected result. (IE: Freeze) I'll try once more... There could be hundreds if not thousands of functions in the zune code and drivers that reference times and dates. It may be last modified timestamps on files, driver version times/dates, DRM, security, the list goes on and on. It only takes a single "operation" where a conversion, comparison etc. says "take the current time date and compare it to ____". When the code does this and there is suddenly a date that it doesn't expect to be possible, you have an error. Yes its simple to add code to prevent the freeze (could have been missed) but the scenario is completely plausible, more than plausible, its now a reality. Thanks for trying to explain it to me. Maybe I am just not getting it. But if the code is asking for a time check then what is it checking against if not the internal clock itself. And if you are saying is correct, which I am not disputing, then waiting one day will not fix it.
KarboMusic wrote: Melissamusic wrote:Please forgive my ignorance, were is it getting an illogical time/date stamp? KarboMusic wrote: Melissamusic wrote: KarboMusic wrote: Melissamusic wrote:I agree. Why would the Zune Player care what time or what day it is without any way to check the correct time? I would understand that the device could fail if there were a conflict in the times if connected to a computer but for it to fail on its own sounds kind of fishy. I think M$ is just buying themselves some time to come up with a fix. Believe it or not... There was a time when a device could contain an internal clock all by itself... Thats not fishy... So it has an internal clock, so if that clock is wrong then it would just show the wrong time. not crash a system. Not really, if a single line of code attempts an operation (dealing with dates/timestamps) and gets back a time/date that isn't "logical" there is going to be an unexpected result. (IE: Freeze) I'll try once more... There could be hundreds if not thousands of functions in the zune code and drivers that reference times and dates. It may be last modified timestamps on files, driver version times/dates, DRM, security, the list goes on and on. It only takes a single "operation" where a conversion, comparison etc. says "take the current time date and compare it to ____". When the code does this and there is suddenly a date that it doesn't expect to be possible, you have an error. Yes its simple to add code to prevent the freeze (could have been missed) but the scenario is completely plausible, more than plausible, its now a reality.
Melissamusic wrote:Please forgive my ignorance, were is it getting an illogical time/date stamp? KarboMusic wrote: Melissamusic wrote: KarboMusic wrote: Melissamusic wrote:I agree. Why would the Zune Player care what time or what day it is without any way to check the correct time? I would understand that the device could fail if there were a conflict in the times if connected to a computer but for it to fail on its own sounds kind of fishy. I think M$ is just buying themselves some time to come up with a fix. Believe it or not... There was a time when a device could contain an internal clock all by itself... Thats not fishy... So it has an internal clock, so if that clock is wrong then it would just show the wrong time. not crash a system. Not really, if a single line of code attempts an operation (dealing with dates/timestamps) and gets back a time/date that isn't "logical" there is going to be an unexpected result. (IE: Freeze)
KarboMusic wrote: Melissamusic wrote: KarboMusic wrote: Melissamusic wrote:I agree. Why would the Zune Player care what time or what day it is without any way to check the correct time? I would understand that the device could fail if there were a conflict in the times if connected to a computer but for it to fail on its own sounds kind of fishy. I think M$ is just buying themselves some time to come up with a fix. Believe it or not... There was a time when a device could contain an internal clock all by itself... Thats not fishy... So it has an internal clock, so if that clock is wrong then it would just show the wrong time. not crash a system. Not really, if a single line of code attempts an operation (dealing with dates/timestamps) and gets back a time/date that isn't "logical" there is going to be an unexpected result. (IE: Freeze)
Melissamusic wrote: KarboMusic wrote: Melissamusic wrote:I agree. Why would the Zune Player care what time or what day it is without any way to check the correct time? I would understand that the device could fail if there were a conflict in the times if connected to a computer but for it to fail on its own sounds kind of fishy. I think M$ is just buying themselves some time to come up with a fix. Believe it or not... There was a time when a device could contain an internal clock all by itself... Thats not fishy... So it has an internal clock, so if that clock is wrong then it would just show the wrong time. not crash a system.
KarboMusic wrote: Melissamusic wrote:I agree. Why would the Zune Player care what time or what day it is without any way to check the correct time? I would understand that the device could fail if there were a conflict in the times if connected to a computer but for it to fail on its own sounds kind of fishy. I think M$ is just buying themselves some time to come up with a fix. Believe it or not... There was a time when a device could contain an internal clock all by itself... Thats not fishy...
Melissamusic wrote:I agree. Why would the Zune Player care what time or what day it is without any way to check the correct time? I would understand that the device could fail if there were a conflict in the times if connected to a computer but for it to fail on its own sounds kind of fishy. I think M$ is just buying themselves some time to come up with a fix.
The internal clock apparently doesn't know how to handle the extra day in a leap year. So when the internal clock reaches this 'strange day' it throws an error in the form of the freeze. once the internal clock goes back to a day it will recognize i.e. Jan 1 20XX then thigns to go back to normal operation
i for one am in no way disappointed with my zune 30
have used it about non stop for about 2 years now
i am disappointed with this issue, and the way it seams to be being handled. an issue with leap year? after the y2k scare you wold think this would not be that big an issue
But if the code is asking for a time check then what is it checking against if not the internal clock itself.
Live dangerously. . . turn shuffle on!
Melissamusic wrote: Ne0Striker wrote: Melissamusic wrote: KarboMusic wrote: Melissamusic wrote:Please forgive my ignorance, were is it getting an illogical time/date stamp? KarboMusic wrote: Melissamusic wrote: KarboMusic wrote: Melissamusic wrote:I agree. Why would the Zune Player care what time or what day it is without any way to check the correct time? I would understand that the device could fail if there were a conflict in the times if connected to a computer but for it to fail on its own sounds kind of fishy. I think M$ is just buying themselves some time to come up with a fix. Believe it or not... There was a time when a device could contain an internal clock all by itself... Thats not fishy... So it has an internal clock, so if that clock is wrong then it would just show the wrong time. not crash a system. Not really, if a single line of code attempts an operation (dealing with dates/timestamps) and gets back a time/date that isn't "logical" there is going to be an unexpected result. (IE: Freeze) I'll try once more... There could be hundreds if not thousands of functions in the zune code and drivers that reference times and dates. It may be last modified timestamps on files, driver version times/dates, DRM, security, the list goes on and on. It only takes a single "operation" where a conversion, comparison etc. says "take the current time date and compare it to ____". When the code does this and there is suddenly a date that it doesn't expect to be possible, you have an error. Yes its simple to add code to prevent the freeze (could have been missed) but the scenario is completely plausible, more than plausible, its now a reality. Thanks for trying to explain it to me. Maybe I am just not getting it. But if the code is asking for a time check then what is it checking against if not the internal clock itself. And if you are saying is correct, which I am not disputing, then waiting one day will not fix it. The internal clock apparently doesn't know how to handle the extra day in a leap year. So when the internal clock reaches this 'strange day' it throws an error in the form of the freeze. once the internal clock goes back to a day it will recognize i.e. Jan 1 20XX then thigns to go back to normal operation You have been very helpful and patient in explaining this to me, Thank you. I just still think that the problem is more serious than just waiting a day so that everything will be back in sync. Hopefully I am wrong and I can begin using my Zune again tomorrow.
Well, we will have an absolute answer once the clock hits 12:01 lol. either it will work or it wont, and there our answer will be :P
Army STRONG