Andy, would it help to get the customer's MAC address?  Do you keep logs of this sort of thing?

Personally I use SN as my alarm clock, and while it does fail more than a real alarm clock, it's definitely better than 75%.  At least 92% :)

Hmm, sure.  I'll take a look.

*** Bug 4980 has been marked as a duplicate of this bug. ***

Just heard from Dan in support another customer is inquiring about this issue. Where do we stand?

I need more info in order to reproduce, can you give a detailed list of all your alarms, their times, volumes, whether or not the fade-in feature is enabled, and what URLs they are set to?  Or just give me your player MAC and I can pull all this from SN.  Hopefully if I setup a player with the exact same alarm settings I'll see the problem.

Here it is:
Player MAC Address:  00:04:20:06:74:d7

Alarm time: Differs from day to day. Now: 08.45
Time zone: GMT+1
Location: Oslo, Norway, Europe
Alarm volume: 9  (probably never the same as it is set to when I leave the squeezebox for the night)
Alarm sound: Varys, but one of these:
   http://media.hiof.no/streams/m3u/nrk-alltid-nyheter-128.m3u  (most common)
 
   mms://straumr.nrk.no/nrk_radio_alltid_nyheter_m  (Same station as above, but wma. Server located in Oslo, I think)
 
   http://kexp-mp3-2.cac.washington.edu:8000/  (now)

I've spotted the bug with all of the stations above.

Support has some users interested in the status of this bug as well.

One user reports that if he sets the alarm via the SqueezeNetwork web interface, it works more reliably, but if he sets an alarm with the remote control SB interface, it is not.

FYI.

The alarm function fails when connected to Squeeze-network. At the specified alarm time the squeezebox switches itself on, but then the screen flashes between the "Alarm Time" and the radio station the alarm is set to play, doesn’t play anything, and then locks up (displaying the radio station but not playing anything). None of the remote controls then work and the only option seems to be to disconnect mains supply and reboot. 

The alarm function does seem to work correctly if the Squeezebox is connected to my computer via Slimserver, but this means leaving the computer running all day and night.

The same problem occured whatever the "alarm sound" is set to via Squeeze-network, (ie other radio stations, Natural Sounds, Musical Alarm). It worked once when set to a Musical Alarm, but I was unable to repeat this. It made no difference whether the fade in was on or off.

I've fixed 2 bugs, please test on the beta server:

Alarms set between 12:00-12:59pm (from the website only) would never fire.  You will need to go and set your alarms again via the website if you had one of these alarms.

Fade-in now properly fades for only 20 seconds.

From the descriptions in this bug it sounds like there may still be other issues.

(I'm not sure if I was supposed to test the beta server. You didn't leave instructions. But I found them myself and tried it out. It now says SQUEEZENETWORK - BETA in top of my display)

From what I can see, the SB will not do any buffering before it will launch the alarm (Beta and current). Causing it to rebuffer after a few seconds. Is it supposed to be like that?

Radio Station Buffer Seconds is set to 3 seconds in my settings.

Beta had a 100% success rate (tested 6 times). Tested both webinterface and remote to set the alarm. Fade-in works fine.

Current failed three out of four. "Checking stream" was flashing, and then it locked on two occasions(pressing and holding power og left arrow DOES work, no need to unplug). It rebooted the third and came back to show "Now playing"(not playing anything).

By 12:00-12:59pm, do you mean US(east coast?) time? I did my testing between 12.00-12.45pm(GMT+1). 

When will these changes enter current?

Thanks for testing.  By 12-12:59 I meant if you had set an alarm to fire between those times (any time zone) it would not fire because it was being set for an invalid time.  These fixes will be moved to production after QA approves them.

Did a few tests in support ... the alarms go off correctly, however the display initially shows the wrong stream.  

I had an alarm previously set to show RadioFoo.  I changed it to go off at 10:52am and play Musical > Barn Fire.  It went off at 10:52 but displayed RadioFoo for the first 10 secs or so, then changed to Now Playing, then changed to Barn Fire.

I tested again changing the time to 10:55 and Musical > Blue Orchid.  It went off at 10:55 and displayed RadioFoo, then Now Playing, then Blue Orchid.

One final test with roughly same results:  alarm goes off on time but displays RadioFoo for 5-30 secs, switches to Now Playing, then switches to the correct stream data.

I have not been able to reproduce the bug where the previous alarm title is displayed.  For me, the correct stream title is always shown with the "Alarm playing" text.

I just tested this and I too am seeing the wrong station displayed briefly as the alarm is initiated. Every time the correct station plays, but half the time the wrong station is displayed briefly. Also, after about 30 seconds of the alarm playing the screen goes blank despite the now playing screen saver being set to now playing. 

