DvProviderUpnpOrgRenderingControl

[PeteManchester]

Hi,

I am trying to make my MediaPlayer compatible with more control points so I have added ConnectionManager, AVTransport and RenderingControl, but I have noticed that some control points seem to have problems with the RenderingControl.

I have looked at the Service XML for the DvProviderUpnpOrgRenderingControl1 and it seems as though there are some differences between that other Renderers.



Which in the Service XML of another renderer looks like

Code:

<action>
<name>GetVolume</name>
<argumentList>
<argument>
<name>InstanceID</name>
<direction>in</direction>
<relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable>
</argument>
<argument>
<name>Channel</name>
<direction>in</direction>
<relatedStateVariable>A_ARG_TYPE_Channel</relatedStateVariable>
</argument>
<argument>
<name>CurrentVolume</name>
<direction>out</direction>
<relatedStateVariable>Volume</relatedStateVariable>
</argument>
</argumentList>
</action>

In the OpenHome DvProviderUpnpOrgRenderingControl the definition looks like:

Code:

<action>
<name>GetVolume</name>
<argumentList>
<argument>
<name>InstanceID</name>
<direction>in</direction>
<relatedStateVariable>A_ARG_TYPE_GetVolume_InstanceID</relatedStateVariable>
</argument>
<argument>
<name>Channel</name>
<direction>in</direction>
<relatedStateVariable>A_ARG_TYPE_GetVolume_Channel</relatedStateVariable>
</argument>
<argument>
<name>CurrentVolume</name>
<direction>out</direction>
<relatedStateVariable>A_ARG_TYPE_GetVolume_CurrentVolume</relatedStateVariable>
</argument>
</argumentList>
</action>
<action>

Which uses the 'A_ARG_TYPE_GetVolume_Channel' instead of A_ARG_TYPE_Channel.

I have looked at the UPNP spec and it seems to suggest that the RedndererControl should use the A_ARG_TYPE_Channel method.

Code:

2.2.19. A_ARG_TYPE_Channel
This variable is used to identify a particular channel of an audio output stream. A channel, except the Master channel, is associated with the location of the speaker where the audio data stream is to be presented. It is customary to refer a channel using the spatial position of associated speaker as described below.
The Master channel is a logical channel and, therefore, has no spatial position associated with it. A one-channel channel cluster does not have spatial position associated with it either and will use the Master channel to control its properties.
The following channel spatial positions are defined:
• Master (Master)
• Left Front (LF)
• Right Front (RF)
• Center Front (CF)
• Low Frequency Enhancement (LFE) [Super woofer]
• Left Surround (LS)
• Right Surround (RS)
• Left of Center (LFC) [in front]
• Right of Center (RFC) [in front]
• Surround (SD) [rear]
• Side Left (SL) [left wall]
• Side Right (SR) [right wall]
• Top (T) [overhead]
• Bottom (B) [bottom]

Could this make a difference to some control points or should I be looking at other things.

The main issues are that some Control Points will not even recognise the Renderer (gives error about RenderingControl A_ARG_TYPE_Channel being null) and on some the volume control is not updated with any changes.

Other Control Points the use the RenderingControl seem to work, so I think i have the format of the LastEvent correct.

Thanks,

Pete.

[simonc]

The service xml returned by ohNet is consistent (you should see A_ARG_TYPE_GetVolume_CurrentVolume as a a non-evented state variable in the xml) but it probably is a bug that the names of non-evented related state variables don't match those suggested by the UPnP Forum.

Unfortunately, this isn't trivial to change. I think it might be possible given a couple of days focused work but I'm not sure on all the details yet so may well have missed something. To help decide on a priority for this work, do you know which control point(s) are likely (hoped) to start working given a fix? Any info about the popularity of the CP would be very interesting too.

[PeteManchester]

(17-10-2013 12:33 PM)simonc Wrote:  The service xml returned by ohNet is consistent (you should see A_ARG_TYPE_GetVolume_CurrentVolume as a a non-evented state variable in the xml) but it probably is a bug that the names of non-evented related state variables don't match those suggested by the UPnP Forum.

