PDA

View Full Version : Will the CLI tell you what menu the client is in ?



Stuart
2006-10-17, 17:44
Hi...

Was wondering:

Will the CLI (Command Line Interface) tell you what menu a particular
client is in (i.e. top, album, title, radio, ect, ...)?

I was writing some client code and it is difficult to tell what menu you
are in just by looking at what the client's 2 line display is saying.
To say nothing of differences like "Playlist" vs. "Play list" which make
all the difference in the world.

...thanks

Fred
2006-10-18, 16:58
Currently it does not. Because of the graphics and screensavers this is actually a bit difficult to report cleanly.

There is already an enhancement request here <http://bugs.slimdevices.com/show_bug.cgi?id=2013>.

It would help designing a proper API if you could explain me your motivation for such a query. What are you trying to accomplish ? (you can post here or in the bug)

Fred

Stuart
2006-10-18, 21:19
Hi Fred...

Thanks for taking the time.

I was trying to create a slimserver client. In most applications it
will be connected to a TV monitor. So, a full screen of, say, titles
would be desirable. The project started out emulating the old
slimdevices hardware clients. As such all remote control key presses
passed through the slimserver program. However, taking a second pass at
the full screen feature, I am starting to realize it may be more
difficult to create full screen menus using this paradigm. Given the
rich CLI command set, it is starting to appear the best approach is to
create, control and manage the full screen menus at the client and only
ask the server for data when necessary.

Alas, I am half way down the road using the slimserver driven menu
paradigm. So, in order to make this easer, I am asking for new CLI
commands to indicate what menu the server is in and (now that I think
about it), what item (numerically) am I looking at. Take title selection
for instance. There are at least 2 menus where the user can select
titles. The "NowPlaying" and the "Browse" menus for example. In both
you use the up / down and enter keys to select a title. But, if you
were to key off the text on the display to figure out what title had
"focus", you would almost have to write 2 different programs. The text
and what pops up as you scroll up and down is that different. And I
haven't touched on the dependency such a program would have on text
changes. A simple change from "Playlist" to "Play List" is enough to
cause problems.

If we could inquire slimserver about which menu and which item in that
menu was in "focus", we could easily and dependably re-create full
screen versions of the current menu. That and I wouldn't have to write
crazy programs trying to match one of a dozen key phrases.


Fred wrote:
> Currently it does not. Because of the graphics and screensavers this is
> actually a bit difficult to report cleanly.
>
> There is already an enhancement request here
> <http://bugs.slimdevices.com/show_bug.cgi?id=2013>.
>
> It would help designing a proper API if you could explain me your
> motivation for such a query. What are you trying to accomplish ? (you
> can post here or in the bug)
>
> Fred
>
>

Fred
2006-10-19, 05:48
Your requests sounds to me like a desire to "skin" the player interface (i.e. present all relevant info to some software layer that may then present it how it wants).

I understand the request and it seems coherent with the existing bug.

Now I think you'd be better off using requests like "artists", "titles", etc, and build your UI on the client. In full screen mode on a TV, I guess showing only 2 lines at a time may leave a lot of unused blank space which could be put to better use displaying a number of lines.


HTH

Fred

Stuart
2006-10-19, 06:37
Hi Fred...

I hear you ...:

"start over" & "this time, do it all on the client"

But that leads you to ...:

"don't let slimserver process the remote control information, do it
your self" & "make your own decisions regarding how the menus are put
together"

Trouble is that I'm already done with the "let slimserver control
everything" code and I don't really want to start over. That plus if I
had to control the logic behind the menus, well, that would be yet
something else I would have to debug.

But, you are right, the CLI commands are rich enough to move the menu
logic to the client. I wish I saw that a year ago.

You description is very structured which gives me an idea. It will be
messy, but I could create a layer of code to decode the 2 line display
into what menu and (maybe) what item had focus. I would still like to
see the "bug / request" solved. But this might get us by with a few
complaints for the time being.

...thanks

P.S. While we are talking about the CLI, here's another question:

Is there a way to pull the entire string of the 2 line display. That
is, the 2 line display will be scrolled by slimserver given the line is
longer than 40 characters. Is there a CLI command that will pull the
entire string - even if it is longer than 40 characters?

...thanks

Fred wrote:
> Your requests sounds to me like a desire to "skin" the player interface
> (i.e. present all relevant info to some software layer that may then
> present it how it wants).
>
> I understand the request and it seems coherent with the existing bug.
>
> Now I think you'd be better off using requests like "artists",
> "titles", etc, and build your UI on the client. In full screen mode on
> a TV, I guess showing only 2 lines at a time may leave a lot of unused
> blank space which could be put to better use displaying a number of
> lines.
>
>
> HTH
>
> Fred
>
>

