Getting 'Status' for multiple players simultaneoulsy

[meep]

Hi

Using the jsonrpc.js command interface from my plugin, I'm currently getting basic information an all players using the 'players' command;

{"id":1, "method":"slim.request", "params":[ "", [ "players","0","50", "playerprefs:volume"]]}

However, I find in testing that not all device types return the same information (eg squeezebox3 and boom don't seem to include power and isplaying states while touch, softsqueeze and radio do). Is this a known issue?

Because of this and as I need further details around playlists etc., I've been looking at the 'status' command.

Now, due to the nature of the application (Alexa<->Plugin), it's inefficient to issue discrete 'Status' commands from the cloud service to the LMS for each device as the round trip time adds up. My design approach is to NOT build commands in the plugin but rather have it parse commands passed in but I'd be prepared to make an exception in this case.

Therefore, I have a few questions....

Is there a form of status that's similar to players in that no playerid is required eg (which I've tried unsuccessfully);

{"id":1, "method":"slim.request", "params":[ "", [ "status","0","2", "tags:"]]}

If not, I can of course iterate through the players and issue the command to each in turn. However, this gets very messy inside the plugin using Slim::Networking::SimpleAsyncHTTP

I would therefore wonder, is there a convenient solution that could use Slim::Player::Client::clients() to obtain similar or equivalent return data to a status command?

I've tried this but the volume of data return is immense;

foreach $client (Slim::Player::Client::clients()) {
          myDebug("Client details = ".Dumper($client));
      }

Any pointers appreciated!

Peter

[mherger]

Getting 'Status' for multiple playerssimultaneoulsy

> However, I find in testing that not all device types return the same
> information (eg squeezebox3 and boom don't seem to include power and
> isplaying states while touch, softsqueeze and radio do). Is this a known
> issue?

Hmm... I can't see how different player types would possibly result in
different responses?!? That said: the server version does. The "players"
command did only return little information in 7.8 and older. I'd
therefore suggest you go with the "serverstatus", which basically
returns the same information (in addition to some server related
pieces). But the difference between 7.9 and older versions is smaller
than with "players".

> If not, I can of course iterate through the players and issue the
> command to each in turn. However, this gets very messy inside the plugin
> using Slim::Networking::SimpleAsyncHTTP

You can run queries directly, no need to go through http requests. See
eg.

https://github.com/Logitech/slimserver/blob/public/7.9/Slim/Web/Pages/Playlist.pm#L144

--

Michael

[meep]

> However, I find in testing that not all device types return the same
> information (eg squeezebox3 and boom don't seem to include power and
> isplaying states while touch, softsqueeze and radio do). Is this a known
> issue?

Hmm... I can't see how different player types would possibly result in
different responses?!? That said: the server version does. The "players"
command did only return little information in 7.8 and older. I'd
therefore suggest you go with the "serverstatus", which basically
returns the same information (in addition to some server related
pieces). But the difference between 7.9 and older versions is smaller
than with "players".

> If not, I can of course iterate through the players and issue the
> command to each in turn. However, this gets very messy inside the plugin
> using Slim::Networking::SimpleAsyncHTTP

You can run queries directly, no need to go through http requests. See
eg.

https://github.com/Logitech/slimserver/blob/public/7.9/Slim/Web/Pages/Playlist.pm#L144

--

Michael

Ah, brilliant Michael, many thanks for that. Exactly what I need! The nice thing about the http requests is that they are asynchronous. I presume Slim::Control::Request blocks (but is quick)?

Sometimes you can't see the forest for the trees!

I though the LMS version might be the issue as well but I have a user on 7.9 who's Boom and Classic are not returning Power or IsPlaying states. Quite odd as other player types on the same LMS version are doing so for other users.

I'm going to ask testers in the next release to check specifically for this on Booms and Classics to see if I can isolate it to this particular user.

Onwards and upwards!

[mherger]

Getting 'Status' for multiple playerssimultaneoulsy

> nice thing about the http requests is that they are asynchronous. I
> presume Slim::Control::Request blocks (but is quick)?

Those requests are what the json/rpc interface would be calling in the
background. They're at the very heart of LMS. Therefore you should be
safe using them. They shouldn't block.

> I though the LMS version might be the issue as well but I have a user on
> 7.9 who's Boom and Classic are not returning Power or IsPlaying states.

It's not only the version, but the revision, too. 7.9 has been in the
works for two or three years. A lot has changed during this time! In
general I'd suggest anyone running 7.9 should update to the recently
released 7.9.0.

--

Michael

[meep]

Michael

Thanks for your help on this. Your solutions were working for me until today when I started seeing the following;

