PDA

View Full Version : CLI working in 5.0.1?



Peter Heslin
2003-11-30, 13:20
When I run the old version of the server, the CLI interface works fine,
but with 5.0.1 from CVS, it doesn't work at all. Is this just something
weird about my setup, or is there really a bug? I tried with both
triplefat and a slimp3 client. Here is an example that works fine, when
using an older version (4.1b1):

$ telnet localhost 9090
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
127.0.0.1:34993 display ? ?
127.0.0.1%3a34993 display SLIMP3%20Home Now%20Playing%20%20%20%20%20%20%20%20%20%20%20%20% 20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20vfD _rightarrow_Vfd

But when I try the same with 5.0.1 (downloaded from CVS a couple of days
ago), the CLI interface doesn't successfully issue any commands. For
example:

$ telnet localhost 9090
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
127.0.0.1:34993 mode play
127.0.0.1%3a34993 mode play
127.0.0.1:34993 display ? ?
127.0.0.1%3a34993 display %3f %3f

No music plays when I do this. Needless to say, the client does not in
fact have ? ? on its display at the time. Here's the output from server
STDERR with various debugging options enabled:

2003-11-29 00:00:33 Accepted connection 1 from 127.0.0.1
2003-11-29 00:00:47 Clients: 127.0.0.1:34993 192.168.2.100:3483
2003-11-29 00:00:47 Processing command: 127.0.0.1:34993 mode play
2003-11-29 00:00:47 Executing command 20:20:20:20:20:20: 127.0.0.1:34993 (mode) (play) () () () ()
2003-11-29 00:00:47 Returning array: 127.0.0.1:34993 (mode) (play) () () () ()
2003-11-29 00:00:47 command line interface response: 127.0.0.1%3a34993 mode play2003-11-29 00:00:47 Ready to accept a new command line interface connection.
2003-11-29 00:00:47 Sending response
2003-11-29 00:00:47 No more messages to send to 127.0.0.1
2003-11-29 00:02:14 Clients: 127.0.0.1:34993 192.168.2.100:3483
2003-11-29 00:02:14 Processing command: 127.0.0.1:34993 display ? ?
2003-11-29 00:02:14 Executing command 20:20:20:20:20:20: 127.0.0.1:34993 (display) (?) (?) () () ()
2003-11-29 00:02:14 Returning array: 127.0.0.1:34993 (display) (?) (?) () () ()
2003-11-29 00:02:14 command line interface response: 127.0.0.1%3a34993 display %3f %3f2003-11-29 00:02:14 Ready to accept a new command line interface connection.
2003-11-29 00:02:14 Sending response
2003-11-29 00:02:14 No more messages to send to 127.0.0.1

Can anyone confirm if this bug exists, or if it is just me?

Peter

dean
2003-12-01, 15:18
Peter,

What happens if you just send the command without the address, does it
work then?

-dean

On Nov 30, 2003, at 12:20 PM, Peter Heslin wrote:

> When I run the old version of the server, the CLI interface works fine,
> but with 5.0.1 from CVS, it doesn't work at all. Is this just
> something
> weird about my setup, or is there really a bug? I tried with both
> triplefat and a slimp3 client. Here is an example that works fine,
> when
> using an older version (4.1b1):
>
> $ telnet localhost 9090
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> 127.0.0.1:34993 display ? ?
> 127.0.0.1%3a34993 display SLIMP3%20Home
> Now%20Playing%20%20%20%20%20%20%20%20%20%20%20%20% 20%20%20%20%20%20%20%
> 20%20%20%20%20%20%20%20%20vfD_rightarrow_Vfd
>
> But when I try the same with 5.0.1 (downloaded from CVS a couple of
> days
> ago), the CLI interface doesn't successfully issue any commands. For
> example:
>
> $ telnet localhost 9090
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> 127.0.0.1:34993 mode play
> 127.0.0.1%3a34993 mode play
> 127.0.0.1:34993 display ? ?
> 127.0.0.1%3a34993 display %3f %3f
>
> No music plays when I do this. Needless to say, the client does not in
> fact have ? ? on its display at the time. Here's the output from
> server
> STDERR with various debugging options enabled:
>
> 2003-11-29 00:00:33 Accepted connection 1 from 127.0.0.1
> 2003-11-29 00:00:47 Clients: 127.0.0.1:34993 192.168.2.100:3483
> 2003-11-29 00:00:47 Processing command: 127.0.0.1:34993 mode play
> 2003-11-29 00:00:47 Executing command 20:20:20:20:20:20:
> 127.0.0.1:34993 (mode) (play) () () () ()
> 2003-11-29 00:00:47 Returning array: 127.0.0.1:34993 (mode) (play) ()
> () () ()
> 2003-11-29 00:00:47 command line interface response: 127.0.0.1%3a34993
> mode play2003-11-29 00:00:47 Ready to accept a new command line
> interface connection.
> 2003-11-29 00:00:47 Sending response
> 2003-11-29 00:00:47 No more messages to send to 127.0.0.1
> 2003-11-29 00:02:14 Clients: 127.0.0.1:34993 192.168.2.100:3483
> 2003-11-29 00:02:14 Processing command: 127.0.0.1:34993 display ? ?
> 2003-11-29 00:02:14 Executing command 20:20:20:20:20:20:
> 127.0.0.1:34993 (display) (?) (?) () () ()
> 2003-11-29 00:02:14 Returning array: 127.0.0.1:34993 (display) (?)
> (?) () () ()
> 2003-11-29 00:02:14 command line interface response: 127.0.0.1%3a34993
> display %3f %3f2003-11-29 00:02:14 Ready to accept a new command line
> interface connection.
> 2003-11-29 00:02:14 Sending response
> 2003-11-29 00:02:14 No more messages to send to 127.0.0.1
>
> Can anyone confirm if this bug exists, or if it is just me?
>
> Peter
>

Peter Heslin
2003-12-01, 17:44
On Mon, Dec 01, 2003 at 02:18:30PM -0800, dean blackketter wrote:
> Peter,
>
> What happens if you just send the command without the address, does it
> work then?

Your crystal ball is working well -- the CLI works when I omit the
client address. That is to say, "display ? ?" correctly returns the
display of the client which is the first or zero-index client (the one
returned by "server name 0 ?"). So what does this clue tell you about
the behavior I am seeing?

Peter

dean
2003-12-01, 19:57
What does:

player address 0 ?

return

and if you use the address returned, does it work? (It will return a
MAC-style identifier, not the IP address.)

It may be that using the IP addresses doesn't work anymore and just the
MAC-style identifiers does. IP addresses might change, but the MAC
address that the player uses to identify itself won't.

Even so, this wasn't intended to break, but using the address returned
as above is the proper way to do it.

-dean


On Dec 1, 2003, at 4:44 PM, Peter Heslin wrote:

> On Mon, Dec 01, 2003 at 02:18:30PM -0800, dean blackketter wrote:
>> Peter,
>>
>> What happens if you just send the command without the address, does it
>> work then?
>
> Your crystal ball is working well -- the CLI works when I omit the
> client address. That is to say, "display ? ?" correctly returns the
> display of the client which is the first or zero-index client (the one
> returned by "server name 0 ?"). So what does this clue tell you about
> the behavior I am seeing?
>
> Peter
>
>

Peter Heslin
2003-12-01, 20:48
On Mon, Dec 01, 2003 at 06:57:34PM -0800, dean blackketter wrote:
> What does:
>
> player address 0 ?
>
> return
>
> and if you use the address returned, does it work? (It will return a
> MAC-style identifier, not the IP address.)
>
> It may be that using the IP addresses doesn't work anymore and just the
> MAC-style identifiers does. IP addresses might change, but the MAC
> address that the player uses to identify itself won't.
>
> Even so, this wasn't intended to break, but using the address returned
> as above is the proper way to do it.

The MAC-style addresses work correctly. Assuming I can get at these
identifiers via $client->macaddress, that should get me back on track.
All of the docs use the IP-address, so that's all I ever thought to use.

Thanks for the help,

Peter

dean
2003-12-01, 21:09
The correct way to get the addresses is to use

