I looked through faq and searched the bbs, I couldnt find much. My player is running hijack v 300 . The day and time seem to be working fine but the player will change to the year 2034. Re adjusting the year works but it changes back a few boots later, is this a known bug ? Has anyone found a way to fix this?

Does the clock keep the correct time?

the clock does keep time well enough, but just realized date and year arent right. Its a riocar as well.

I knew the empeg did a lot of things but a time machine as well??

Oh yeah, I should have asked him if it was installed in a DeLorean.

Mine did something similar over new year. I went away for a week, came back and it had some crazy date like July 2034 (can't quite remember exactly) I thought it was just because I hadn't turned it on for a bit and it had been kept in a cold place (locked in a boot/trunk), so I thought nothing more of it - it hasn't done it before or since though.

Pretty sure that 2034 is where Unix date/time rolls over. It sounds like when reading the time, the processor is getting all 1s or somthing like that. I assume the clock chip is external in empeg?

Unix date/time is a signed 32 bit number meaning a maximum of roughly 2 billion seconds or 68 odd years. With an epoch of Jan 1 1966, that makes it roll over in 2034.

Sounds like hardware could be a prob.

Edit: Unix date/time epoch is actually jan 1 1970 but I'm pretty sure I'm on the right track.

time rollover would be 2038.

Yeah that makes sense BUT the Unix date rollover is definitely 2034.

Perhaps my understanding of how the 32 bits is used is wrong. Perhaps they use 6 bits = 64 years which would make 2034 right.

Nope. 03:14:07, Tuesday, January 19, 2038 UTC. Of course, by then, hopefully, we'll all be running 64-bit Unix systems that store the number of seconds past 1/1/1970 in a 64-bit integer that will require nothing more than a recompile of affected software.

Of course, then we'll have to do it all over again by 15:30:08, Sunday, December 4, 292277026596. I guess there's no perfect solution.

OK correct you are but the time function overflows in 2034.

September 30, 2034 - Overflow of Unix time function

January 19, 2038 - Overflow of Unix systems

September 30, 2034 - Overflow of Unix time function

Yeah, that could be relevant here.

I can't find much more info about this 2034 date than rote repetition. The only site I can find that says anything more says:

2034-09-30 Sat - Time overflow in some ancient UNIX, which was fixed long ago. Genuine, but no longer significant. See 2038.

Wait. Here's one that says:

September 30, 2034 - UNIX time function overflow per USAF website (May be one of those nasty site-specific dates)

I think that we can both agree that the problem in 2038 is that a signed 32-bit integer will no longer be able to contain the number of seconds after 1969, right? Well, my Solaris man page for time(2) says:

The time() function returns the value of time in seconds since 00:00:00 UTC, January 1, 1970.

which seems like the same description to me.

2034-09-30 Sat - Time overflow in some ancient UNIX, which was fixed long ago.

Some really old Unixes didn't have the epoch in 1970. I couldn't find an online reference to this, but in The Clock Of The Long Now Ken Thompson or Dennis Ritchie or someone like that describes his mail archives from about that time, in which he's not sure exactly when they're from because "we changed the epoch around a few times".

Peter

mine did the same thing, displaying 2034. pretty kooky.

no one seems to know, maybe a software thing.

Happened to me too... weird...

My spare empeg did this when I put it to use after it was unpowered for a few months. I just passed it off as a glitch due to the long time of being away from power, and haven't seen it again.

Mine keeps doing it!

stopit!


is it perhaps a CMOS battery? does the Empeg have one of those?

No battery, just a cap. Should last you a couple of weeks between charges.

Could a bad CAP be the cuplrit? Maybe (it's a long shot) our empegs got stuck with some poorly manufactured CAPS? (the article mentions that these typically are used to smooth out the power supply.

If you know where to look, check the capacitors for a slight buldge (maybe, the X is more defined) or brownish ooze.

Arcticles as reference:
http://www.spectrum.ieee.org/WEBONLY/resource/feb03/ncap.html
http://slashdot.org/articles/02/11/04/1751210.shtml?tid=137

I'm not trying to scare anyone and It's not even a 'hunch', just a odd-ball idea that somebody more talented than I could confrim or deny. Is there an easy way to test the CAP or outright elimitate it as being faulty?

I have seen only 1 example of a bad CAP (and it was on an IBM motherboard - mentioned in the article)...

i don't think it would be a bad capacitor. from what i've read, the issues with bad capacitors involve using generic components in the manufacture of the capacitors. I have a feeling that the Sonicblue/RIO/empeg people did not skimp on parts. but then again, it is reading 2034...