Missing services in BUTE

[Integrator]

I'm writing an application from scratch and was interested to see the difference between Bute & Auskerry. So I did the firmware upgrade on my Akurate to Bute. When you 'discover' a Bute device only a basic device & services are shown in the root device description, whereas when you 'discover' an Auskerry device, all are shown.
I did a bit of digging on the OSS site and found an article which relates to the Auskerry & Bute Islands - this explains the extra services that are used to get access to the Preamp etc... but they aren't shown in the root XML document.

Surely as a uPNP product these services should be available within the root device description as a 'manufacturers extension'??? since the whole idea is to not have to retain any information.
Am I wrong ??? if not is this going to be fixed in the next upgrade?


............rolled back to Auskerry...............

[grahamd Linn Staff]

Integrator,

Everything is there in Bute as well as Auskerry. Please post the XML that leads you to think otherwise. I should then be able to work out the source of your problem.

It probably has something to do with Auskerry using a single root device with multiple embedded devices, and Bute using multiple root devices.

Graham

[Integrator]

grahamd Wrote:Integrator,

Everything is there in Bute as well as Auskerry. Please post the XML that leads you to think otherwise. I should then be able to work out the source of your problem.

It probably has something to do with Auskerry using a single root device with multiple embedded devices, and Bute using multiple root devices.

Graham

Hi Graham

