Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
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 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 Smile

(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 Blush, 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..

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

   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

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

Thanks again,

Find all posts by this user

Messages In This Thread
RE: DvProviderUpnpOrgRenderingControl - PeteManchester - 24-10-2013 03:27 PM

Forum Jump: