1 (edited by gclausen 2013-06-10 06:22:49)

Topic: Alarm misfired

I have the Insignia 3.5 and, of course, use of only two screens. The night time screen is primarily what its set on and the composite calendar screen is the default otherwise. Well this morning the alarm did not go off as it has since I have owned it. I have had set to go off on weekdays at 7:15am and nothing on the weekends. So this morning, I wake up and stare at the clock and see that's its 7:34, it did not activate. When I hit the top bar to see what the problem might be, it changed to the calendar screen and I saw it switch from Sunday June 9th to todays day and date, Monday June 10th, within a blink of the eye. It still thought it was Sunday? So has this happened to anyone else? If so, did you fix it and how? Has the dependability run out on the clock as well? I have it on battery backup so it never shut off but it may lose internet connection at times.
I am just bummed about this latest quirk, if I can't depend on it to go off at the correct time what good is it?

**EDIT-Added better clarification

Re: Alarm misfired

The drawing of yesterday's date was likely due to a different graphics plane used for the calendar screen.  I'm fairly certain the device didn't magically get the date when you hit the button.

I don't know that I've ever had a mis-fired alarm on my Chumby devices.  Usually in the past, I've realized that I accidentally left it off or something, but that's because I don't use the fancy M-F alarms, I use the quick alarm and turn it off on weekends and sometimes forget it.

Maybe I'll set up a fancy alarm soon and see if it gives me different rates of success.

Linux Guy - Occasional Chumby Hacker

Re: Alarm misfired

Materdaddy wrote:

The drawing of yesterday's date was likely due to a different graphics plane used for the calendar screen.  I'm fairly certain the device didn't magically get the date when you hit the button.

I don't know that I've ever had a mis-fired alarm on my Chumby devices.  Usually in the past, I've realized that I accidentally left it off or something, but that's because I don't use the fancy M-F alarms, I use the quick alarm and turn it off on weekends and sometimes forget it.

Maybe I'll set up a fancy alarm soon and see if it gives me different rates of success.

Yeah, I had the same thought about the graphics screens BUT why would it quickly flash the day and date from the previous day before switching to the correct day UNLESS it got stuck (?) on Sunday thus is the reason why it didn't activate. Don't know why it would do that, just my trying to figure it out.

Re: Alarm misfired

Whent he device goes into night mode, the currently displayed widget is suspended.  It's still alive, but not actually running or getting events.

When the widget wakes up, it's in exactly the same state it was when it was suspended, screen and all.

This particular widget updates its display each second. This means that when it first wakes up, it will display what it was displaying before - and upon the next second change it will "fix" itself to show the current date and time.

So...what the widget is showing for that brief period is no reflective of any particular issue with the system clock - the fact that it updated it is a pretty good indicator that it wasn't wrong.

Widgets aren't any part of the alarm subsystem anyway - even if it were displaying complete nonsense, that would not affect alarms.

So, as to the alarm not firing, that's a more interesting issue.

I assume you knew that it was 7:34 because that's what the device was showing in Night Mode - if so, that would confirm that the device did indeed know the time.  So, what might have gone wrong?

