Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[simoncn]

The "initial event" NOTIFY message sent by the MC UPnP renderer doesn't conform to the UPnP Device Architecture specification and can't be parsed by a spec-compliant UPnP control point.

According to section 4.3.2 of the UPnP Device Architecture 1.1 document (page 98), the required format is:

Code: [Select]

<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<firstName>firstValue</firstName>
</e:property>
<e:property>
<secondName>secondValue</secondName>
</e:property>
<e:property>
<thirdName>thirdValue</thirdName>
</e:property>
</e:propertyset>

with a separate <e:property> tag for each value. The MC renderer is sending this:

Code: [Select]

<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<firstName>firstValue</firstName>
<secondName>secondValue</secondName>
<thirdName>thirdValue</thirdName>
</e:property>
</e:propertyset>

The control point is (correctly) parsing only the first property value, so the other values are uninitialized. This problem is preventing me from using the MC UPnP renderer.

[AndrewFG]

The "initial event" NOTIFY message sent by the MC UPnP renderer doesn't conform to the UPnP Device Architecture specification and can't be parsed by a spec-compliant UPnP control point.

According to section 4.3.2 of the UPnP Device Architecture 1.1 document (page 98), the required format is:

Code: [Select]

<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<firstName>firstValue</firstName>
</e:property>
<e:property>
<secondName>secondValue</secondName>
</e:property>
<e:property>
<thirdName>thirdValue</thirdName>
</e:property>
</e:propertyset>

with a separate <e:property> tag for each value. The MC renderer is sending this:

Code: [Select]

<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<firstName>firstValue</firstName>
<secondName>secondValue</secondName>
<thirdName>thirdValue</thirdName>
</e:property>
</e:propertyset>

The control point is (correctly) parsing only the first property value, so the other values are uninitialized. This problem is preventing me from using the MC UPnP renderer.

I think you are not quite right here...

The UPnP Audio Video specifications require that all events are bundled as a combined XML payload within one single property named LastChange. So compliant UPnP AV Renderers (including MC) always send just this one single property value. You can read about this here: http://upnp.org/specs/av/UPnP-av-AVTransport-v1-Service.pdf

So if you think your are seeing multiple properties in an event notification, (as you describe in your post), then you are probably mistaken. Also if you expect to see multiple properties, you are also certainly mistaken...

[simoncn]

I think you are not quite right here...

The UPnP Audio Video specifications require that all events are bundled as a combined XML payload within one single property named LastChange. So compliant UPnP AV Renderers (including MC) always send just this one single property value. You can read about this here: http://upnp.org/specs/av/UPnP-av-AVTransport-v1-Service.pdf

So if you think your are seeing multiple properties in an event notification, (as you describe in your post), then you are probably mistaken. Also if you expect to see multiple properties, you are also certainly mistaken...

This NOTIFY message is being sent for a subscription to the ConnectionManager:1 service, which doesn't use the LastChange property.

Here is the start of the data that MC is sending (captured from Wireshark):

Code: [Select]

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<CurrentConnectionIDs>0</CurrentConnectionIDs>
<SourceProtocolInfo/>
<SinkProtocolInfo>http-get:*:audio/L16;rate=22050;channels=1:DLNA.ORG_PN=LPCM,
http-get:*:audio/L16;rate=22050;channels=2:DLNA.ORG_PN=LPCM,
http-get:*:audio/L16;rate=22050;channels=4:DLNA.ORG_PN=LPCM,
http-get:*:audio/L16;rate=22050;channels=6:DLNA.ORG_PN=LPCM,


[AndrewFG]

Ok. That does indeed look wrong.

IMHO I would not worry too much about bad formatted events from the ConnectionManager service. Because other than the initial event (to get the status) its properties will probably never change anyway (at least not in MC)...

[simoncn]

Ok. That does indeed look wrong.

IMHO I would not worry too much about bad formatted events from the ConnectionManager service. Because other than the initial event (to get the status) its properties will probably never change anyway (at least not in MC)...

