A/V control: standardizing AVTransport and RenderingControl services

Plugins & Plugin Development General Plugin Discussion
1

I open this topic to quickly converge to a common standard for AVTransport and RenderingControl services.
This is required because we have now several plugins implementing these A/V services, while the Vera is not conceived to manage several services having the same type.
So the idea is to define and maintain a common service file that will include all what is needed by the different plugins.

Here are the current plugins identified as using these services:

  • Sonos
  • Squeezebox
  • DLNA
  • Russound

Being the author of the DLNA plugin and now the last remaining contributor for the Sonos plugin, I can tell you that this work is already done for Sonos and DLNA.

So we just have to enhance the two files to be fully compliant with Squeezebox and Russound plugins, and then change these plugins to use these services.

2

I propose to name the reference files S_AVTransport1.xml and S_RenderingControl1.xml.

3

Squeezebox plugin only uses a RenderingControl service, not AVTransport service.
And only SetVolume is apparently implemented from this service.
So that means Squeezebox plugin is already compatible with the RenderingControl service defined for Sonos and DLNA plugins.

4

The files found on code.mios.com for Squeezebox are not current nor implement what I have modified to the plugin. You can find the current files for the Squeezebox here:

http://forum.micasaverde.com/index.php/topic,9451.msg132625.html#msg132625

I do not own or maintain the code.mios.com code.

For Russound:

http://forum.micasaverde.com/index.php/topic,15832.0.html

  • Garrett
5

For the Russound plugin, only RenderingControl service is implemented and one time again only SetVolume is implemented.
So that’s not a problem to use the Sonos version of the service.

6

[quote=“garrettwp, post:4, topic:178168”]The files found on code.mios.com for Squeezebox are not current nor implement what I have modified to the plugin. You can find the current files for the Squeezebox here:

http://forum.micasaverde.com/index.php/topic,9451.msg132625.html#msg132625[/quote]

The AVTransport service file is the one from the Sonos plugin, isn’t it ?
Did you update it (add something) ?

You should have implemented few actions of the AVTransport service because the final user will see them in the scene editor and could select them: play, puase, stop for example.

7

I took the files from the Sonos Plugin some time ago. I’ll see about adding the additional AVTransport functions. I only added what was needed to have it similar to the Sonos Plugin for 3rd party app support.

  • Garrett
8

As the Vera architecture is not designed to have several different files for the same service type, I propose the two following files as reference for these services:

[ul][li]urn:schemas-upnp-org:service:AVTransport:1[/li]
[li]urn:schemas-upnp-org:service:RenderingControl:1[/li][/ul]

Each plugin using one of these service types should include the reference file.
Doing that, we can have several plugins working well on the same Vera unit.

Of course, if one plugin requires a complement for one of these 2 services, we will update the reference file (and update all plugins).

9

I am looking to join the standardization club for the Onkyo Receiver Plugin. I am currently fine with the S_RenderingControl1.xml. I need added to S_AVTransport1.xml are a couple of allowedValues specific to Onkyo Receivers. Below is the modified stateVariable with my added allowedValues.

<stateVariable sendEvents="no"> <name>CurrentPlayMode</name> <dataType>string</dataType> <defaultValue>NORMAL</defaultValue> <allowedValueList> <allowedValue>NORMAL</allowedValue> <allowedValue>SHUFFLE</allowedValue> <allowedValue>REPEAT_ONE</allowedValue> <allowedValue>REPEAT_ALL</allowedValue> <allowedValue>RANDOM</allowedValue> <allowedValue>DIRECT_1</allowedValue> <allowedValue>INTRO</allowedValue> <!-- Sonos and XBMC --> <allowedValue>SHUFFLE_NOREPEAT</allowedValue> <!-- Onkyo --> <allowedValue>REPEAT_FOLDER</allowedValue> <allowedValue>SHUFFLE_ALBUM</allowedValue> <allowedValue>SHUFFLE_FOLDER</allowedValue> </allowedValueList> </stateVariable>

I would suggest adding these files to code.mios.com as a project for standard upnp files so versioning isn’t an issue.

10

@jullio: welcome to the club 8) I am happy to see someone else interested by this subject.