I cycle through each client as follows;

   foreach my $client (Slim::Player::Client::clients()) {
               
                  my  $clID = $client->id;
                  my $request = Slim::Control::Request->new( $clID, [ 'mixer', 'volume', '?' ] );


                  $request->source('internal');
                  $request->execute();

And then retrieve the volume;

my $devVol = $request->{'_results'}->{'_volume'};

All good until I started seeing the following result object for one player. _volume is coming back as '[object Undefined]'. Any thoughts why? This player returned a volume up until now.

$VAR1 = bless( {
                 '_status' => 10,
                 '_func' => sub { "DUMMY" },
                 '_requeststr' => 'mixer,volume',
                 '_cb_enable' => 1,
                 '_langoverride' => undef,
                 '_params' => {},
                 '_clientid' => 'bb:f1:bc:b3:44:a8',
                 '_source' => 'internal',
                 '_useixhash' => 0,
                 '_isQuery' => 1,
                 '_results' => {
                                 '_volume' => '[object Undefined]'
                               },
                 '_needClient' => 1,
                 '_request' => [
                                 'mixer',
                                 'volume'
                               ]
               }, 'Slim::Control::Request' );

[meep]

Em, nothing to see here.

its entirely possible I caused this myself by passing in the undefined object as a parameter in a mixed volume command. A big more digging to fix another related error elsewhere and this stopped as well.

Will post back back if it returns.

peter

[mherger]

Getting 'Status' for multiple playerssimultaneoulsy

> my $devVol = $request->{'_results'}->{'_volume'};

You shouldn't access a request object's innards directly. But use
$request->getResult('volume') etc. instead. Otherwise you might
accidentally modify the object itself - which could result in the
effects you've experienced.

If you see variables or names prefixed by an underscore, it's likely
you're doing something wrong. The underscore often means it's internal,
not to be used directly. It's not a hard rule, but an unwritten convention.
--

Michael

[meep]

> my $devVol = $request->{'_results'}->{'_volume'};

You shouldn't access a request object's innards directly. But use
$request->getResult('volume') etc. instead. Otherwise you might
accidentally modify the object itself - which could result in the
effects you've experienced.

If you see variables or names prefixed by an underscore, it's likely
you're doing something wrong. The underscore often means it's internal,
not to be used directly. It's not a hard rule, but an unwritten convention.
--

Michael

Thanks

That bit is a few weeks old and I think I tried $request->getResult('volume') initially and had some problems.

I'll revert it in the next round to see if I can replicate. This is the problem with learning a language as you go! (and especially as I'm coding in both perl and js - the number of errors I've introduced by using '==' rather than 'eq' is mesmerising!!)

[meep]

Hi Michael

I revisited the code under discussion above and added two variants for accessing the return data;

foreach my $client (Slim::Player::Client::clients()) {

                  my  $clID = $client->id;


                  my $request = Slim::Control::Request->new( $clID, [ 'mixer', 'volume', '?' ] );
                  $request->source('internal');
                  $request->execute();


                  if ( $request->isStatusError() ) {
                    myDebug($request->getStatusText());
                  }else{
                    my $devVol = $request->{'_results'}->{'_volume'};
                    my $devVol2 = $request->getResult('volume');


                    myDebug ('volume is '.$devVol);
                    myDebug ('volume2 is '.$devVol2);
                  }
}

In this case, $devVol comes back as the correct volume, devVol2 comes back undefined.

I'm not sure what's going wrong here as it's the result of a direct Slim::Control::Request as discussed earlier in the thread?

Here is the entire $request object for reference:

$VAR1 = bless( {
                 '_request' => [
                                 'mixer',
                                 'volume'
                               ],
                 '_isQuery' => 1,
                 '_useixhash' => 0,
                 '_needClient' => 1,
                 '_status' => 10,
                 '_results' => {
                                 '_volume' => 30
                               },
                 '_func' => sub { "DUMMY" },
                 '_source' => 'internal',
                 '_langoverride' => undef,
                 '_cb_enable' => 1,
                 '_clientid' => '00:04:20:2a:f7:b0',
                 '_requeststr' => 'mixer,volume',
                 '_params' => {}
               }, 'Slim::Control::Request' );

It's a Squeezebox radio connected to LMS v 7.9.0 on OSX

[mherger]

Getting 'Status' for multiple playerssimultaneoulsy

> my $devVol2 = $request->getResult('volume');

What about getResult('_volume')?


--

Michael

[meep]

What about getResult('_volume')?

That works, and returns the same value as

my $devVol = $request->{'_results'}->{'_volume'};

I guess using getResult is better, even if requires accessing the name using an underscore despite your earlier comment?

>
If you see variables or names prefixed by an underscore, it's likely
you're doing something wrong. The underscore often means it's internal,
not to be used directly. It's not a hard rule, but an unwritten convention.
Michael