The problem is that the control point stack chokes on the bad formatting, which is a showstopper for me.

[AndrewFG]

The problem is that the control point stack chokes on the bad formatting, which is a showstopper for me.

In addition to informing about MC here, you should also inform the CP maker. A CP that falls over like that is a bad design and a security risk.

[simoncn]

In addition to informing about MC here, you should also inform the CP maker. A CP that falls over like that is a bad design and a security risk.

How do you think the control point should react to this? It is unable to retrieve all the property values because of the formatting error. I can think of two options:

1) It could refuse to recognise the MC renderer.

2) It could substitute null values for the properties that it couldn't read, which would leave me unable to use the MC renderer because of the missing protocol information.

In either case, I wouldn't be able to use the MC renderer unless the formatting bug is fixed.

[AndrewFG]

How do you think the control point should react to this? It is unable to retrieve all the property values because of the formatting error.

Are you writing your own CP?

If the CP receives an Event notification that it is not able to parse, then it should just return an HTTP 4xx error (see the device architecture specifications). In my opinion a CP should never try to double guess what might have been the content of that notification if it would have been able to parse it.

Also in my opinion a CP should never refuse to talk to a UPnP device simply because its event notifications are bad. If the device behaves OK on the Description and Control parts of the specifications, it is probably still usable. (I say this because there are indeed many usable devices that behave badly on the Eventing part of the specification).

unable to use the MC renderer because of the missing protocol information.

Use the GetProtocolInfo method rather than relying on eventing.


EDIT: by the way, if you are indeed writing your own CP I want to give you top praise for wanting to check SinkProtocolInfo before pushing streams to a renderer. Most CPs (including MC) just push what they want without so checking the renderer's capabilities. In my opinion that is lazy. The whole purpose of SinkProtocolInfo and SourceProtocolInfo is to provide a proper clean way for negotiating the highest common denominator stream format that both server and renderer can mutually support. The GetProtocolInfo method is in the specification for a very good reason.

[simoncn]

Are you writing your own CP?

I'm writing a renderer proxy which passes CP invocations to the real renderer and passes renderer event notifications to the CP.

If the CP receives an Event notification that it is not able to parse, then it should just return an HTTP 4xx error (see the device architecture specifications). In my opinion a CP should never try to double guess what might have been the content of that notification if it would have been able to parse it.

This is the initial event notification (see section 4.1 of the UPnP Device Architecture specification). The initial event notification must be received and processed before other events can be processed. If the control point rejects the initial event, this would mean that eventing is completely disabled for this renderer.

Also in my opinion a CP should never refuse to talk to a UPnP device simply because its event notifications are bad. If the device behaves OK on the Description and Control parts of the specifications, it is probably still usable. (I say this because there are indeed many usable devices that behave badly on the Eventing part of the specification).

These evented state variables are a required part of the UPnP specification for ConnectionManager:1. Any device that claims to be a UPnP renderer (as MC does) should support them.

Use the GetProtocolInfo method rather than relying on eventing.

This would work if the control point could safely assume that the value will never change.

EDIT: by the way, if you are indeed writing your own CP I want to give you top praise for wanting to check SinkProtocolInfo before pushing streams to a renderer. Most CPs (including MC) just push what they want without so checking the renderer's capabilities. In my opinion that is lazy. The whole purpose of SinkProtocolInfo and SourceProtocolInfo is to provide a proper clean way for negotiating the highest common denominator stream format that both server and renderer can mutually support. The GetProtocolInfo method is in the specification for a very good reason.

The problem with this is that some renderers don't send complete and correct protocol information, so a control point that does these checks might refuse to send a stream to a renderer even though the renderer would be able to handle the stream. Also, there is enormous confusion over which MIME types are correct for various stream types, which can cause a similar problem.

[Hendrik]

Do I understand the problem correctly, that instead of the dump you quoted above, it should look like this?