TheEndless
2006-10-19, 14:11
I was trying to create a slimserver client. In most applications it will be connected to a TV monitor.
It sounds like you might be working on something similar to what I did for the Roku PhotoBridge HD Media Player. My app is heavily reliant on the CLI interface. You can see some screenshots here that might give you some ideas: http://www.permanence.com/slimroku/

Note: The "LCD/VFD" in the top center of the screen is an emulated version of the 2-line SqueezeBox display and is the main control point for all remote commands when on the Now Playing screen. That display is the heart of the whole application. It's essentially a SqueezeBox/SoftSqueeze running in a window. If the user wants, they can use that display to control the application just as they would a SqueezeBox. The rest of the application (music library, cover art browser, playlists, etc) gets its information from and controls SlimServer via the CLI in realtime.

TheEndless

Stuart
2006-10-19, 20:53
Hi Steve...

TheEndless wrote:
> stuart;147562 Wrote:
>> I was trying to create a slimserver client. In most applications it
>> will be connected to a TV monitor.
> It sounds like you might be working on something similar to what I did
> for the Roku PhotoBridge HD Media Player. My app is heavily reliant on
> the CLI interface. You can see some screenshots here that might give
> you some ideas: http://www.permanence.com/slimroku/

Wow.

> Note: The "LCD/VFD" in the top center of the screen is an emulated
> version of the 2-line SqueezeBox display and is the main control point
> for all remote commands when on the Now Playing screen. That display
> is the heart of the whole application. It's essentially a
> SqueezeBox/SoftSqueeze running in a window. If the user wants, they
> can use that display to control the application just as they would a
> SqueezeBox. The rest of the application (music library, cover art
> browser, playlists, etc) gets its information from and controls
> SlimServer via the CLI in realtime.
>
> TheEndless

....nice, everything I want to do plus enough graphics to choke my
platform (I'll have to pass on that for now). So - got some questions:

You kept the 2 line display - interesting - is the information still
controlled by the slimserver program or did you derive it locally?

Do you still send all the remote control key presses to the slimserver
program first - or - do you process them locally?

If you process them (remote control key presses) locally, do you then
turn around and ask slimserver using the CLI for the songs you want?

Going on, if you process them (remote control key presses) locally, and
slimserver is controlling the 2 line display.... well, how did you get
that to work? I mean if slimserver isn't processing the key presses as
they are received by the roku box, then the 2 line display will become
"out of sync" with what is going on - won't it?

I see where you hilite what has focus on the roku display. Is this
"what is playing" or is this "what the user is looking at"?

If the above is "what the user is looking at" - well, how did you do
that? I process my remote control key presses through the slimserver
program and figuring out what the users is looking at is problematic.

....hey, if you could answer these questions I would really appreciate
it. If nothing else, it gives me something to shoot for...

...thank

TheEndless
2006-10-20, 17:08
You kept the 2 line display - interesting - is the information still controlled by the slimserver program or did you derive it locally?
It's completely controlled by SlimServer (via the grfe SlimProto command).


Do you still send all the remote control key presses to the slimserver program first - or - do you process them locally?
When on the Now Playing screen, all IR commands are passed on to SlimServer (again, via the SlimProto protocol). The only exceptions are the IR commands to bring up the menu to open the library interface.


If you process them (remote control key presses) locally, do you then turn around and ask slimserver using the CLI for the songs you want?
In the music library, I query SlimServer for genres, artists, albums, and tracks via the CLI. When the user highlights an item and presses play, I pass the command to the CLI to add the selected track(s) to the current playlist.


Going on, if you process them (remote control key presses) locally, and slimserver is controlling the 2 line display.... well, how did you get that to work? I mean if slimserver isn't processing the key presses as they are received by the roku box, then the 2 line display will become "out of sync" with what is going on - won't it?
All remote presses (on the Now Playing screen) that are relevant to navigating the display are passed on the SlimServer, which in response, sends the grfe command to update the display.


I see where you hilite what has focus on the roku display. Is this "what is playing" or is this "what the user is looking at"?
If the above is "what the user is looking at" - well, how did you do that? I process my remote control key presses through the slimserver program and figuring out what the users is looking at is problematic.
All highlights are of what the user currently has selected in SlimRoku. The only "what is playing" data is on the main Now Playing screen, which is queried for via the CLI.


....hey, if you could answer these questions I would really appreciate
it. If nothing else, it gives me something to shoot for...

...thank
No problem. I hope I made sense :p

TheEndless

Stuart
2007-01-14, 15:26
Hi Fred...

Fred wrote:
> Currently it does not. Because of the graphics and screensavers this is
> actually a bit difficult to report cleanly.
>
> There is already an enhancement request here
> <http://bugs.slimdevices.com/show_bug.cgi?id=2013>.
>
> It would help designing a proper API if you could explain me your
> motivation for such a query. What are you trying to accomplish ? (you
> can post here or in the bug)
>
> Fred

I was wonder on the state of this "enhancement". Or better put, I am,
for one, still interested in this feature. That is, I am trying to
write a slimserver client and have run into the situation of not knowing
what menu the server is in. It sounds silly, but I wanted to make the
client more feature rich. In order to do that I need to know which menu
the server is in. Many of the server's menus look the same (i.e. there
are several different server states that display the title of the music
of interest). To tell the exact state of the server using 1 CLI command
would change a guessing game into an easy 1 evening coding job.

