I have no problem with this.  I use 24H format and it seems to work fine.  Are you seeing anything in the log?  how about settings prefs logging for DEBUG level?

Created attachment 3547 [details]
Alarm Error

KDF: I checked and could only repro this on the Boom branch of 7.2

It appears to be the new alarm code that is causing the issue.

See attached log

Steps to Reproduce

Install 7.2 boom branch
Set SC clock to 24h
Clear all alarms if any are set for an attached boom
Attempt to set the time for a new alarm
Notice that the time field is always blank

hrm...my test was on the branch as well - timeFormat: "%H:%M:%S"

Are you entering the time with formatting?  ie 13:00 rather than 1300 ?  without the colon, it does fail, but with it I'm having no trouble.  See the following log ship:


[09:09:02.8189] Slim::Utils::Prefs::Base::set (114) setting server::timeFormat to "%H.%M.%S"
[09:09:12.0096] Slim::Utils::Prefs::Namespace::savenow (302) saving prefs for server to C:\Documents and Settings\All Users\Application Data\SqueezeCenter\prefs\server.prefs
[09:09:13.4948] Slim::Utils::Prefs::Base::set (114) setting server:de:c2:39:ac:b8:21:alarms to {
  b096ec34 => {
        _comment  => undef,
        _days     => [1, 1, 1, 1, 1, 1, 1],
        _enabled  => 1,
        _id       => "b096ec34",
        _playlist => "",
        _time     => 43_200,
        _volume   => 50,
      },
}

This definitely works for me - I tested it quite thoroughly with various different time formats.  Please confirm that it still doesn't work.  Also, how are you setting the alarm time - web ui or player ui.  Is this only when connected to squeeze network?

I'll have to retest this when SN and SC are synced for boom, as this was an SN error.  Thanks for all your work on verifying this Max and KDF

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

This is still happening on my systems with the latest build of SC 7.2 and r21.

I have reproduced this on MAC / Vista / XP.

There is no problem setting the time from the BOOM UI, only from SC/SN WEB UI.  Firefox / Opera / Safari all have the problem.

Either with or without the punctuation I have the problem.

Created attachment 3720 [details]
Log with ALARM debug info

Server log with Alarm Debug.  Note TIME = 0.00 when alarm is saved.  SC time format set to 24h (#7) hh,mm.

I still can't reproduce.  Exactly which time format are you using?  Mine is 24 hour (hh:mm:ss (24h)).  I've never seen this.

Reassigning to Michael as this issue only appears in web ui.

I have tested ALL of the 24h time formats.  The only one's I can get working are:

#1 - hh:mm:ss pm (12h)
#5 - h:mm (24h)
#8 - hh:mm pm (12h)
#11 - hh:mm:ss (24h)
#14 - h:mm:ss pm (12h)
#19 - h:mm pm (12h)

Notice that only the ones with : as the separator work.  if you have something else as the separator like ' or , then it will fail

the time format options are interfering with the strptime call that is supposed to give use the seconds to store as the pref.  Since that fails, 0 is stored.

the problem appears to be that strptime can only handle time formatted as HH:MM or hh:mm AM/PM.  The player UI uses this type of input, and the older web ui as well.  I've done some research and it doesn't look like there is any easy way to parse arbitrary formatted strings other than a complicated regex matching via Time::Normalize.  perhaps the Default skin ui can unparse the time string before submitting, as a reverse of what it's doing to show the formatted version of the string given through the template.

change 22342 - apply a rather simplistic fix, which should cover our cases: replace ,. separators with a colon before storing the alarm time.

Please test with our various formats. Thanks!

Feel free to re-open if this fix was too simplistic for your taste.

Tested with 7.222374, the fix appears to be working.

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

Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already.  

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