I'm a new chumby user, and this has seriously diminished my confidence in the reliability of the product. I had planned to ditch my clock radio and use chumby as my alarm clock. As of today, chumby has failed me two times out of four. Is chumby ready to play with the big boys?

We're still doing the root cause analysis of what happened here, and we'll let you know when we find out.  The problem occurred at the company where we host our systems, not at Chumby itself.

As to what chumbys should do under these circumstances - chumbys that ware active during this outage should still have had their alarms go off.  If one had restarted the chumby, that would have resulted in alarm failures.

We have a plan for better off-line operation, but it was out in the future a bit, once overall functionality stabilized - the biggest issue is that modifying offline mode requires firmware updates, and thus more difficult and failure-prone to deploy.

Today will no doubt be consumed with internal meetings to post-mortem this event and plans for insulating chumbys from this sort of problem in the future.  We're actively committed to reduce customer impact from these types of events.

The timing, of course, couldn't be worse - we're *officially* launching the chumby today, and I wake up to a forum full of posts about an outage, and a string of emails from IT discussing the issue.  They were up all night working with the hosting company to fix this.

But then, what else could we expect? Murphy always strikes at exactly these times.

Well, some of it is, however, it's from a different system than the one that had the outage.  We don't host the streams themselves, but for some of these we either host or proxy the directories.  In general, we've tried to minimize these sorts of issues by spreading the work across different systems, but there are still some lingering failure modes, as we've all just seen.

Today was my first real use of Chumby as an alarm clock and it failed.

I set two alarms for this morning and none of them worked.  I think the reason why the alarm failed was because they both had an action of changing to a different channel and since the network was down it couldn't change the channel and the alarm didn't go off.  Luckily I set my old alarm clock as a backup.

Here's the scenario I had:
1)  Alarm set at night to put the the chumby to display the bedtime channel (this worked)
2)  Alarm set later at night to put the chumby in night mode (this worked)
3)  Alarm set for the morning at time A to steam music and change to the wake up channel (did not work)
4) Alarm set for morning at time B to "beep" and change channel to the wake up channel (did not work)

When I woke up this morning, it was my old alarm clocking buzzing and the Chumby was still in night mode.  I thought this was odd and saw that it said the alarm will go off at time B.  I waited for time B to come around and when it did, the alarm did not go off.  It stayed in night mode and presented the next time the alarm would activate.

I really think that since I had the actions set up to change the chumby channel on wakeup and the network was down, this caused my alarm not to go off.  Can you please look into this and resolve this issue?  If a network not found condition is found, it should be caught and a regular or "default" alarm should go off at the scheduled times. 

It's a good thing I had my old alarm clock as a backup, but I would like to get rid of this old clock as it is taking up valuable table space.

I have my alarm set to one of the internet radio stations.  The screen to "turn off the alarm" or "snooze" came up, but there was no music playing.  Luckily, I woke up before the alarm went off.   Do the internet stations go down, when chumby goes down?

It was set to HardRadio.  Not sure if it is on Shoutcast or what.  Also, when the screen came up to shut the alarm off.  I turned it off, and the digital clock screen came up, but the time had stopped.   I didnt think anything of it.  When I went back to my bedroom, the alarm screen was back on the screen, but no music.   Again, I hit the option to turn it off.  The clock came back, but still stopped. 

I then rebooted my chumby, and it hung at "Checking Network Connection"....I then had to go to work, and just shut the whole chumby off.

Thanks for the response Duane.  I'm sure your company will resolve these issues.

When I set the alarms for this morning, I'm not sure why I had both actions set to change to the "wake up" channel.  I guess I was thinking that it shouldn't matter.

I'm thinking the way around this is to have one alarm change the channel and the other alarm not have any action.  This way the second alarm should still go off when the network is down.

Well, again, we have a plan for these failure modes that just hasn't been deployed yet.

Chumbys regularly check that they can contact chumby.com - however, since this failure mode was in the database backend, this contact would have succeeded - so the chumbys incorrectly believed the system was fully operational.

I'm not absolutely sure what the behavior is of every combination of alarm settings with a down local network. We have been compiling a matrix of all of the possibilities in order to cover everything for a future release - obviously, failover to an internal "chime" alarm is the best solution overall - assuming we can accurately know the status of the network.

Yes, we had to revert to a backup from Sunday at 2 pm PST.  This was unavoidable, because the failure that occurred at the hosting service completely corrupted the database.

Again, we don't have the root cause analysis yet - once we do, we'll be able to reproduce it as part of QA's process to make sure chumbys can survive it in the future if it ever happens again, which hopefully won't be the case.

I woke up to no streaming alarm clock radio and thought I overslept.    I was not happy to realize that it stopped working because Chumby.com went down.    I hate the fact that so much functionality dependent on Chumby.com.  For something as simple as an alarm clock, which is the sole reason I bought it, it is the most unreliable alarm clock I've ever used.  If power blinks off, it doesn't come back online .  If Chumby.com's website goes down it stops working.  When Chumby Inc goes out of business, my Chumby is basically an expensive brick (at least then it won't be an ad covered brick).

The worst part is that all these problems were basically engineered into the product through conscience software decisions.  I would tag it "defectivebydesign" if I could.  I applaud you for your efforts in your slow improvement of your software, but I know I will be recommending against anybody buying a Chumby till these reliability issues are resolved.  I don't want to hear about adding additional servers, I want to hear that the product is no longer going to be reliant on the website or even the company being around to function. 

Deleted due to incomplete display of the post. It makes no sence if the entire post is not shown.
PLease fix this.
I take the time and use energy to post and to have the "system" delete 1/2 of the post makes it a waste of my time.
Yaesumofo