Interne klok 30GB-model Zune struikelt over schrikkeljaar

Eigenaars van de Zune met een 30GB-harde schijf werden op 31 december 2008 onaangenaam verrast toen bleek dat de mediaspeler niet meer wilde opstarten. Volgens Microsoft is een datumgerelateerde bug de oorzaak van de bootproblemen.

Microsoft onderzocht het probleem en kwam uit op een fout in de driver voor de interne klok. Deze hield geen rekening met het feit dat 2008 een schrikkeljaar was en ging dus uit van slechts 365 dagen in plaats van het correcte aantal van 366 dagen. De opstartproblemen hebben volgens Microsoft alleen betrekking op het 30GB-model Zune, dat in 2006 werd uitgebracht.

Microsoft geeft op de Zune-supportsite een stappenplan voor het oplossen van de tijd-glitch. Gebruikers wordt aangeraden usb- en voedingskabels los te koppelen van de Zune 30 en te wachten totdat de batterij geheel ontladen is. Daarna moet gewacht worden tot 1 januari 2009 om 13.00 uur 's middags Nederlandse tijd voordat de batterij weer mag worden opgeladen. De Zune-speler zou dan gewoon weer moeten opstarten. Volgens Microsoft zou de bug geen consequenties hebben voor de met drm-beveiligde content op de Zune, maar gebruikers wordt wel aangeraden om na een succesvolle herstart de Zune te synchroniseren met de computer.

Hoewel het probleem zich uiteindelijk vanzelf oplost, is Microsoft volgens de New York Times van plan om een update uit te brengen voor de Zune 30, zodat het probleem niet hernieuwd opduikt in het volgende schrikkeljaar 2012. Microsoft wilde niet zeggen hoeveel Zune 30's het bedrijf verkocht heeft, maar verklaarde alleen dat in principe elk exemplaar van die serie het probleem vertoont.

Reacties (131)

[Verwijderd]

Het concept schrikkeljaar is altijd heel moeilijk geweest voor MS, al sind jaren geleden zit in Excel een schrikkeljaar-bug, die ze braaf hebben overgenomen in OOXML, en die dus nu ook in Zune zit.

Een OOXML-ontwikleaar moet volgende stukje tekst uit de specificatie goed begrijpen:

For legacy reasons, an implementation using the 1900 date base system shall treat 1900 as though it was a leap year. [Note: That is, serial value 59 corresponds to February 28, and serial value 61 corresponds to March 1, the next day, allowing the (nonexistent) date February 29 to have the serial value 60. end note] A consequence of this is that for dates between January 1 and February 28, WEEKDAY shall return a value for the day immediately prior to the correct day, so that the (nonexistent) date February 29 has a day-of-the-week that immediately follows that of February 28, and immediately precedes that of March 1

De beschrijving van een Excel-setting

date1904 (Date 1904)
Specifies a boolean value that indicates whether the date systems used in the workbook starts in 1904.
A value of on, 1, or true indicates the date system starts in 1904.
A value of off, 0, or false indicates the workbook uses the 1900 date system, where 1/1/1900 is the first day in the system.
The default value for this attribute is false.

Zou het kunnen dat de werking van Zune intern in OOXML is gedocumenteerd?
Lijkt mij niet onwaarschijnlijk.

Gebruikers wordt aangeraden usb- en voedingskabels los te koppelen van de Zune 30 en te wachten totdat de batterij geheel ontladen is.

Duidelijk, misschien even met een multi-meter meten of de batterij werkelijk leeg is. Vreemd overigens dat de batterij eruit halen niet volstaat? Of is dat weer te slim?

[Reactie gewijzigd door Verwijderd op 25 juli 2024 19:45]

[berend_engelbrecht]

@nieuwstip
Sorry, je verhaal over de Excel-schrikkeljaarbug is wel interessant maar heeft niet met deze schrikkeljaar-bug te maken. Excel weet wel dat 2008 een schrikkeljaar is en zal gisteren niet op tilt geslagen zijn.

Het concept schrikkeljaar is altijd heel moeilijk geweest voor MS, al sind jaren geleden zit in Excel een schrikkeljaar-bug

Die uitleg is tendentieus en feitelijk onjuist. De "schrikkeljaar-bug" in Excel is geen bug maar bewust erin gebracht voor backward compatibility met Lotus 1-2-3 (bron). Destijds toen Microsoft Multiplan en Excel op de markt bracht was het belangrijk om één op één compatible te zijn omdat Lotus 1-2-3 market leader was (Lotus 1-2-3 was het eerste PC-softwareproduct waarvan meer dan een miljoen exemplaren verkocht zijn, om je een idee te geven van de populariteit).