Code: [Select]

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<CurrentConnectionIDs>0</CurrentConnectionIDs>
</e:property>
<e:property>
<SourceProtocolInfo/>
</e:property>
<e:property>
<SinkProtocolInfo>http-get:*:audio/L16;rate=22050;channels=1:DLNA.ORG_PN=LPCM,
http-get:*:audio/L16;rate=22050;channels=2:DLNA.ORG_PN=LPCM,
http-get:*:audio/L16;rate=22050;channels=4:DLNA.ORG_PN=LPCM,
http-get:*:audio/L16;rate=22050;channels=6:DLNA.ORG_PN=LPCM,.................

I should familiarize myself with the UPnP/DLNA specs.
Until I get a chance, maybe bob sees this and can confirm and fix.

[AndrewFG]

I'm writing a renderer proxy which passes CP invocations to the real renderer and passes renderer event notifications to the CP.

If your are proxying, then IMHO you should just pass on what you get.

This is the initial event notification (see section 4.1 of the UPnP Device Architecture specification). The initial event notification must be received and processed before other events can be processed. If the control point rejects the initial event, this would mean that eventing is completely disabled for this renderer.

No. It would only be disabled for that particular service (ConnectionManager) on that renderer.

These evented state variables are a required part of the UPnP specification for ConnectionManager:1. Any device that claims to be a UPnP renderer (as MC does) should support them.

Yes. And all renderers that I have seen do actually support those state variables. But not all of them accurately support eventing on those state variables...

This would work if the control point could safely assume that the value will never change.

Personally I would just call GetProtocolInfo every time just before I wanted to push something to the player.
But in reality is extremely unlikely that a renderer would suddenly change the list of formats that it can play; and if it did so, then it is quite likely that it would go bye-bye in between. Or ??

The problem with this is that some renderers don't send complete and correct protocol information, so a control point that does these checks might refuse to send a stream to a renderer even though the renderer would be able to handle the stream. Also, there is enormous confusion over which MIME types are correct for various stream types, which can cause a similar problem.

Yes. This is indeed the argument that many CP writers use as a justification for not calling GetProtocolInfo and just pushing whatever they darn well choose.

[AndrewFG]

Do I understand the problem correctly, that instead of the dump you quoted above, it should look like this?

Code: [Select]

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<CurrentConnectionIDs>0</CurrentConnectionIDs>
</e:property>
<e:property>
<SourceProtocolInfo/>
</e:property>
<e:property>
<SinkProtocolInfo>http-get:*:audio/L16;rate=22050;channels=1:DLNA.ORG_PN=LPCM,
http-get:*:audio/L16;rate=22050;channels=2:DLNA.ORG_PN=LPCM,
http-get:*:audio/L16;rate=22050;channels=4:DLNA.ORG_PN=LPCM,
http-get:*:audio/L16;rate=22050;channels=6:DLNA.ORG_PN=LPCM,.................

I should familiarize myself with the UPnP/DLNA specs.
Until I get a chance, maybe bob sees this and can confirm and fix.

Correct.

Following is an extract from the UPnP Device Architecture specifications:

propertyset Required. Contains the following sub element.
property Required. Repeat once for each variable name and value in the event message. Contains the following sub element.
variableName Required. Element is name of a state variable that changed (name sub element of stateVariable element in service description). Value is the new value for this state variable.

EDIT: and instead of sending <SourceProtocolInfo/> I would personally recommend sending <SourceProtocolInfo></SourceProtocolInfo>

[simoncn]

EDIT: and instead of sending <SourceProtocolInfo/> I would personally recommend sending <SourceProtocolInfo></SourceProtocolInfo>

I agree that this change would be desirable. The UPnP Device Architecture 1.1 specification explicitly states on page 98 that property values should use the syntax:

Code: [Select]

<e:property>
<variableName>new value</variableName>
</e:property>

It is safer to use this syntax for an empty value to ensure interoperability with al control points.

[Hendrik]

So we cannot even send proper XML now?

[simoncn]

If your are proxying, then IMHO you should just pass on what you get.

