you could use kdf's Alarm plugin which does (amongst others) exactly this.
http://www.deane-freeman.com/slimserver/

I feel that this simple feature should become part of the main application, and
not an addon.  The trouble with Plugins, is that they can sometimes break
between updates, and you have to wait for the plugin developer to catch up. 
Normally this isn't a big issue, but when relay on the alarm to wake you up for
work, it's more reassuring to know the Alarm feature is part of the stable
application, and not a 3rd party plugin.

Luckily the plugin's author not only is one of the most active developpers, but also relying on his plugin 
himself. I've never had to wait for an update after updating the server. 

This kind of thing has come up many times before.  The design is for a SIMPLE
alarm in core, leaving extentions for elsewhere.  The caution, I'm sure, is that
if you add one more feature, you get forced into adding more and more, all under
the statement "but its only a simple change".

I'm perfectly willing to incorporate any aspect of the plugin to the core.  If
this is desired, then Slim Devices can assign this to me. 

In my own defense, however, I do have to point out that when it comes to the
Alarm Plugin, I'm likely more up to date than the built in alarm should anything
break it.  The only difference is, its a separate download. The point regarding
plugin delays is usually valid.  The AlarmPlugin, I feel, is probably one of the
worst examples to use in defense of that point.

To make another point: a major gain in sticking to the lines when plugins come
along is that it DOES free up the core devs for working on the really important
core features, instead of dealing with all the sideline functions, which, if
they ever did stick to being simple, would not break as often as they do :)

Getting this one off the 6.1 radar.

I'd like to consider adding a set of 7 day-of-week alarms to the default alarm plugin.  Essentially, to the 
existing alarm menu, we'd add an item "Weekday Alarms", in there there'd be 7 items, one for each day:

Monday (7:00am)
Tuesday (off)
Wednesday (7:00am)
etc....

Under each of those would be a set of settings for the alarms (time, alarm sounds, etc...)

KDF: what do you think?

7 settings groups, yeah, seems doable. I've done this with the plugin, but only
via installing copies of the module.  Will be a bit different to make it all
work from one central module.

Dean, the time display in brackets seems to be a Squeezenetwork thing.  Any
chance I can get at the code for that instead of having to add something similar
with new, and maybe different code?

otherwise, got most of it going already.  just the alarm on/off that's still
being difficult.

Created attachment 750 [details]
add weekday player UI

this is what I have so far.  it seems to work.	There is an upgrade script to
change the alarm prefs into arrays, and a submenu for weekday alarm.  Still
some cleanup here.  the weekday isn't saved, so going into that menu is always
Monday, but this could go to the last selected day OR the current day by
default.  I also still need to see the ccode for showing the time in parens for
each.

The [x] bit is handled by INPUT.Choice with an overlay ref.  Here's a sample:

               'settings/SETUP_LONGDATEFORMAT' => {
                        'useMode' => 'INPUT.Choice',
                        'listRef' => \@dateFormatChoices,
                        'header' => "{SETUP_LONGDATEFORMAT} {count} {PRESS_TO_SELECT}",
                        'name' => sub { 
                                my ($client, $item) = @_;
                                # format current time in current format option 
                                return $client->longDateF(undef, undef, $item);
                        },
                        'onRight' => sub {
                                my ($client, $item) = @_;
                                Slim::Utils::Prefs::clientSet($client, 'longdateFormat',  
                                                                                          $item);
                                $client->showBriefly($client->string('SAVING_SELECTION'));
                        },
                        'initialValue' => sub {return Slim::Utils::Prefs::clientGet($_[0], 'longdateFormat')},
                        # overlay shows checkmark next to selected option
                        'overlayRef' => sub {
                                my ($client, $item) = @_;

                                if ((Slim::Utils::Prefs::clientGet($client, 'longdateFormat') || '') eq $item) {
                                        return [undef,"[x]"]; # use "x" until we have checkmark
                                } else {
                                        return [undef,"[ ]"];
                                }

                        },
                },

Thanks.  What about the lines for displaying the time: "Alarm Clock (19:55)"?

Created attachment 753 [details]
updated alarm module

this should do it.  give 'er a test, or I can commit and let everyone else at
it.