Ook in Lotus 1-2-3 was het overigens geen bug voorzover ik weet. Vrijwel zeker is de fout ook in dat programma bewust aangebracht om compatible te zijn met VisiCalc (de moeder van alle moderne spreadsheets). Ik hoorde begin jaren '90 al eens het verhaal dat Lotus 1-2-3 die fout zelf weer geërfd had van VisiCalc, toen ik in een team werkte met een Amerikaanse spreadsheet-expert. Na flink zoeken vond ik een bron die dit inderdaad plausibel maakt: hier vind je het verslag van iemand die nagegaan heeft dat de originele VisiCalc executable hetzelfde probleem heeft.

Waarom een bug er in houden?
Boekhoudformules gebruiken vaak onderliggend getallen om dagen en periodes weer te geven en er zijn formules die niet zomaar over te brengen zijn als je het nulpunt van de datumtelling ineens zou wijzgen. Een boekhouder zal het niet op prijs stellen als zijn formules ineens verkeerd werken bij het overstappen op een nieuwe software, dat is een goede reden om de nieuwe software niet aan te schaffen. De boekhoudwereld is behoorlijk conservatief (bij grote bedrijven vind je zelfs nog tamelijk veel COBOL-software), dus een firma die nieuwe software op dit gebied op de markt wil brengen heeft er belang bij om de legacy goed te ondersteunen, inclusief dit soort rariteiten.

[Reactie gewijzigd door berend_engelbrecht op 25 juli 2024 19:45]

[Verwijderd]

Dus de bug zit in OOXML verwerkt omdat Cobol code anders fout met Excel omgaat, en het ligt ook niet aan Excel maar aan Lotus, of eigenlijk aan Visicalc (maar dat is onzeker), pakweg 20 jaar geleden?
Het was niet mogelijk geweest om dit in OOXML te omzeilen via een ISO datum-notatie, en het probleem in Excel bij Excel te laten? Moet nu de hele wereld een raar vlaggetje zetten vanwege de bug in Visicalc 20 jaar geleden?

Ook in Lotus 1-2-3 was het overigens geen bug voorzover ik weet. Vrijwel zeker is de fout ook in dat programma bewust aangebracht om compatible te zijn met VisiCalc

Goed, we begrijpen nu allemaal waarom bugs die je geen bug mag noemen wel 20 jaar kunnen blijven bestaan.

Destijds toen Microsoft Multiplan en Excel op de markt bracht was het belangrijk om één op één compatible te zijn omdat Lotus 1-2-3 market leader was

Opvallend overigens, dat ODF dit wel elegant kan oplossen. Gewoon de legacy laten waar deze hoort.

Die in OOXML geimplementeerde bug is een foutgevoelige situatie die keer op keer opnieuw tot fouten zal leiden, en het is dan wel typisch dat in Zune ook een schrikkeljaar fout zit, terwijl iedere code-library schrikkeljaren goed afhandelen.
Het is een bug van proportie W2K-bug (jaar 2000 bug), dat blijkt nu ook weer.
Maar ik geef toe dat mijn vorige reactie een grapje is, ikzelf vind het wel leuk. Het is vreselijk gênant voor MS.

Boekhoudformules gebruiken vaak onderliggend getallen om dagen en periodes weer te geven en er zijn formules die niet zomaar over te brengen zijn als je het nulpunt van de datumtelling ineens zou wijzgen

Voor dit doel bestaat ISO 8601 (http://en.wikipedia.org/wiki/ISO_8601) al sedert 1988.
Misschien een ideetje dan voor banken en gedegen boekhoudsoftware die Excel datumtelling gebruiken, en ook voor OOXML om dit aan te houden.

Zoals ze ook bij MS hebben ontdekt, ISO is zo gek nog niet, en het voorkomt domme fouten, maar dan moet je het wel goed volgen, en legacy laten waar het hoort, in de legacy.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 19:45]

[berend_engelbrecht]

Behalve dat VisiCalc niet in COBOL geschreven is heb je het goed weergegeven, ja (COBOL heb ik er alleen bijgesleept om het conservatisme te illustreren). Het is geen bug, maar een gedrag van de software dat ze hetzelfde willen houden, juist omdat het anders tot fouten in de uitvoer zou leiden. Mensen kopiëren formules zonder ze werkelijk te begrijpen en willen niet dat het gedrag verandert.

