DvProviderUpnpOrgRenderingControl
|
16-10-2013, 07:01 PM
Post: #1
|
|||
|
|||
DvProviderUpnpOrgRenderingControl
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> In the OpenHome DvProviderUpnpOrgRenderingControl the definition looks like: Code: <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 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. |
|||
17-10-2013, 12:33 PM
Post: #2
|
|||
|
|||
RE: DvProviderUpnpOrgRenderingControl
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. |
|||
17-10-2013, 01:50 PM
Post: #3
|
|||
|
|||
RE: DvProviderUpnpOrgRenderingControl
(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. 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. |
|||
18-10-2013, 02:36 PM
Post: #4
|
|||
|
|||
RE: DvProviderUpnpOrgRenderingControl
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.
|
|||
24-10-2013, 10:30 AM
Post: #5
|
|||
|
|||
RE: DvProviderUpnpOrgRenderingControl
(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. |
|||
24-10-2013, 10:56 AM
Post: #6
|
|||
|
|||
RE: DvProviderUpnpOrgRenderingControl
(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. 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. |
|||
24-10-2013, 03:27 PM
Post: #7
|
|||
|
|||
RE: DvProviderUpnpOrgRenderingControl
(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 getting nervous now ![]() 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: ------------------------------------------------- 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. |
|||
« Next Oldest | Next Newest »
|