Andy can you look at the logs for our players, would that help? Dan and I seem to have no trouble reproducing some odd behavior. 

Will review the outstanding SN bugs after 7.0 ships.

We also are encountering a problem with our SqueezeBox alarm - used with internet radio.  Specifically:

The alarm clock function has not worked since the February migration. It was
completely reliable prior to that day. The alarm logo is still present, but
the alarm never goes on. We have it set to SqueezeNetwork.

Thank you! 
Jack Steele

*** PLEASE ADD cc to jack.steele@h-gac.com ***

ALARM BEHAVIOR & FIRMWARE UPGRADE:  Since we installed firmware in 7.0 two days ago, the alarm has worked correctly.

Is the only remaining alarm issue on SN the fact that the wrong title can sometimes be displayed?  I believe that's been fixed in the current QA branch on testsn.

I just fixed a bug where the player UI menu for selecting an alarm using our built-in Natural Sounds was using the old URLs so those would always return 404 and not play anything.

QA to reproduce

I'm still seeing unpredictable behavior. I set an alarm for 3:33 for a Pandora station, 3:33 my player came back from off screen saver and shows "Alarm Clock Now Playing, Highveld Stereo" however I'm not sure what Highveld Stereo is, and nothing is playing. 

OK it will be good if you can retest this on the test server.

Ross:  please verify the fix

Will do, standing by. 

With the alarm sound set to a Rhapsody or Pandora stream my player freezes when the alarm time comes due, but does not play the audio. It displays Alarm Clock Now Playing, then rhapd://...etc, with infinite spinning wheel. Holding left arrow for 5 seconds seems to be the only way to exit this state. 

Can you test if this also happens in SC?

Works with SC 7.0.1 - 18806 using 'The current playlist'. 

Hmm I tested Rhapsody's Smooth Jazz channel rhapd://ps.8647878.rdr as an alarm and it played just fine.  What specific Rhapsody track/channel is set for your alarm?

Same result with Pandora.

Indeed looks to be working much better now. 

This issue seems to be back. 

We are getting numerous emails from customers saying that the alarm function does not work anymore when connected to SqueezeNetwork. 

I have also tested and verified that the alarm function does not work via SqueezeNetwork. 

Our alarm function ceased after the April 28 ABBA download.  Although the icon is still illuminated, there is no alarm, and we cannot scroll right to select sounds.  I sent comments 17+ reporting alarm malfunctions in March, and reported the problem solved thereafter.

My alarm stopped functioning on April 28, 2008. I made no changes to any settings. The alarm had functioned perfectly prior to this. I tried resetting both through the player itself and through the SqueezeNetwork web page. But nothing changes.

All the settings show up, and are changeable. But the alarm simply does not turn on the device at e alarm time any more.

My info is:

Type: Squeezebox 3 
Player MAC Address: 00:04:20:07:af:59 
Player IP Address: 219.79.249.61 
Player Firmware Version: 86 

Alarm time set for 7:00 local time (GMT +8)

I fixed a bug related to alarms but it shouldn't have affected your player.  Alarms seem to be working fine for me.

This bug is not resolved! I just tested it 5 minutes after receiving Andy's notice. It still does not work. The player does not respond at the alarm setting time.

I forgot to mention the fix takes an hour to roll out to SN, so please try again in a bit.

STILL NOT RESOLVED.

Now the alarm does play at the proper time, but after the alarm starts, there are new problems:

1) When the alarm plays, the sound fades in, even though "Fade Alarm Sound" setting is not selected (i.e. it's off)
2) Squeezebox device freezes and will not respond to remote control: unable to navigate to menus, unable to turn off. I must unplug the device to shut it off.

When no alarm is playing, the Squeezebox responds normally to the remote, except:

3) Unable to change the "Fade Alarm Sound" setting through the device.

Alarm functioned properly this morning, coming on at 6 a.m. CDT on MPR as programmed.

Tested it again this morning. Still having the same problems listed above:

-Unable to change the setting for "fade in alarm sound"
-Alarm sound fades in, even though the setting appears to be stuck on "don't fade"
-Device freezes once alarm starts playing. Doesn't respond to remote control, and must be unplugged from the power source to shut it off.

Note also that when I try to change the alarm settings through the
SqueezeNetwork web page, I get the error page: "Oops! An error has
occurred. We're working to fix the problem, thank you for your patience"

Alarm FAILED to come on at 6 a.m. this morning.

Further comments:

As noted above, alarm comes on at the proper time, and did so this morning (my time: GMT+8). But it fades in, even though my setting is to not fade in. I am unable to change the fade-in setting either through the device or through the web page.

