PDA

View Full Version : Send notification to specific Controller ?



erland
2010-03-04, 13:10
Is it possible to use Slim::Control::Request::notifyFromArray to send an event to a specific Controller ?

Let's say I have two controllers which both have the same player selected, can I somehow only send the event to only one of them ?
Or is a notification with notifyFromArray always tied to a player (not a controller) ?

Triode
2010-03-04, 14:46
Are you considering creating your own status processing on the server side? If so you could potentially create a filter for them which allows you to target notifications to specific controller.

However the simple answer is any notifications will go to all controllers.

pippin
2010-03-04, 14:49
Why do you want to do this?
Can't the controller decide on it's own whether it's meant?

erland
2010-03-04, 16:17
Are you considering creating your own status processing on the server side? If so you could potentially create a filter for them which allows you to target notifications to specific controller.

However the simple answer is any notifications will go to all controllers.
Is Controller's represented on the SBS side as a Slim::Player::Client object if you haven't enabled playback on them ?

Is the trick and send "undef" in the first parameter to Slim::Control::Request::notifyFromArray ?

You can probably guess what I like to do based on the other threads recently in this forum section, but here is the idea:
1. A SBS plugin will send a notification to request a certain file (for example "/var/log/messages"
2. A SP applet will pickup the request and send the the base64 encoded file back by making a JSON command call (which is implemented by the plugin) with the file data as parameter.

I've got it working, by calling Slim::Control::Request::notifyFromArray with a client object on the SBS side and doing a "player:subscribe" on the SP side. The problem is that this is based on players, not controllers. And if two Controller's are available and both have chosen the same player, I want to trigger one to respond with the callback but not the other.

It's not a problem that both get the events (in 1) but I need to have some way to ensure that only one of them answers with the callback (in 2). At the moment it seems like the event are sent to the controller that represent the player which I've specified in the $client parameter to notifyFromArray. I'm just looking in the "network.cometd" logs and in the logs on the SP play side, it it might be that the notification is really sent to all, but from the logs that doesn't seem to happen.

I have a feeling, I've just missed something very simple.

peterw
2010-03-04, 18:04
I have a feeling, I've just missed something very simple.

I hope you're right, but I expect you're wrong, that this simply is something the architecture was not designed to accomodate. Each Controller will have a unique MAC address, I'd just have your applet report that (might read it from something in /proc) to the plugin, and have your plugin send that MAC as part of your notification.

I do hope you're right.

pippin
2010-03-04, 18:17
The player ID is for the player part of a controller. If you use your controller with a different player they are disconnected.
Player IDs in the cometd protocol always refer to the player part.

I agree with Peter, you will have to have logic in the controller to understand that _this_ controller is to answer to the notification, the server doesn't know the controller identity.

That said: If the controller uses cometd (like iPeng and Squeezeplay), there's also a (connection specific) clientId in that protocol. It's not a device ID and not persistent (so it will change whenever the communication breaks down and is re-established) and also a client could theoretically have several of them if it opens more than one connection (iPeng doesn't but I don't know about SqueezePlay) but if you could get hold of that one, it may be a start.

I don't know where this could be known to the server, though, chances are it's only within the communication stack.

erland
2010-03-04, 18:20
I hope you're right, but I expect you're wrong, that this simply is something the architecture was not designed to accomodate. Each Controller will have a unique MAC address, I'd just have your applet report that (might read it from something in /proc) to the plugin, and have your plugin send that MAC as part of your notification.

That works, I got the same idea an hour ago so I tried this.

There is a "System:getMacAddress()" call which can be used to get the local Mac address and a "System:getMachine()" to get the model.

In one way, this actually turned out to be pretty good in my case, because it will work as follows:
1. The applet register itself with the server when it connects to it
2. In the SBS user interface I can display a list of the devices and that list will only contain the devices where the applet has actually been installed.

I kind of like the idea that only the devices where the applet is installed is shown in the list, because it means that you can only select the devices that will actually work.

Still, I'm interested if there is any way to get the MAC address of available controllers on the server side, because this would be useful in some scenarios.

The "Slim::Control::Request::notifyFromArray" call on the SBS side seems to send the notification to all players if I set the first parameter to undef. I had specified the selected $client in that call and then it's only sent to a single player (or actually all controllers controlling that specific player).

peterw
2010-03-05, 06:45
There is a "System:getMacAddress()" call which can be used to get the local Mac address and a "System:getMachine()" to get the model.
...
In the SBS user interface I can display a list of the devices and that list will only contain the devices where the applet has actually been installed.

I kind of like the idea that only the devices where the applet is installed is shown in the list

I think this would be a great enhancement for SqueezePlay in general -- have each SP device report its ID, model, and the name and version of every installed applet. Have SBS keep track of this info -- perhaps as normal clients (add a new method to indicate if the SP device is a player?), perhaps as a new array of squeezeplay objects. One of the attributes of a squeezeplay SBS object should be the $client->id() that it's currently controlling.

Triode
2010-03-05, 11:59
> The "Slim::Control::Request::notifyFromArray" call on the SBS side
> seems to send the notification to all players if I set the first
> parameter to undef. I had specified the selected $client in that call
> and then it's only sent to a single player (or actually all controllers
> controlling that specific player).

This depends on how you have subscribed for notifications on the server, but
yes the architecture is designed around sending information about clients
(players) to any interested party who registers interest in that client,
rather than directed to a specific receiver.

If you have your own server side query code and register using
$request->registerAutoExecute, then you could build in a filter for the
target in the query filter. The standard subscription to notifications
using subscribe will filter on client and request verbs, but you can't
target a specific cometd session.