Yes, I realize if I stuck with ONLY the Command Line Interface (CLI)
most if not everything would be absolute (i.e. I would absolutely be
playing a particular play list). But I already have a good base of code
that interfaces with the normal slimserver ports that I do not want to
abandon.

...thanks

Fred
2007-01-15, 15:54
I am afraid I did not find any time to progress on this, and it looks like it won't be before some time. There is another more pressing project that requires my attention.

Hopefully some other volonteer can help?

Fred

Stuart
2007-01-16, 19:00
Hi Fred...

Fred wrote:
> I am afraid I did not find any time to progress on this, and it looks
> like it won't be before some time. There is another more pressing
> project that requires my attention.
>
> Hopefully some other volonteer can help?
>
> Fred

Can you give me enough information so that I can evaluate if I want to
do this modification?

For instance - slimserver is written all in PERL. These are the places
to insert a new CLI command. Here is where you would define a variable
to track the state of the server. These are the routines that are
jumped to when the server states are changed. That sort of stuff...

...thanks

Stuart
2007-04-06, 11:02
Hi...

stuart wrote:
>
> Hi Fred...
>
> Fred wrote:
>> I am afraid I did not find any time to progress on this, and it looks
>> like it won't be before some time. There is another more pressing
>> project that requires my attention.
>>
>> Hopefully some other volonteer can help?
>>
>> Fred
>
> Can you give me enough information so that I can evaluate if I want to
> do this modification?
>
> For instance - slimserver is written all in PERL. These are the places
> to insert a new CLI command. Here is where you would define a variable
> to track the state of the server. These are the routines that are
> jumped to when the server states are changed. That sort of stuff...
>
> ...thanks

I was wondering if any of the developers were considering this feature:

"CLI command to disclose the menu and / or state slimserver is currently
in."

....In trying to write code for a full screen client, the CLI interface
has been indispensable. However, it is difficult to predict and / or
track the state of the server. Something which is necessary when
showing the user what his or her current options are. True, you could
completely ignore the states of slimserver and ask for one song at a
time - but you give up a lot of slimserver features when you do that.

....thanks

mherger
2007-04-08, 22:40
> I was wondering if any of the developers were considering this feature:
>
> "CLI command to disclose the menu and / or state slimserver is currently
> in."

Have a look at Felix' ShadowPlay plugin. It does mirror a player's display
content on another player. You could use the same method for your own
needs, probably enhancing that plugin with a CLI.

--

Michael

-----------------------------------------------------------------
http://www.herger.net/SlimCD - your SlimServer on a CD
http://www.herger.net/slim - AlbumReview, Biography, MusicInfoSCR

Stuart
2007-04-09, 07:23
Hi Michael...

Michael Herger wrote:
>> I was wondering if any of the developers were considering this feature:
>>
>> "CLI command to disclose the menu and / or state slimserver is currently
>> in."
>
> Have a look at Felix' ShadowPlay plugin. It does mirror a player's display
> content on another player. You could use the same method for your own
> needs, probably enhancing that plugin with a CLI.

Thanks for your suggestion. I already use the CLI in the client I am
helping to develop. By that I mean that I am dumping and analyzing the
display (not a very clean solution). However, there are cases where you
just don't know where you are. I think browsing an album and moving
through the now playing list is an example (i.e. they both look the
same). Some clients like slimRoku get around this by implementing the
softSqueeze program inside there own screen menus. However, I think the
cleanest solution for these full screen clients (i.e. clients that
display more than the just 2 lines of information) is to provide the
current state of the server. The extreme alternative is to ignore
slimserver for most everything except serving up music and assume
responsibility for most of the features (already built into slimserver)
on the client.