Bug 9354 - Issues with Alarms using CLI in 7.2
: Issues with Alarms using CLI in 7.2
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: CLI
: 7.2
: PC Windows XP
: -- normal (vote)
: 7.x
Assigned To: Max Spicer
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-31 23:21 UTC by Barry Gordon
Modified: 2009-09-08 09:18 UTC (History)
4 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Barry Gordon 2008-08-31 23:21:42 UTC
I am a little confused re the documentation regarding alarms in SC 7.2 CLI documentation and have noted some issues and at least one bug

1) How does one now set the Global alarm fade parameter over CLI? It is not under the alarm command but it does come back on an alarms request.

2) The day numbering between the alarm command and the alarms command is inconsistent.  It looks like alarms is as it was before, but alarm has changed.  To set an alarm for sunday I send alarm with a dow of 6, but if I want to do an alarms query for sunday I send alarms with a dow of 7.  Does not sound like the slimdevices way of doing things. 

3) In an alarms query the dow parameter always comes back with no values.
   ( ID alarms 0 10 filter:all) dow comes back as dow:

4) Is there any way to set snooze length and alarm timeout over CLI?

5) It would be nice if snooze length and alarmtimeout both came back as tagged items on an alarms query





TIA
Comment 1 Michael Herger 2008-09-02 01:31:36 UTC
Adding Ben - he's been implementing alarm control for the Controller.
Comment 2 Joerg Schwieder 2008-09-02 01:47:53 UTC
I think this is now mainly about #3 plus added CLI documentation (adding the preferences where one can find the parameters not available through the "alarm" and "alarms" CLI).
I can confirm #3: "alarms" only returns an empty string for "dow" no matter which days are set.
I feel #2 is also an issue, but I can't know, as #3 applies :-)
Comment 3 Joerg Schwieder 2008-09-02 02:15:11 UTC
Another one:
is this supposed to me the correct time format? It's what I get in the "time" parameter when calling "alarms" through JSON/RPC. Looks like a charset issue to me.

[code]
 "time" => 33_540,
[/code]
Comment 4 Barry Gordon 2008-09-02 05:15:34 UTC
To summarize the alarm issues I have re 7.2 and CLI:

1) dow is not returned on an alarms query

2) The playerprefrences and probably the serverpreferences also could use some documentation and should have some sort of an interface document plus wiki as they now seem to be a major way of getting and setting information. Maybe a table in the back of the CLI doc.  I would be willing to do the scut work if someone pointd me to where it all is.

3) alramfadeseconds, alarmTimeoutSeconds and alarmSnoozeSeconds as player prerences all work, but perhaps alarmfadeseconds should be alarmFadeSeconds

4) How does one turn the global fade on and off? Set alarmfadeseconds to 0?

5) Looking at alarms.pm there is discussion about time in seconds associated with a DOW vs epoch date.  Is epoch date alarm format documented and implemented  as a preference or as ... or not implemented yet

6) Is there any way of pulling back the sounds list that will show on the web interface but does not seem to be available over the CLI.  If it requires an http get the URL would be helpful.

7 Individual alarm volumes seem to work. How does one set the global default volume over the CLI - player or server prefrence if so which one

8) I can generally figure out where prefrences are stored and how to reference them, but I could not find alarmTimeoutSeconds nor alarmSnoozeSeconds.  Please advise where they are. (re (2))


Comment 5 Barry Gordon 2008-09-08 12:40:07 UTC
Some additional questions regardng alarms and CLI in version 7.2

1) How does one go about getting the state of the global prefrences/values
   All Alarms enabled ?
   Default volume setting.

2) I see how to set the "All Alarms Enabled" (I think) but the documentation in the CLI DOC on the alarm command is confusing.  It states that an id is needed to enable or disable all alarms, but that makes no sense as an alarm might not yet be established and should not be necessary.  perthaps this needs to be a player preference

3) Is there any way to set an epoch date/time over the CLI interface? If so how? 

If the alarm system as implemented for 7.2 is not going to be addressed/fixed please let me know so I can remove it from my Remote Control implementation.  As it stands no there are a lot of questions

This bug report is getting very little traction and that surprises/disappoints me.
   