The best way to try and figure that out is with more info about what the alarm was set to do - was it using one of the "built-in" alarms, or was it using a stream such as Pandora or SHOUTcast?  If a built-in alarm, was the backup alarm enabled?  If streaming, is there a possibility that the network was down, or that the particular stream used was sending out silence?  Did this alarm get accidentally skipped (there's a button for that on the Night Mode screen)?

Re: Alarm misfired

chumbies have a long standing bug with the kernel which goes off and hangs the chumby. something to do with the wireless driver triggering a kernel bug. zurk's forum has an extensive write up on it.
the devices are not reliable. period. dont use them as alarm clocks.

Re: Alarm misfired

delaney99 wrote:

chumbies have a long standing bug with the kernel which goes off and hangs the chumby. something to do with the wireless driver triggering a kernel bug. zurk's forum has an extensive write up on it.
the devices are not reliable. period. dont use them as alarm clocks.

I've been using chumbies for various hackery, alarm clock, etc. for about 5 years now and this is the first I've heard of this "long standing bug".  Do you have a link to the write up on it?  I'm intrigued.

Linux Guy - Occasional Chumby Hacker

Re: Alarm misfired

delaney99 wrote:

chumbies have a long standing bug with the kernel which goes off and hangs the chumby.

Although in this particular instance, the Chumby didn't hang.

Re: Alarm misfired

This is the first time I've heard of this kernel bug.

Re: Alarm misfired

Duane wrote:

This is the first time I've heard of this kernel bug.

Zurk posted about it in his forum: http://sourceforge.net/p/zurk/discussio … /2050bb81/
It hasn't impacted me, and I've had my Chumby since April.

Re: Alarm misfired

Hmmm, that looks like the C8.  I don't see anything there about problems with C1 and CC, I8 or I3.5, so if this is the case, then it seems to apply only to this one device not all devices.

It would indeed be odd if it were something that affects all chumbies, since they run different processors with different kernels and different drivers.

Curiously, though, I have a bunch of C8s that have been running for years and have never had them hang, let alone as often as stated in this post.

Is anyone running the *stock* C8 firmware using the stub server seeing this issue?

Re: Alarm misfired

Funny enough, C8 is the only device of the collection that I'm missing.  I have never seen this on the I8, of which I have a few.

Linux Guy - Occasional Chumby Hacker

Re: Alarm misfired

The I8 and C8 use the same processor, and I think the same kernel and drivers.  There are some minor userspace differences, and of course the Flash Player and Control Panel are different.

Re: Alarm misfired

Duane wrote:

The I8 and C8 use the same processor, and I think the same kernel and drivers.  There are some minor userspace differences, and of course the Flash Player and Control Panel are different.

As I've said previously, I've never seen that error.  I'll have to see if the discussion has any more details about how to reproduce it with any frequency.  Squashing kernel bugs can be fun at times...

Linux Guy - Occasional Chumby Hacker

Re: Alarm misfired

I'm certainly not saying that it doesn't happen, just that I've never seen it.

15 (edited by bobsz 2013-06-10 21:12:08)

Re: Alarm misfired

Re the bug nathanm noted from zurk's blog: the beginning of that post made it sound widespread but the end of zurk's post was that it was rare:

"Basically if you see the line cut here you are affected by this very rare bug. Please post the text between the cut here … end trace lines in this thread so i can gather more data about this condition and work around it. Chances are highly unlikely you will see it as this bug is rare but more samples would be useful."

Also, he wrote about it in different versions of his zurkware but didn't mention the incidence "in the wild" with unaltered Chumbys. At one point he wrote it hit all Chumbys, but that was obviously a mis-statement since I haven't seen it on mine, or read about it extensively here. I do remember some odd misfires in early versions of zurkware when I was trying it.

Re: Alarm misfired

If we're getting super pedantic here (with no evidence, simply conjecture)... If Zurk doesn't change the kernel (which I don't believe he does), he's just using the device differently than the stock firmware.  That means the bug is present all Chumby devices that run that kernel.  The difference would be in the way the user-land software is using the device drivers using his firmware vs. the way the user-land stack written by Chumby/flash use the device drivers.

I'm going to try his firmware on the I8 at work tomorrow to see if I can reproduce the failure.

Linux Guy - Occasional Chumby Hacker

Re: Alarm misfired

@materdaddy- I was going to tell you to read the thread on Sourceforge, but just saw you actually just posted there! You can see this crash problem is basically an *Urban Legend.* The thread's been going on for almost a year, but only one person is actively reporting the problem. The user has noted these "Chumby crashes" often at odd times, like when he updates Windows on his PC or uses a netbook near his Chumby. No kidding. eg,

" This time the crash was within a few seconds of booting up a nearby laptop. Any clue to what is causing this..."

Although the problem seems non-existent yes, zurk does manage to fault the Chumby kernel as you mention:

http://sourceforge.net/p/zurk/discussio … bb81/#51ce

"try with v27. realistically tho at this point it doesnt seem fixable short of replacing the kernel. when duane/blue octy gives access to the kernel source code i might try to build a good kernel."

Or, it could be the Borg, frightened by seeing the LCARS screen all over the place lately.