I am trying to do this, but the control point and device stacks that I'm using don't support receiving or sending of incorrectly formatted event messages.

No. It would only be disabled for that particular service (ConnectionManager) on that renderer.

Agreed.

Yes. And all renderers that I have seen do actually support those state variables. But not all of them accurately support eventing on those state variables...

As these variables are defined in the service spec as evented, and the Device Architecture spec requires all evented state variables to appear in the initial event message, it seems to me that the renderer is required to send an initial event message containing all these state variables.

Personally I would just call GetProtocolInfo every time just before I wanted to push something to the player.
But in reality is extremely unlikely that a renderer would suddenly change the list of formats that it can play; and if it did so, then it is quite likely that it would go bye-bye in between. Or ??

The SinkProtocolInfo data from the MC renderer is 12000 bytes long. Retrieving and parsing this every time seems like an overhead that should ideally be avoided.

[AndrewFG]

As these variables are defined in the service spec as evented, and the Device Architecture spec requires all evented state variables to appear in the initial event message, it seems to me that the renderer is required to send an initial event message containing all these state variables.

You are quite right. However many don't do that...

The SinkProtocolInfo data from the MC renderer is 12000 bytes long. Retrieving and parsing this every time seems like an overhead that should ideally be avoided.

You are going to be streaming tracks that are tens if not hundreds of megabytes in length. Who cares about an additional 12k before each track...

[AndrewFG]

So we cannot even send proper XML now?

I know you're smiling, but it is worth pointing out that both xml forms are proper for empty strings, and every device must have code to parse the long form, and perhaps some of those devices forgot to implement code to parse the short form. In this business you have to think and code defensively...

[Hendrik]

I should probably figure out why my Sony TV fails at video playback when accessing the MC DLNA server and why I cannot use it as a renderer at all. Then I could actually test some things.

[AndrewFG]

I should probably figure out why my Sony TV fails at video playback when accessing the MC DLNA server and why I cannot use it as a renderer at all. Then I could actually test some things.

Sony devices are strict on the DLNA extensions. And specifically they usually only play tracks where the server offers the track item with a resource element that has a ProtocolInfo attribute that has the full monty of DLNA flags attached.

[bubbleguuum]

If you are dealing with UPnP devices you didn't write yourself, don't use eventing at all. It is buggy, incomplete or unusable with so many devices that you just cannot rely on it working. The only case I use eventing is to be notified of volume changes. And even that is broken with somes devices.

[AndrewFG]

Hi bubbleguuum -- it is good to see you over on this forum too !!

If you are dealing with UPnP devices you didn't write yourself, don't use eventing at all. It is buggy, incomplete or unusable with so many devices that you just cannot rely on it working. The only case I use eventing is to be notified of volume changes. And even that is broken with somes devices.

Hmm. That is a very black statement. But basically I do agree with you. Perhaps I see it more gray than black...

As far as MC is concerned, (bob please correct me if I am wrong), I think it first tries to get status via event notifications, and if that fails it falls back to the polling method.

IMO the state variables which change fastest are the xxxTimePosition & xxxCounterPosition variables, and these are not evented variables, so you are forced to use the polling method for them anyway. And the polling method (GetPositionInfo) does pull a lot of (meta) data in each poll, so it is quite a resource hog. But on the other hand, none of the other AV state variables change much and so the polling method can be used for them with little extra overhead.

[bob]

Hi bubbleguuum -- it is good to see you over on this forum too !!

Hmm. That is a very black statement. But basically I do agree with you. Perhaps I see it more gray than black...

As far as MC is concerned, (bob please correct me if I am wrong), I think it first tries to get status via event notifications, and if that fails it falls back to the polling method.

Mostly correct. We look for the events and if we don't get them poll but we'll still deal with the events if we eventually get them.
Which reminds me that I don't think we are asking for volume change events.

Hendrik thanks for fixing the NOTIFY message.

[simoncn]

Hendrik thanks for fixing the NOTIFY message.

Will there be an update available soon that I could try (please)?