Thanks for the response. The 'LOCATION' path given from the discovery message with bute is <IP_ADDRESS>: Port/MediaRenderer, where as in Auskerry it is <IP_ADDRESS>: Port/. However, in the XML document for this address the URL base address has been added. When using the path name in LOCATION, I simply get a single device & three services (as far as I can remember, I'd have to convert my Akurate back to bute to confirm this).
So, Should I really be using the URL base address in the document to get the full list???
I am going to try and make my app Auskerry/Bute compatible if possible. Currently on Auskerry base I have my discovery complete, eventing subscription completed and am just creating the SOAP structures. So If I need to make adjustments to cope with both, I would rather do it now.

Also, can I determine between bute & auskerry by simply testing against the Port number?

Many Thanks

[Integrator]

grahamd Wrote:Integrator,

Everything is there in Bute as well as Auskerry. Please post the XML that leads you to think otherwise. I should then be able to work out the source of your problem.

It probably has something to do with Auskerry using a single root device with multiple embedded devices, and Bute using multiple root devices.

Graham

Hi Graham

I have attached a notepad doc with the root doc that I get from the discovery location.....I take it that I have missed something?

Thanks
[attachment=159]

[grahamd Linn Staff]

Hi Integrator,

In Upnp, each device has a description which, amongst other things, enumerates the services it supports.

Furthermore, each device can contain other devices ('embedded devices') each with their own description.

It is possible to discover devices by device type. I assume this is what you are doing. I guess you are discovering urn:schemas-upnp-org:device:MediaRenderer:1. But when you discover such a device it is possible that that device is not a root device, but an embedded device.

Now, note that the device XML file in the LOCATION header is always the root device XML. So, you have to hunt for the device you are looking for by traversing the tree of parent-child device relationships until you get to the device you are interrested in.

But it is poor practice to start looking at all the other embedded devices and services that pass before your gaze while you are doing this.

It seems to me that you are searching for a (Upnp Media Renderer) device and then making assumptions about the context in which you find it.

If you discover Upnp MediaRenderer devices you should only use the Upnp MediaRenderer services that you find there.

If you want to use Linn extension services, you should use the appropriate discovery techinque to access them.

I would advise against trying to develop an application that is compatible with both Auskerry and Bute. It is certainly possible, but probably not really worth the programming overhead.

There is some discussion of the different discovery strategies here:

http://oss.linn.co.uk/trac/wiki/CompatibilityFamily

But please don't hesitate to ask further questions about this.

Thanks
Graham

[grahamd Linn Staff]

Hi Integrator,

Just to add, in case this wasn't clear, in BUTE the different UPnP devices are separate ROOT devices, so when you get their device XML you only get the device XML relevant to that device (as shown by your Notepad file). This is in fact preferable and makes for better interoperability with a range of client software.

If you want to use the Linn extension services you will need to discover the appropriate Linn extension devices to get at them, which is the correct approach all in all.

Thanks
Graham

[Integrator]

grahamd Wrote:Hi Integrator,

Just to add, in case this wasn't clear, in BUTE the different UPnP devices are separate ROOT devices, so when you get their device XML you only get the device XML relevant to that device (as shown by your Notepad file). This is in fact preferable and makes for better interoperability with a range of client software.

If you want to use the Linn extension services you will need to discover the appropriate Linn extension devices to get at them, which is the correct approach all in all.

Thanks
Graham

Hi Graham

Ta for the info.

So just to get this straight, is what you are basically saying is that the to get to the actual root document, the search target needs to be upnp:rootdevice rather than MediaRenderer:1. I am assuming that this is the way otherwise there would be no way to recover the initial tree.

Thanks

[Integrator]

grahamd Wrote:Hi Integrator,

Just to add, in case this wasn't clear, in BUTE the different UPnP devices are separate ROOT devices, so when you get their device XML you only get the device XML relevant to that device (as shown by your Notepad file). This is in fact preferable and makes for better interoperability with a range of client software.

If you want to use the Linn extension services you will need to discover the appropriate Linn extension devices to get at them, which is the correct approach all in all.

Thanks
Graham

Hi Graham

I'm clearly not getting the gist here. With Auskerry, I have discovered device:MediaRender:1 types and then used the root tree to harvest all the info for the roor dev & services and also the embedded devs and services. using this method I get a result.
With bute, doing this simply give me the notepad doc that I sent to you.
So are you saying that if I wanted the info for say the AkurateDs:1 device, is there no root document that tells you that that device exists in the first place as with the root script in Auskerry?
Otherwise that would mean that you are storing data rgarding services & devices specific to a manufacturers device wouldn't it?

Thanks

[grahamd Linn Staff]

Hi Integrator,

I'm obviously not explaining very well. I'll give it another go.

The UPnP world is made up of devices and services.

Devices own services. In other words you cannot have a free standing service that is not owned by a device.

Furthermore, devices can own further devices. And they can own further devices in a potentially infinite tree of ownership. In this case the head of the tree is called a root device and all the children and their children and their children's children etc are called embedded devices.

Devices have a device type.

Services have a service type.

There are three primary ways to perform Upnp discovery:

Give me all the devices that conform to a specified device type
Give me all the devices that contain a service of the specified service type
Give me all the root devices

In all instances, whether the device or devices that are discovered are root or embedded devices, the device xml reported in the LOCATION header of the SSDP message is the device xml for the root device in which owns the device that satisfies the discovery criteria.

UPnP AV specifies some device profiles. One of them is the UPnP Media Renderer. It specifies a device type (urn:schemas-upnp-org:device:MediaRenderer:1) and 3 services (urn:schemas-upnp-org:service:AVTransport:1, urn:schemas-upnp-org:service:RenderingControl:1, urn:schemas-upnp-org:service:ConnectionManager:1). A conformant device of type MediaRenderer must contain all three of these services.

So, if you want to write a program that works with Upnp Media Renderers, your best strategy is to discover devices of type MediaRenderer and then access the three services that are mandated to be there once you discover those devices.

Note that there are many manufacturers of Upnp Media Renderer devices. You program will work with all of them.

Linn DS products contain several devices. In Auskerry there is a complex collection of embedded devices and services collected under the umbrella of a single root device.

One of those devices is the Upnp Media Renderer device, which contains the three services mentioned above. The Upnp Media Renderer device and the implementation of its services ensures that the Linn DS products are able to work with standard client software written to use ANY Upnp Media Renderer.

What you seem to be doing is completely disregarding the device architecture of Upnp. You discover the Upnp Media Renderer device, which in the case of Auskerry is an embedded device. You then collect its root device XML and scan it with abandon for any service, Upnp Standard or Linn Extension with complete abandon.

Firstly, this means your program may run into difficulties when it is presented with a Upnp Media Renderer from another manufacturer.

Secondly, there is no guarantee, from one DS software version to the next that the arrangement of root devices and embedded devices will stay the same.

To put it another way, Upnp provides a mechanism for discovering devices and a mechanism (by scanning the device XML) of then finding the services on that device.

However, if the device you discover is an embedded device, there is an anomoly within UPnP that means that you suddenly gain access through the root device xml to all sorts of services and devices that you weren't looking for.

So, instead of the normal pattern: discover a device and then discover its services,

You are following the ill-advised pattern: discover a device and then take advantage of a loophole in UPnP that allows you to see all sorts of other devices and services that you didn't originally search for.

Now, you can do this, but it is not a wise long term strategy because the assumption you are making concerning the relationship between the root devices and embedded devices might change (and indeed it has changed in BUTE)

To make your program robust over time you need to adopt a robust discovery strategy that is likely to survive across software versions, rather than use a discovery strategy that exploits a loophole in the UPnP protocol.

Graham

[grahamd Linn Staff]

By the way, you suggest that you might do better by searching for root devices.

This is rarely a good thing to do. In order to really help you with an appropriate strategy, I need to know what it is that you want your program to do.

But in advance of knowing this, the best strategy for a program that wants to utilise service X is to discover on service X. Simple as that. Far better than discovering all root devices and then scanning their device xml for service X - that just clogs up the network unnecessarily.

Graham