Unfortunately, this isn't trivial to change. I think it might be possible given a couple of days focused work but I'm not sure on all the details yet so may well have missed something. To help decide on a priority for this work, do you know which control point(s) are likely (hoped) to start working given a fix? Any info about the popularity of the CP would be very interesting too.

Hi Simon,

No problem, it isn't a big issue for me, I was just curious why some Control Points wouldn't work.

I don't have any big plans for my renderer, it's more of a hobby to keep me occupied when I'm working away from home, hopefully when your new mediaplayer comes along http://www.openhome.org/wiki/OhMediaPlayer I can use that instead.

The Control Points that I have noticed a minor issue of the volume control not synching to the actual volume of the renderer and I would hope would work are :
Asset Control
Foobar UPNP Controller

The CP I used to diagnose the issue was Intels UPNP Dev Tool CP, but that is not really a consideration.

Also on iOS MediaConnect will not even recognise the renderer, but I couldn't say it was definitely because of this issue.

The CP's that uses the Renderer Control and seems ok is PlugPlayer.

The CP I normally use and has no issues because it doesn't use the RendereControl is Kinsky..

Thanks,

Pete.

[simonc]

Thanks Pete. These aren't control points we'd want to break so I'll try to schedule time towards the end of the month to look at this.

[PeteManchester]

(18-10-2013 02:36 PM)simonc Wrote:  Thanks Pete. These aren't control points we'd want to break so I'll try to schedule time towards the end of the month to look at this.

Hi Simon,

I just tested again and found that Asset Control does work with the Providers as they currently are.

I'm not sure if that makes any difference for your plans...

Also I noticed that the ConnectionManager and AVTransport have their state variables declared in a similar style to the Rendering control.

Thanks again,

Pete.

[simonc]

(24-10-2013 10:30 AM)PeteManchester Wrote:  I just tested again and found that Asset Control does work with the Providers as they currently are.

I'm not sure if that makes any difference for your plans...

Thanks Pete, that's good to know. I don't think it'll change our desire to fix things for Foobar but it's reassuring that we haven't broken quite as many control points at least

(24-10-2013 10:30 AM)PeteManchester Wrote:  Also I noticed that the ConnectionManager and AVTransport have their state variables declared in a similar style to the Rendering control.

All ohNet providers do this. We generate service xml on demand. This seemed like a good thing as it allowed us to tailor the xml to describe only the actions/properties that a particular implementation had chosen to register. The downside with this is that we generate xml that doesn't look quite like what was published by the service's owner.

Action arguments which have non-evented related state variables only have their type and name stored in the auto-generated base classes. This means that we have to invent state variables if asked to create service xml. We chose a simple but verbose process for this - every such argument has its own dummy state variable created with names which include both action and argument name to encourage uniqueness.

A fix for this bug will have to involve storing the names of non-evented related state variables with action arguments. Some further work will be required in runtime service xml creation to avoid duplicating state variable entries.

[PeteManchester]

(24-10-2013 10:56 AM)simonc Wrote:  

(24-10-2013 10:30 AM)PeteManchester Wrote:  I just tested again and found that Asset Control does work with the Providers as they currently are.

I'm not sure if that makes any difference for your plans...

Thanks Pete, that's good to know. I don't think it'll change our desire to fix things for Foobar but it's reassuring that we haven't broken quite as many control points at least

(24-10-2013 10:30 AM)PeteManchester Wrote:  Also I noticed that the ConnectionManager and AVTransport have their state variables declared in a similar style to the Rendering control.

All ohNet providers do this. We generate service xml on demand. This seemed like a good thing as it allowed us to tailor the xml to describe only the actions/properties that a particular implementation had chosen to register. The downside with this is that we generate xml that doesn't look quite like what was published by the service's owner.

Action arguments which have non-evented related state variables only have their type and name stored in the auto-generated base classes. This means that we have to invent state variables if asked to create service xml. We chose a simple but verbose process for this - every such argument has its own dummy state variable created with names which include both action and argument name to encourage uniqueness.