Your change will be included in my next releases of Sonos and DLNA plugins.
By the way, the current versions of these plugins will continue to work even with your changes.

I agree with you about the need of a special project in code.mios.com. I will ask for it … as soon as I have time. If you have an account in code.mios.com, please give it to me (MP) so that I can ask an access to this new project for you too.

11

I have been playing around with standard S_AVtransport file and also Rendering Control files I downloaded from lolodomo. I am seeing a lot of custom actions and serviceStateVariables that aren’t in the actual AV transport upnp documentation from upnp.org. The only thing I see customization within that standard are the state variable standard values which allows vendor specific options. Such as the values that I need for onkyo shuffle_folder within the state variable of transportstatus in the AVTransport service file.

I think that we need to keep the AVTransport service file and Rendering control service file as close to the standard outline as possible with no custom actions or state variables. I see this as a problem with plugins not implementing custom actions in this file. If there are custom actions necessary I put those actions in my plugin specific service file.

I don’t know how everyone else feels about it but I think this will make it possible for the standardization and less problems with actions that aren’t implemented. If someone could tell me how non implemented actions isn’t a problem let me know. I am open to discussion.

Jullio

12

[quote=“jullio, post:11, topic:178168”]I have been playing around with standard S_AVtransport file and also Rendering Control files I downloaded from lolodomo. I am seeing a lot of custom actions and serviceStateVariables that aren’t in the actual AV transport upnp documentation from upnp.org. The only thing I see customization within that standard are the state variable standard values which allows vendor specific options. Such as the values that I need for onkyo shuffle_folder within the state variable of transportstatus in the AVTransport service file.

I think that we need to keep the AVTransport service file and Rendering control service file as close to the standard outline as possible with no custom actions or state variables. I see this as a problem with plugins not implementing custom actions in this file. If there are custom actions necessary I put those actions in my plugin specific service file.

I don’t know how everyone else feels about it but I think this will make it possible for the standardization and less problems with actions that aren’t implemented. If someone could tell me how non implemented actions isn’t a problem let me know. I am open to discussion.

Jullio[/quote]

Attached are the Services files directly from upnp.org that I suggest we use. We can modify the allowedValues and other vendor specific values.

13

[quote=“jullio, post:12, topic:178168”][quote=“jullio, post:11, topic:178168”]I have been playing around with standard S_AVtransport file and also Rendering Control files I downloaded from lolodomo. I am seeing a lot of custom actions and serviceStateVariables that aren’t in the actual AV transport upnp documentation from upnp.org. The only thing I see customization within that standard are the state variable standard values which allows vendor specific options. Such as the values that I need for onkyo shuffle_folder within the state variable of transportstatus in the AVTransport service file.

I think that we need to keep the AVTransport service file and Rendering control service file as close to the standard outline as possible with no custom actions or state variables. I see this as a problem with plugins not implementing custom actions in this file. If there are custom actions necessary I put those actions in my plugin specific service file.

I don’t know how everyone else feels about it but I think this will make it possible for the standardization and less problems with actions that aren’t implemented. If someone could tell me how non implemented actions isn’t a problem let me know. I am open to discussion.

Jullio[/quote]

Attached are the Services files directly from upnp.org that I suggest we use. We can modify the allowedValues and other vendor specific values.[/quote]

Attached are my updated files with the allowedValues updated to reflect sonos and other values.

14

You missed the main reason of the initial request.

Due to the bad way Micasaverde manages UPnP services, we cannot have in the Vera several files for the same service type. It was noticed by several users that if you are in this case, the MCV engine will only consider one of the different files and use it for all devices that implement this service type. That leads of course to devices not working properly.

Of course, the normal and proper way to do it would have been to create one file for each device, like a file for Sonos, one another for Onkyo and so one. Unfortunately, it will not work in the Vera if you have one Sonos device and one Onkyo device.

Here is why we conclude that the best (to not say the only) solution would be to have one unique file shared by all plugins for each particular service type. The idea is to start from the standard service provided by UPnP (note that it would normally have been the file I will use in the DLNA plugin) and then add to it vendor specific stuff like additional actions. In the current file I use, as you noticed, there are already a lot of additional actions that are mainly Sonos specific stuff. What I tried to do is to add a comment in the file when something is vendor specific (and not the UPnP standard).