Regarding my SB3 freezing: it seems that the device does not respond to the remote control for around 60-90 seconds after the alarm begins. After that 60 to 90 seconds, it does respond to the remote. It seems that the problem may be related to the fade-in function, in that the device doesn't respond during the fade-in. Add to that the inability to change the fade-in setting, and it all seems to point to a bug within this function.

fyi, in the past we have experienced the same symptoms reported by Larry Feign (copied below).  They stopped upon the correction of the problems with the ABBA download.

(Text from Larry Feign):

As noted above, alarm comes on at the proper time, and did so this morning (my
time: GMT+8). But it fades in, even though my setting is to not fade in. I am
unable to change the fade-in setting either through the device or through the
web page.

Regarding my SB3 freezing: it seems that the device does not respond to the
remote control for around 60-90 seconds after the alarm begins. After that 60
to 90 seconds, it does respond to the remote. It seems that the problem may be
related to the fade-in function, in that the device doesn't respond during the
fade-in. Add to that the inability to change the fade-in setting, and it all
seems to point to a bug within this function.

Alarm functioned as programmed today.

Customers report this is not fixed.  

Email I received from the cusotmer. 

It seems like this bug is closed, even though I am STILL having
problems with the alarm.

First, I am unable to change the "alarm sound fade-in" setting. The
sound fades in, even though I have supposedly set it to not fade in,
by using the web interface (I can't change the setting on either of my
SB3 devices)

Second, the device still freezes up for the first 90 seconds that the
alarm sound begins. Here's what happens:

1) Alarm sound starts at appointed time
2) Alarm sound fades in for around 30 seconds
3) Attempt to turn off the SB3 with the remote control fails.
4) Also can't access any other settings with the remote control.
5) After around 90 seconds, SB3 goes into Stop mode (not off), with a
news ticker displaying (which I definitely did not set up in my
settings!)
6) After this happens, SB3 now responds to remote control.

I have unplugged and reset my SB3 several times.

It has been nearly two weeks, and there has been no progress with this bug. I can confirm that as of today, all of the above still occur. Plus a new one:

- When the Rooster crow sound plays, the name of the sound now appears in German rather than in English.

My wife 'allowed' me to buy a second SB3, to put in our bedroom, based on the alarm function (she depends on it, not me). She is now so fed up with it malfunctioning that she's buying a regular alarm clock instead. And Logitech can now forget about me ever convincing her to spend the money on a Transporter or other device.

Unless you fix the bug soon and mollify my wife.

I fixed the problem with the fade preference (don't test for 1 hour please).  I can't reproduce the frozen screen issue.

The only issue I am currently seeing with Alarms on SqueezeNetwork (sv) r3519/r19795 is that the Meta Data displayed when the alarm FIRST starts is not correct. 

About 15-30 seconds after the alarm first goes off, the meta data will change to the proper item.

In my testing, I found that my alarm would display the 1st item in my favorites list.  It would properly play the item I selected.

I was unable to replicate any other issues listed here.

Thanks for fixing the fade preference setting. Everything now works properly for me. Fade preference works, and SB3 no longer freezes when alarm goes off. I no longer have any issues about the alarm.

The issue with the wrong title being displayed when a weekday alarm is going off has been fixed.  There is still a possible issue with freezing UI that I can't reproduce at the moment.

Oh, no.  Not again!  Alarm failed to go off at 6 a.m. as programmed.  Unpredictability is not a virtuous attribute for an alarm ...

Alarm failed again today, June 2, 2008.  

In summary (most recent events only ...): 

Alarm failed to function Friday, May 23.  
Functioned as programmed Saturday, May 24, through Sunday, June 1.  
Failed to function June 2.  

HELP!!!  Why does the alarm function have to be so unpredictable?  It's one function you really need, and should be able, to count on!

Thanks in advance for support.

Alarm failed to go off at 0600 CDT this morning as programmed.  It had been functioning correctly for about a week prior.

On again, 6/16/2008.

NOT WORKING again 7/2/2008.

Still NOT WORKING July 3.  Reloaded software yesterday, but didn't help.

WORKING July 4, 2008.  Thank you!  

Alarms are totally rewritten in Devo, going to mark this fixed.

I realize this bug has been closed, however, the alarm failed to operate this morning.

(In reply to comment #61)
> I realize this bug has been closed, however, the alarm failed to operate this
> morning.
> 

Fran: Please remove all alarms you have set, then re-create them.  if you are still having issues, open a new alarm with steps on how to reproduce as well as the equipment you are using.

ok.  will reset alarms.

This bug has been fixed in the latest release of SqueezeNetwork!

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.