A fix for this bug will have to involve storing the names of non-evented related state variables with action arguments. Some further work will be required in runtime service xml creation to avoid duplicating state variable entries.

I'm getting nervous now , when I review everything I don't really have any concrete evidence that if you do all that work that FooBar will work.

Also as good as FooBar is I'm not sure if the issue is worth fixing, it is only a minor problem with FooBar and it is also unlikely that anybody would use FooBar in this scenario:

In the Foobar UPnP Controller you can select the source of the media renderer, in the case of my renderer that is 'PlayList', 'Radio', 'Receiver' (all standard OpenHome providers) or you can chose the source provided by the AVTransport provider.
If you select the AVTransport source then you can make changes to the volume, but any changes to volume made by another CP are not updated in FooBar (uses DvProviderUpnpOrgRenderingControl1)
If you chose the PlayList source then this uses the OpenHome Volume provider (DvProviderAvOpenhomeOrgVolume1) and so this works fine.

In my opinion it is very unlikely that someone would be using the AVTransport source, when the PlayList source is available and also with my Media Renderer (there are only 3 other people using it besides me)

The only evidence I have of a CP that is impacted by the state variable declaration, is the CP in the Intel UPNP Developers Toolkit, which is not likely to be used by anyone as a serious Control Point..

Code:

-------------------------------------------------
Origin: mscorlib
Time: 24/10/2013 15:59:44

System.Reflection.TargetInvocationException : System.NullReferenceException

Additional Info:
Exception has been thrown by the target of an invocation.

InnerException #0:
Message: Object reference not set to an instance of an object.
Source: UPNP_AV
StackTrace:    at OpenSource.UPnP.AV.CpRenderingControl.get_Values_A_ARG_TYPE_Channel() in c:\Users\Public\Downloads\DeveloperToolsForUPnP\Global\UPNP_AV\CpRenderingContro​l.cs:line 408
   at OpenSource.UPnP.AV.RENDERER.CP.RenderingControlLastChange..ctor(CpRenderingContr​ol cpRC, String Ident, Int32 ID, OnReadyHandler ReadyCallback) in c:\Users\Public\Downloads\DeveloperToolsForUPnP\Global\UPNPAV_RendererStack\Rend​eringControlLastChange.cs:line 97
   at OpenSource.UPnP.AV.RENDERER.CP.AVConnection..ctor(UPnPDevice device, Int32 AVTransportID, Int32 RenderingControlID, Int32 ConnectionID, OnReadyHandler ReadyCallback, Object StateObject) in c:\Users\Public\Downloads\DeveloperToolsForUPnP\Global\UPNPAV_RendererStack\AVCo​nnection.cs:line 534
   at OpenSource.UPnP.AV.RENDERER.CP.AVRenderer..ctor(UPnPDevice device) in c:\Users\Public\Downloads\DeveloperToolsForUPnP\Global\UPNPAV_RendererStack\AVRe​nderer.cs:line 271
   at OpenSource.UPnP.AV.RENDERER.CP.AVTargetDiscovery.AddSink(UPnPSmartControlPoint sender, UPnPDevice device) in c:\Users\Public\Downloads\DeveloperToolsForUPnP\Global\UPNPAV_RendererStack\AVTa​rgetDiscovery.cs:line 154
   at OpenSource.UPnP.UPnPSmartControlPoint.HandleAddedDevice(UPnPInternalSmartControl​Point sender, UPnPDevice device) in c:\Users\Public\Downloads\DeveloperToolsForUPnP\Global\UPnP\UPnPSmartControlPoin​t.cs:line 380

TRACE:
   at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
   at OpenSource.Utilities.WeakEvent.Fire(Object[] args) in c:\Users\Public\Downloads\DeveloperToolsForUPnP\Global\UPnP\WeakEvent.cs:line 140

-------------------------------------------------

The other control points I have succesfully tested that use the AVTransport and Renderer providers are :
Asset Control
PlugPlayer
eLyric
AudioNet

So it seems that the state variable declaration doesn't break a number of very good CPs...

Thanks again,

Pete.