Comment 6 Blackketter Dean 2008-09-09 07:41:40 UTC
max, would this be yours?
Comment 7 Max Spicer 2008-09-09 07:50:11 UTC
Only partially.  The CLI side of the new alarm code was done by Michael and Ben in order to support the web interface and controller requirements.  I don't want to start changing things here as I don't know the consequences - especially for the Controller code.
Comment 8 Barry Gordon 2008-09-13 12:11:16 UTC
Michael,

Any idea when you might be able to look at this.  The killer for me is the dow tag being empty on an alarms query command
Comment 9 Michael Herger 2008-09-15 01:53:59 UTC
change 23177 - fix the dow value in alarms query
Comment 10 Joerg Schwieder 2008-09-15 01:57:13 UTC
is this in 7.2.1?

Can you explain how the global Alarm works?
Comment 11 Michael Herger 2008-09-15 02:00:15 UTC
#2 - alarms should all be sunday=0 based now

Other than that I'm a bit confused about this report. What are the outsanding _bugs_? Documentation of the settings' values should be in the appropriate settings pages.

Jörg - what's the real value you'd have expected in that case 33_540? What would you get on the command line?
Comment 12 Michael Herger 2008-09-15 02:00:53 UTC
Yes, it's in 7.2.1.

What do you mean by "global alarm"?
Comment 13 Joerg Schwieder 2008-09-15 02:16:32 UTC
This was a PR on two issues:

1. "alarms" CLI didn't work
2. documentation is incomplete

It would be nice to have a documentation that allowed to actually implement/use the feature, this was not present in the versions we posted these bug reports on.
NOW there's some documentation in this bug, but this is a bug reporting tool, not development/usage documentation, so it would be nice to have that, too.
I didn't check on the latest builds but a few days ago it was not yet in, as it wasn't in the wiki.

You may feel this is two bugs rather than one.

Sorry for "global alarm", I meant "global volume".
Comment 14 Joerg Schwieder 2008-09-15 02:21:51 UTC
Sorry for the other one, that was the wrong bug.
Note to self: File a CR on the bug reporting system not to take you to other bugs after reporting something.

BTW, what do you mean by "in the appropriate settings pages"?
Maybe this is a principal thing:

My understanding is: the primary means of controlling SC these days is the CLI or the JSON/RPC IF. If you plan to use that, it's very inappropriate to have developer documentation in perl or html or js source files since these don't apply. 
Apart from source files generally not being appropriate as a means of documentation.
Comment 15 Michael Herger 2008-09-15 02:26:11 UTC
Max - may I ask you to take care of the documentation part? A comment about using the pref query to set some of the setting might do. Thanks!

Jörg - "the CLI _was_ broken"? Means it's fixed now? I thought I had only addressed one issue in a looong bug report.
Comment 16 Max Spicer 2008-09-15 02:29:29 UTC
Sure - I'll handle the docs.  Please pass this bug on to me if there's nothing but docs left.
Comment 17 Joerg Schwieder 2008-09-15 02:35:01 UTC
I said "alarms" CLI!
Will have to read the whole bug carefully to see what else may be wrong with the "alarm" CLI.

The broken "alarms" command prevented me from implementing the alarm feature, that is fixed now, anything else will just result in reduced functionality.
The doc part is important as well. I still don't understand hot to set a global volume, for example.
Comment 18 Michael Herger 2008-09-24 05:42:24 UTC
Max - assigning to you for the docs. Feel free to close this bug if you're already done. Thanks!
Comment 19 Max Spicer 2008-09-27 11:00:10 UTC
I've added alarm pref documentation in changes 23319 and 23320.  Barry/Joerg - please reopen if there are outstanding issues.

Re Description, point 5 - alarm timeout and snooze length are per-player settings not per-alarm so it doesn't really make sense to return them as tagged alarm parameters.

Re Comment 4, point 3 - alarmfadeseconds is lower case for backwards compatibility.  Its confusing name is also because that's how it's always been.

Re Comment 4, point 5 - epoch alarms aren't really implemented yet.  The underlying support is there, but there's no ui.  It may be possible to set them via the cli, having first read the docs in Slim::Utils::Alarm.pm.  YMMV.

Re Comment 4, point 6 - there is no way of pulling back the sounds list.  There probably should be.  I've filed Bug 9598 to track this.
Comment 20 James Richardson 2008-12-15 12:06:44 UTC
This bug has been fixed in the 7.3.0 release version 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.
Comment 21 Chris Owens 2009-07-31 10:28:40 UTC
Reduce number of active targets for SC