Dit stamt echt wel van ver voor de OOXML-controverse. Dat project waar ik naar verwijs was in 1991, het Europe IRIS project van Mobil Oil. Zelf heb ik in de jaren '80 nog met Lotus 1-2-3 gewerkt, dat was toen ook in Nederland verreweg het meest gebruikte spreadsheet-programma. De uitleg dat Microsoft hier een stomme fout maakt en stom is om het niet te herstellen hoor je vaak in verband met OOXML, maar vind ik gekleurd en onterecht. Ik heb geprobeerd om hierboven voldoende bronnen voor mijn verhaal te geven en als je zelf googelt zal je hier zonder moeite nog andere bevestiging voor kunnen vinden.

[comecme]

Die ISO-norm gaat volgens mij alleen over een eenduidige weergave van datums. Je kunt er echter niet mee rekenen. Niet in de zin van DatumTot - DatumVan = AantalDagen of zo.

[Verwijderd]

Er zijn heel veel libraries voor gebruik in C of Pascal of Java die de ISO-datum notatie intern of extern omzetten naar een rekeneenheid.
(voorbeeld: http://joda-time.sourceforge.net/cal_iso.html)
Als je er mee wilt rekenen is het wel heel goed dat je weet dat je een eenduidige datumnotatie hebt, daarvoor zorgt de ISO-datumnotatie. (ISO voegt zelfs op wens, tijdzone toe, en daar kan dus ook mee gerekend worden, kwestie van goede libaries)

[Reactie gewijzigd door Verwijderd op 25 juli 2024 19:45]

[simon]

't is nogal een gedoe om de batterij eruit te halen, moet de behuizing open. Dat wil MS natuurlijk niet.

[devguru]

Door de batterij eruit te halen verziek je waarschijnlijk je garantie, en da's toch zonde Ik denk dat de batterij eruit halen prima volstaat. Als ie eruit is nog even de aanknop inhouden (net zoals met een BIOS) om de laatste restjes te verbruiken dan dan heb je het identieke effect als wanneer de batterij leeg is.

[Verwijderd]

In OOo hadden ze dit simpel opgelost voor het .doc formaat, gewoon de telling bij 31 december 1899 laten beginnen in plaats van 1 januari 1900 (zoals MS doet), en vanaf 1 maart 1900 loopt alles weer netjes synchroon.

[berend_engelbrecht]

Ja, dat zou inderdaad een simpele oplossing zijn. Jammer dat het niet zo gedaan is. Helaas denk ik dat het altijd moeilijk wordt voor mensen om in simpele oplossingen te denken zodra er een controverse ontstaan is en er kampen zijn die zich elk in hun eigen positie verschansen.

[Verwijderd]

Dat is allemaal leuk en aardig, maar ik snap nog steeds hoe zo'n ding total kan vastlopen als hij denkt dat het een volgende dag is, terwijl dat het niet is.

Edit: ze hebben het hier over een oneindige lus: http://www.zuneboards.com...ear-problem-isolated.html

[Reactie gewijzigd door Verwijderd op 25 juli 2024 19:45]

[piderman]

De Zune houdt de datum bij als het aantal dagen dat verstreken is sinds 1 januari 1980. Je krijgt het huidige jaar door voor elk jaar een aantal dagen (365 of 366) van het totale aantal af te trekken en er dan een jaar bij op te tellen. In theorie werkt dit prima. De code leest vrij vertaald als volgt:

- Hebben we meer dan 365 dagen in het totaal over en is het geen schrikkeljaar? Haal dan 365 van het totaal af en tel een jaar verder.
- Maar, hebben we nu een schrikkeljaar? Dan kijken we of we meer dan 366 dagen in het totaal hebben. Zo ja, trek dan 366 dagen van het totaal af en tellen we een jaar verder.
- Hebben we 365 dagen of minder in het toaal over? Dan zijn we klaar en kunnen we het aantal dagen omrekenen naar een maand en de dag van die maand.

De kneep zit m in het stukje "kijken we of we meer dan 366 dagen hebben". Als je precies 366 dagen over hebt *en* het is een schrikkeljaar, dan zijn we op de 366e dag van het jaar, 31 december dus. We hebben niet /meer/ dan 366 dagen, dus we tellen niet een jaar verder, want het is een schrikkeljaar. De ontwikkelaars hadden dus al juist ingezien, dat ze hier iets speciaals moesten doen.

Echter, ze hebben verzuimd ook daadwerkelijk iets met deze informatie te doen. Ze tellen niet een jaar verder, maar ze gaan nu *ook niet* kijken welke dag in het jaar het precies is. Wat ze wel doen, is weer aan het begin gaan kijken van "heb ik meer dan 365 dagen? is het een schrikkeljaar?" etc. En op die gelegenheid komt het programma er ook niet uit, gaat weer kijken of het meer dan 365 dagen zijn, komt er weer niet uit etc.

In de praktijk heet dit een "oneindige lus". Het programma blijft oneindig lang hetzelfde doen, en komt niet verder in het opstarten, tot jij de batterij uit de Zune haalt en m hardhandig uitzet.

Voor alle andere dagen in het schrikkeljaar, en alle dagen in een niet-schrikkeljaar werkt de code prima, dus aanzetten op 1 januari (MS heeft middag GMT gekozen omdat dan alle tijdzones inmiddels 1 januari op de kalender hebben), verhelpt het euvel.

Blijft het feit dat op elke laatste dag van een schrikkeljaar deze bug zich voordoet. Dus of even de fix van Microsoft installeren, of m op 31 december 2012 niet aanzetten.

[Reactie gewijzigd door piderman op 25 juli 2024 19:45]

[carpin]

Het is niet de Zune die struikelt over het schrikkeljaar maar de programmeur valt te pletter door het schrikkeljaar.

[Hadron]

Gebruikers wordt aangeraden usb- en voedingskabels los te koppelen van de Zune 30 en te wachten totdat de batterij geheel ontladen is. Daarna moet gewacht worden tot 1 januari 2009 om 13.00 uur 's middags Nederlandse tijd voordat de batterij weer mag worden opgeladen.

Hoe lang duurt dat? Ik weet niet hoe dat met de zune zit, maar zelfs bij mn batterijslurpende Zen Touch kan het zomaar een paar dagen duren eer de batterij leeg is, zeker als'ie niets aan het afspelen is en de backlight uitstaat. Helpt resetten niet? Of zorgt de bug ervoor dat de batterij sneller geleegd wordt?

Edit: Bedankt voor de extra info, ThunderNet Wachten is irritant, maar wachten op iets waarvan je niet weet hoe lang het duurt is nog veel irritanter...

[Reactie gewijzigd door Hadron op 25 juli 2024 19:45]

[ThunderNet]

Dit duurt niet zo erg lang. Hij blijft in het bootscherm hangen, alle energiebesparende code wordt dus niet uitgevoerd. Hij voelt ook warm aan, dus hij is druk genoeg bezig.
Resetten kan niet, omdat hij niet opgestart wordt, tenzij je een hard-reset doet maar daar moet je hem voor uit elkaar halen

[Umbrah]

Of de accu d'r uit trekken, dat kan met deze spelertjes vrij gemakkelijk. Welke spelertjes die makkelijk hun wachtwoord beveiliging lieten omzeilen kon dat ook alweer niet mee?

[Nokian95dude]

In principe kan je altijd een reset doen. Dat ie zich niet in een opstartfase bevind doet daar niks aan af en staat daar in principe los van. Als een pc bijv. vasloopt als je muziek aan het draaien bent is je pc ook niet aan het opstarten. Maar je pc heeft een resetknop of anders kan je ctrl-alt-del doen en werkt zelfs dat niet (wat ook kan) dan helpt de stekker eruit trekken altijd.

Dat kan je ook met je ipod doen. Dat wil zeggen dat je in t uiterste geval je batterij eruit moet, ff wachten, er weer in en het ding opnieuw aanzetten. En als het goed is start t ding dan weer op.

Maar in deze situatie neem ik aan dat je bedoeld dat het niks zal helpen omdat je nu met dit probleem zit van het schrikkeljaar.

Ik wilde enkel even uitleggen dat het losstaat van resetten want dat kan altijd.

[Verwijderd]

wat een domme fout, van ms zou je na al die jaren marktleiderschap in software ontwikkeling toch beter verwachten.

[vgroenewold]

Op zich wel, maar goed, dit soort fouten kunnen altijd over het hoofd gezien worden. Valt mij wel op dat een bug als deze dan eigenlijk nauwelijks tot nooit voorkomt in andere apparaten.

[Sr_Ogel]

De millenium bug had een grote klapper moeten zijn op schrikkeljaar gebied.
gelukkig konden de computers hier wel mee overweg.

2000 was namelijk een bijzonder schrikkeljaar.
2000 deelbaar door 4 dus schrikkeljaar
2000 deelbaar door 100 dus geen schrikkeljaar
2000 deelbaar door 400 dus wel weer een schrikkeljaar.

en dat moet je dan maar net weten en ik wist het zelfs niet van deze schrikkelregels en ik ben nog wel geboren op de 29 van februari
zoals mijn ouders zeggen een verschrikkelijk kind

[kemphaas]

Vraagje, waarom zou een jaar dat deelbaar is door 100 geen schrikkeljaar kunnen zijn?

Ik noem:

400.
800.
1200.
1600.
2000.

Allemaal schrikkeljaren en allemaal deelbaar door 100?

[wildhagen]

Zoals alexkroeze al zegt: een jaar dat deelbaar is door 100 krijgt geen extra schrikkeldag, tenzij ze ook deelbaar zijn door 400, dan weer wel. Dat is omdat we anders door overcompensatie weer wat 'tijd overhouden'.

En laten de jaren die jij noemt nu net allemaal deelbaar zijn door 400...

Zie voor meer uitleg deze site: http://home.wanadoo.nl/~haj.quast/pages/schrikkeljaar.htm

[Sr_Ogel]

maar 1700, 1800, 1900 en 2100 zijn geen schrikkeljaren

[flamingworm]

De jaartelling met schrikkelijkjaren is maar gestart in 16de eeuw

[Peedy]

Dat maakt voor het in retrospect bepalen van schrikkeljaren niets uit.

[MSalters]

Toch wel. Er zaten maar 365 dagen in het jaar 1200; na 28-2-1200 volgde 1-3-1200. In een schrikkeljaar zitten 366 dagen, en 29 februari. Conclusie: 1200 was geen schrikkeljaar.

[NBK]

Dat de overgang naar 2000 goed gaat is niet zo bijzonder. De overgang naar 2100 had op dat gebied een groter probleem kunnen geven omdat veel software (ontwikkelaars) niet op de hoogte zijn van die deelbaar door 100 en deelbaar door 400 regels.

[Reactie gewijzigd door NBK op 25 juli 2024 19:45]

[.oisyn]

Daar hoeven reguliere software-ontwikkelaars ook niet van op de hoogte te zijn. Het bepalen wat een schrikkeljaar is is een hooguit een programmeeropdracht voor school, ik kan me geen reden bedenken waarom reguliere software in hemelsnaam zelf dat soort berekeningen moet gaan zitten doen. Die gebruiken gewoon datumfunctionaliteit van de standaard libraries.

[Vastloper]

Dit zal misschien een schok voor je zijn maar er is nog steeds heel veel software nodig voor niet pc elektronica Het schijnt zelfs dat er consumentenproducten zijn waar geen full blown windows, unix, linux of macos op draait Zelfs systemen waar niet eens een x86 processor in zit of soms gewoon nog een 8 bit microcontroller in zit zonder mmu.
Er zijn zelfs bedrijven die hun eigen chips ontwikkelen!
Vast heel schokkend voor je dat er nog meer is in de wereld dan waar jij je mee bezig houd.

[Reactie gewijzigd door Vastloper op 25 juli 2024 19:45]

[.oisyn]

No shit, sherlock! Ik ben heel goed op de hoogte van het bestaan van embedded software. En lees nu mijn reactie nog eens een keer, en concentreer je dan vooral op het woordje "regulier". Het zal misschien heel schokkend voor jou zijn, maar de embedded software wereld is een heel stuk kleiner dan die voor reguliere software. En goh, had ik het niet over "datum-functionaliteit van standaard libraries"? Door wie denk je dat die worden geschreven? Met andere woorden, ik sloot helemaal niet uit dat iemand dat soort functionaliteit maakt. Maar voor die personen die dat wél doen is het uiteraard van belang dat je research doet naar hoe datums en locales werken. En nog steeds blijft het geval dat itt die lui reguliere software developers die kennis niet hoeven te bezitten.

Wel weer grappig dat jij denkt te weten waarmee ik me allemaal mee bezig hou, en hoe je de assumptie maak dat ik niets van embedded software weet. Wat helemaal grappig is is dat juist jij zo'n reactie post omdat je je volgens je profiel met embedded software bezig houdt. Wat is er, voel je je op je tenen getrapt?

[Reactie gewijzigd door .oisyn op 25 juli 2024 19:45]

[E-E-R]

Ik vind het eigenlijk gek dat een datum-gerelateerde bug ervoor kan zorgen dat je apparaat niet meer opstart, wat heeft de datum nu weer te maken met het wel of niet booten van een apparaat?

[Verwijderd]

Vind ik inderdaad ook raar. Bovendien, hoe weet dat apparaat eigenlijk wat de echte tdatum is?

[Verwijderd]

Weet niet of de Zune het doet maar de iPhone of iPod touch zoeken de echte datum op het internet.

[johnbetonschaar]

Ik snap er ook weinig van, ik zou graag de technische details wel eens willen weten.

Zoals ik het zie zit er gewoon een klok in dat ding die bijhoudt welke tijd en datum het is, als daar een bug in zou zitten zou je verwachten dat je gewoon een verkeerde datum krijgt ofzo.

Maar misschien zit er wel een of andere gekke DRM check om te zorgen dat mensen niet met hun klok gaan klooien om hun beveiligde bestanden langer af te kunnen spelen [/conspiracy mode]

[darkfader]

Mja. Zo lijkt het meer op een toegevoegde feature dan bug.

[RemcoDelft]

Mwah, ja al die jaren verwacht ik juist van Microsoft dergelijke bugs... 't Is niet alsof ze nooit eerder rare bugs gemaakt hebben, zeker met de datum! Millenniumbug was een groot probleem, maar ook het verzetten van de klok om 3 uur 's nachts (Windows heeft de tijd aangepast ==> 2 uur ==> OK). Tot m'n verbazing kwam er een uur later weer exact dezelfde melding (toen ben ik maar gaan slapen).

[Nokian95dude]

Ja toch wel een vervelend foutje wat eigenlijk niet zou nmoeten kunnen vind ik. Dat ze een update gaan uitbrengen is niet meer dan logisch anders heb je hetzelfde euvel over 4 jaar weer. En dat kan toch eigenlijk niet want zo werkt het bij een pc ook niet. En gelukkig maar

Ik heb t probleem niet, ik heb een mp3speler van Creative maar ook al zou daar een probleem mee zijn, ik gebruik die toch niet want ben nu superblij dat ik een tellie heb die dat allemaal kan (en nog veel meer).

En mijn Nokia laat me nooit in de steek

Maarja zoals al eerder gezegd, ieder bedrijf maakt wel eens een foutje, groot of klein. Het zijn ook maar mensen. Een fout is menselijk he

[mashell]

Dat ze een update gaan uitbrengen is niet meer dan logisch anders heb je hetzelfde euvel over 4 jaar weer.

Is dat wel zo? Het gaat hier om een 30Gb Zune uit 2006. Die is in 2012 al 6 jaar oud, met een lage capaciteit schijf. Dus het apparaat is dan of al lang vervangen of gewoon kapot. Dit soort modegevoelige consumenten elektronica wordt niet gemaakt om lang mee te gaan.

[Verwijderd]

mp3's worden niet groter tussen nu en 2012 zolang je de bitrrate niet vergroot, en omdat de meesten dat verschil toch niet horen, en al helemaal niet op een draagbare speler, is daar geen reden voor. Mijn Nokia 6230i uit 2005 is nog steeds een prima mp3 speler, en er past niet eens meer dan een 4GB kaart in (het maximum van MMC).

[Verwijderd]

en video's dan? ja op een ipod "classic" is dat niet zo handig maar op een zune is het erg handig. Om lekker veel films mee te nemen heb ik toch meer dan 120gb nodig.
Volgend jaar komen ze met 250gb (apple en microsoft)

[Umbrah]

Hmmm, ik weet het niet, op m'n PSP kan ik de gehele LOTR trilogie en geheel seizoen 1 van heroes kwijt op een 8gb stickje, en dan gebruik ik slechts 6GB. Dat is dan ook de enige reden waarom ik een PSP heb, persoonlijk vind ik er niet echt veel leuke spellen voor. Wat ik op 250GB kwijt kan, is astronomisch eigenlijk. PSP filmpjes zijn wel "slechts" 480*277, maar het schermpje is zo'n beetje de max van wat je mobiel houd. Op het moment denk ik dat 800*480 zo'n beetje de max haalbaar is zonder dat de CPU-tjes de accuduur tenniet doen, maar zelfs dat is niet zo groot qua compressie.

Ah well, laten we het maar "op de toekomst voorbereid" noemen. Persoonlijk zal ik niet zo snel geneigd zijn om een apparaat te komen met 250gb "vast" geheugen, ik wissel liever af en toe van stick. Ik gok dat de schermpjes pas over een paar jaar zo groot/uitvouwbaar zijn dat 250GB nuttig is. En dan is de restvraag, hoe is de status van de compressie tegen die tijd? Ik bedoel, als je een spel met UT2004-like graphics met één level in 96KB kan krijgen op DIT moment, wat wil dat zeggen?

[Gondor]

MS is inderdaad vrij snel met een oplossing gekomen.

Het lijkt er op dat ze het al wisten en de oplossing paraat hadden. En op het moment dat er klachten zijn/zou (ge)komen hebben ze de oplossing gepubliceerd.

Anders is het wel erg merkwaardig dat op nieuwjaarsdag minstens 1 team zune gaat debuggen, probleem opsporen, oplossing bedenken/zoeken, oplossing testen/analyseren. De oplossing naar de PR afdeling sturen, PR maakt het publiceer klaar. Dat doe je niet zomaar in paar uurtjes.

Ook omdat je het niet veroorloven om achteraf "Ow, wacht dit werk niet je moet dit en dat eerst doen" te moeten zeggen.

Waarom? Zo zie ik het: Nu is het hoofdnieuws en iedereen heeft het over Zune anders was het een firmware update nieuws geweest.

[Verwijderd]

Als ze het al wisten is het wel zeer bizar dat ze niet gewoon een update de wereld hebben rondgestuurd. Het zegt in dat geval veel over de slordigheid van MS. De reden voor de bug circuleerde al op het net nog voor MS op zijn website liet weten dat er problemen gedetecteerd waren. Lijkt me eerder dat MS de reden zelf heeft kunnen achterhalen door engadget te lezen.

[bvk]

Wat ik niet begrijp: waarom is het apparaat niet gewoon doorgegaan met werken, maar met verkeerde datum? Die je daarna gewoon bij kan stellen neem ik aan, of zie ik dit nu helemaal verkeerd?

[Bloodshot]

Bij devices waar tijd van ondergeschikt belang is (telefoons die als telefoon gebruikt worden en dus niet als horloge) heb je volkomen gelijk. Bij spelers waarbij DRM wordt gebruikt (datum/tijd-afhankelijkheid!) ligt dit anders. Vergelijk het met een digitaal certificaat met een einddatum.

[DarkTemple]

Hoe weet dat apparaat dan dat de datum die hij denkt dat het is niet klopt?

Heeft die zune een ingebouwde wifi dan die automatisch de tijd/datum eerst checkt voordat hij opstart? en wat dan als je net geen wifi in huis hebt, start hij dan helemaal niet op?

[Verwijderd]

Ik denk dat de Zune kijkt naar hoeveel dagen verstreken zijn en deze dan vergelijkt met de kalenderdatum. 31 december op de 366ste dag zal ervoor zorgen dat de Zune helemaal in de war geraakt.

[Verwijderd]

Wat ik vreemd vind is waarom dit niet op 28 februari opgemerkt is..?

[wildhagen]

Omdat ze toen nog niet op dag 365 van het jaar zaten, en de Zune dus niet 'denkt' dat het al 2009 is, terwijl het nog 2008 was?

[High-Voltage2]

Wat ik vreemd vind is waarom dit niet op 28 februari opgemerkt is..?

Daar heb je een punt!!
Op 29 februari zou er iets fout moeten gelopen zijn omdat de RTC tijd niet overeen komt met wat de systeemklok kan weergeven. Volgens de systeemtijd bestaat 29 februari niet terwijl de RTC toch 29 februari meetelt.

[MSalters]

De RTC is de Real Time Clock, niet de Real Time Calendar. Klokken houden de datum niet bij, alleen de tijd.

[Fab1Man]

Wat ik niet helemaal begrijp is hoe de Zune hier een probleem mee heeft. Dan kun je wel zeggen dat het met DRM niet goed werkt, maar van waar uit komt de cross-check of die datum überhaupt wel klopt? Of is het meer dat het in de DRM bestanden wél goed op staat genomen en dat de Zune een verkeerde datum aangeeft en daardoor crashed?