player address 0 ?

to get the zeroth player's address. The 5.0.1 CLI documentation does
use the MAC style addresses, but there may be other places I missed...
Pointers welcome...

-dean

On Dec 1, 2003, at 7:48 PM, Peter Heslin wrote:

> On Mon, Dec 01, 2003 at 06:57:34PM -0800, dean blackketter wrote:
>> What does:
>>
>> player address 0 ?
>>
>> return
>>
>> and if you use the address returned, does it work? (It will return a
>> MAC-style identifier, not the IP address.)
>>
>> It may be that using the IP addresses doesn't work anymore and just
>> the
>> MAC-style identifiers does. IP addresses might change, but the MAC
>> address that the player uses to identify itself won't.
>>
>> Even so, this wasn't intended to break, but using the address returned
>> as above is the proper way to do it.
>
> The MAC-style addresses work correctly. Assuming I can get at these
> identifiers via $client->macaddress, that should get me back on track.
> All of the docs use the IP-address, so that's all I ever thought to
> use.
>
> Thanks for the help,
>
> Peter
>
>

Peter Heslin
2003-12-02, 04:41
On Mon, Dec 01, 2003 at 08:09:56PM -0800, dean blackketter wrote:
> The correct way to get the addresses is to use
>
> player address 0 ?
>
> to get the zeroth player's address.

If you look back at my lonely e-mail in an earlier thread regarding the
changes to the server that I suggested making in order to permit
transport and transcoding of streams by an external Real Audio / Windows
Media to mp3/wav converter, I was suggesting that the client address
should be put in an environment variable before launching the
player/transcoder, so that this external process could feed textual
output to the client's display. That's what I've been trying to
implement.

Anyway, I have transcoding of Real/Windows streams working now, and I
just need to get the client display working. So the server needs to
tell the player/transcoder which client's display to manipulate, and I
am now planning to do that like so:

$ENV{SLIM_CLIENT} = Slim::Player::Client::macaddr($client)

Is this right, or is there a more correct way?

> The 5.0.1 CLI documentation does
> use the MAC style addresses, but there may be other places I missed...
> Pointers welcome...

Sorry, I was looking at the web page
http://www.slimp3.com/documentation/crestronCLI.html
which uses IP-style addresses.

Peter

dean
2003-12-02, 08:52
Hi Peter,

On Dec 2, 2003, at 3:41 AM, Peter Heslin wrote:

> On Mon, Dec 01, 2003 at 08:09:56PM -0800, dean blackketter wrote:
>> The correct way to get the addresses is to use
>>
>> player address 0 ?
>>
>> to get the zeroth player's address.
>
> If you look back at my lonely e-mail in an earlier thread regarding the
> changes to the server that I suggested making in order to permit
> transport and transcoding of streams by an external Real Audio /
> Windows
> Media to mp3/wav converter, I was suggesting that the client address
> should be put in an environment variable before launching the
> player/transcoder, so that this external process could feed textual
> output to the client's display. That's what I've been trying to
> implement.

Sorry for not commenting on your previous e-mail. It was important and
complex enough that I didn't have enough brains to deal with it at the
time. I will later today.

>
> Anyway, I have transcoding of Real/Windows streams working now, and I
> just need to get the client display working. So the server needs to
> tell the player/transcoder which client's display to manipulate, and I
> am now planning to do that like so:
>
> $ENV{SLIM_CLIENT} = Slim::Player::Client::macaddr($client)
>
> Is this right, or is there a more correct way?

Environment variables are a great idea for transcoding. For that
specific case, use

$ENV{SLIM_CLIENT} = $client->id();

as this is the unique identifier. The MAC address is the same as the
ID for SLIMP3 & Squeezebox, but not for HTTP clients.

>
>> The 5.0.1 CLI documentation does
>> use the MAC style addresses, but there may be other places I missed...
>> Pointers welcome...
>
> Sorry, I was looking at the web page
> http://www.slimp3.com/documentation/crestronCLI.html
> which uses IP-style addresses.

Yeah, another thing on my list to fix. Sorry for the confusion.

-dean