Go ahead and commit and Iet folks have a play.  Will comment on what I see.

One more thing.  Why are you removing the old alarm setting?  I think that we should have the same 
Alarm settings for the "every day" alarm, we're also adding 7 more alarms, one for each weekday.  So 
there's a new set of prefs in an array for each day, but the old alarm should be in place.  Right?

I'm not removing the old pref, but I do have ot move it into the array or yaml causes a crash when I try 
to use the same names.  So, what we'll have is day 0-7 where day 0 is every day and 1-7 are each day.  

Just as more info on the pref change.  Having it all as a single array gives me
more code reuse, since I can simply re-enter the existing alarm mode with a
param. Using 0 for every day means I can do a simply if ($day) and get a
true/false for everyday/oneday.  

committed to trunk at change 4024

I'm late... but the new alarm setting does break the player setting's web 
interface (or has it been broken since moving to yaml?). The volume setting is a 
text field containing a hash reference.

thanks michael.  patched at change 4029.  its a bit of overkill, perhaps, with
the   currentValues, but they didn't want to appear using this style of UI with
array prefs.  I still need to figure out what kind of web UI would be right for
the weekday alarms.  Dean, got any ideas? I think it could be 7 groups, one for
each day just like the one we already have.  Or we use the array templates to
somehow make something work here.

I'd make an eight row table like this:

Alarm Clock

You can set up alarms that will turn on your player and play a saved playlist every day or on days of the 
week.  Enter a time, volume level (0-100) and choose a playlist below.

                                Time           Volume   Playlist
Every day:        [on]   [ 9:00am]    [50]        [Morning Music]
Monday:          [off]   [12:00am]    [50]       [                      ]
Tuesday:         [off]   [12:00am]    [50]       [                      ]
Wednesday:    [off]   [12:00am]    [50]       [                      ]
Thursday:       [off]   [12:00am]    [50]       [                      ]
Friday:            [off]   [12:00am]    [50]       [                      ]
Saturday:        [off]   [12:00am]    [50]       [                      ]
Sunday:          [off]   [12:00am]    [50]       [                      ]

(Change)

ah yes. we'll need a new template to do this, that allows pulldowns in the
table.  or, I may find a way to 'fake' it using a group for each row.

When in doubt, ask the oracle of Moser.  :)

and so I will.  

Robert, any thoughts on how this kind of template could be implemented?

I don't believe that a simple template will work for this.  This kind of
arrangement will require some backend work as well.  The current setup.pm just
isn't flexible enough for this.

It might be best to just overhaul setup.pm such that the template engine handles
most of the layout work.  Then we can come up with a way of expressing this
arrangement a bit better.

That's what I thought.  I guess we need something short term.  I'll do it with
multiple groups for now.  Its the only thing on that page, so it won't be
compeltely horrible.  An overhaul of setup might be good for 6.5 or 7 roadmap

Created attachment 773 [details]
web UI

here is the web setup UI.  Its not the desired layout, but it is what the
server can generate for now. Seems to work, tho I haven't given it full testing
with existing prefs (since mine were wiped by bug2009) 

 I've also added some code to to Prefs.pm.  Theory is there that an existing
scalar pref can be converted into an array pref (so no upgrade script needed).
feedback welcome.  I know I may not be taking into account all problems caused
by allowing this.

The prefs code is flawed.  You don't delete the scalar pref before setting the
new hash pref, which will most likely cause an error.  For the array pref
conversion, you store the old value in $old, but when you set the [0] index you
use $prefs{$key}, which you just deleted.

erk, yes.  diffed before I saved.  I wasn't sure how to deal with the old value
if it gets moved into hash pref.  I suppose I could use '0' as well?  What would
make the most sense?  I suppose anything could be set now, since we don't have
any hash prefs that I know of as yet.

Created attachment 774 [details]
prefs conversion code

I just went ahead with '0' as the old when converting to hash pref.  It can be
anything sensible as long as we set it to something.

committed the Alarm web settings at change 4117
layout is about as good as I can see doing with the existing framework.   We can
close this, or leave it retargetted for a version with some setup rework. Prefs
change was only a passing thought