Regarding your other idea to cut in two parts a service to have the standard in one side and the specific in another side, it will not work in Vera for the reason I explained, and by the way, that is not really compliant with the UPnP standard.

So, we have to try maintaining one unique file compliant with every device we want to control in the Vera. It is not the proper way to do but the only way we have for the Vera due to a bad MCV handling of services.

15

I understand that point of view. I think that will work for me.

My plugin will work with those files of yours.

16

[quote=“jullio, post:9, topic:178168”]I am looking to join the standardization club for the Onkyo Receiver Plugin. I am currently fine with the S_RenderingControl1.xml. I need added to S_AVTransport1.xml are a couple of allowedValues specific to Onkyo Receivers. Below is the modified stateVariable with my added allowedValues.

<stateVariable sendEvents="no"> <name>CurrentPlayMode</name> <dataType>string</dataType> <defaultValue>NORMAL</defaultValue> <allowedValueList> <allowedValue>NORMAL</allowedValue> <allowedValue>SHUFFLE</allowedValue> <allowedValue>REPEAT_ONE</allowedValue> <allowedValue>REPEAT_ALL</allowedValue> <allowedValue>RANDOM</allowedValue> <allowedValue>DIRECT_1</allowedValue> <allowedValue>INTRO</allowedValue> <!-- Sonos and XBMC --> <allowedValue>SHUFFLE_NOREPEAT</allowedValue> <!-- Onkyo --> <allowedValue>REPEAT_FOLDER</allowedValue> <allowedValue>SHUFFLE_ALBUM</allowedValue> <allowedValue>SHUFFLE_FOLDER</allowedValue> </allowedValueList> </stateVariable>[/quote]

Finally, is it the only change you need for your Onkyo plugin ?
No need for additional actions ?

17

[quote=“lolodomo”][quote=“jullio, post:9, topic:178168”]I am looking to join the standardization club for the Onkyo Receiver Plugin. I am currently fine with the S_RenderingControl1.xml. I need added to S_AVTransport1.xml are a couple of allowedValues specific to Onkyo Receivers. Below is the modified stateVariable with my added allowedValues.

[code]
CurrentPlayMode
string
NORMAL

NORMAL
SHUFFLE
REPEAT_ONE
REPEAT_ALL
RANDOM
DIRECT_1
INTRO

SHUFFLE_NOREPEAT

REPEAT_FOLDER
SHUFFLE_ALBUM
SHUFFLE_FOLDER

[/code][/quote]

Finally, is it the only change you need for your Onkyo plugin ?
No need for additional actions ?[/quote]

That is all I need right now. Are you going to package it as a separate app on apps.mios.com? I don’t have a sonos system and many others won’t either.

18

Project is now created in code.mios.com. It is named “Common UPnP AV Plugin Files”.
Here is the direct link to the files: / – Common UPnP AV Plugin Files

@jullio: you have write access. So I let you apply your changes.

The general principle for the future is to discuss any change. Normally these services files should not evolve very often.

When these services are included in the Vera (attached to a device), all actions are then automatically exposed in the Vera scene editor. As the Vera design does not allow in getting return values from actions, I decided to keep all actions in the services but to comment all actions that could not be really used by a final user (including of course all “GET” actions).

What we can change without any risk is:

[ul][li]Add vendor specific values for list of values[/li]
[li]Add vendor specific actions[/li][/ul]

Suppressing anything is of course forbidden.

19

No.

The files are now available in a public place for every developer that is concerned by A/V control using services types urn:schemas-upnp-org:service:AVTransport:1 and urn:schemas-upnp-org:service:RenderingControl:1.
Any developer should use these files and publish his plugin including the common files required by his plugin.
Of course, a developer could have the need to enhance these common files because the device he wants to control has some vendor specific stuff not yet present in the common files. In this case, we will have to enhance the common files.

To be clear, the file S_AVtransport1.xml will be included in the Sonos plugin, the DLNA Media controller plugin and your Onkyo plugin.

20

My understanding is that you can not have more than service type defined in the app store. It will not let you create it if already exists. We should keep all files in sync between plug-ins.

  • Garrett