Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
UPnP eventing subscription bug?
19-01-2014, 12:59 PM (This post was last modified: 19-01-2014 01:26 PM by Duke.)
Post: #1
UPnP eventing subscription bug?
[Edit] Sorry for the confusion, but I figured (too late) that the device is MinimServer, and service ContentDirectory. Therefore I guess the issue is specific to this device.

Hi,

I'm developing an application consuming the OH Playlist service, and subscribing to this service events.

Using dbPoweramp Renaissance renderer as device for testing, I faced a situation where the SID header returned when subscribing for service events looks invalid.

The value returned is "uuid:2d456ab4-bede-4e9d-98a7-7800e22d153e-9" (notice the trailing "-9", which makes it an invalid UUID).

FYI, it if may be of any help, the product header value is "Windows/6.1 UPnP/1.1 ohNet/1.0"

Is this a bug? Or should I modify my code to consume only the relevant SID characters?

Thanks,

Denis
Find all posts by this user
19-01-2014, 09:15 PM
Post: #2
RE: UPnP eventing subscription bug?
(19-01-2014 12:59 PM)Duke Wrote:  I'm developing an application consuming the OH Playlist service, and subscribing to this service events.

Using dbPoweramp Renaissance renderer as device for testing, I faced a situation where the SID header returned when subscribing for service events looks invalid.

The value returned is "uuid:2d456ab4-bede-4e9d-98a7-7800e22d153e-9" (notice the trailing "-9", which makes it an invalid UUID).

The value returned here is a subscription id. This conforms to UPnP 1.0 rules that it is universally unique but not to UPnP 1.1 rules on uuid formatting.

You should use the SID exactly as it is returned in your application.
Find all posts by this user
20-01-2014, 07:46 PM
Post: #3
RE: UPnP eventing subscription bug?
(19-01-2014 09:15 PM)simonc Wrote:  The value returned here is a subscription id. This conforms to UPnP 1.0 rules that it is universally unique but not to UPnP 1.1 rules on uuid formatting.

You should use the SID exactly as it is returned in your application.

This seems like it might cause interoperability problems with UPnP 1.1 devices. Is there any plan to change these IDs to make them compatible with UPnP 1.1?
Find all posts by this user
21-01-2014, 08:53 AM
Post: #4
RE: UPnP eventing subscription bug?
(20-01-2014 07:46 PM)simoncn Wrote:  This seems like it might cause interoperability problems with UPnP 1.1 devices. Is there any plan to change these IDs to make them compatible with UPnP 1.1?

It could theoretically cause problems but only in hugely pedantic control points. We haven't found any of these yet.

I hadn't been aware of the uuid pedantry in UPnP 1.1 until Duke mentioned it. Addressing it isn't currently a high priority for us. If it became an issue, we could deal with it. Reverting to 1.0 support might turn out to be the easiest 'solution' in this case.
Find all posts by this user
21-01-2014, 09:19 AM
Post: #5
RE: UPnP eventing subscription bug?
(19-01-2014 12:59 PM)Duke Wrote:  [Edit] Sorry for the confusion, but I figured (too late) that the device is MinimServer, and service ContentDirectory. Therefore I guess the issue is specific to this device.

This is not specific to MinimServer. These IDs are created by ohNet, not by MinimServer, and you would see IDs in this format for all service subscriptions hosted by the ohNet runtime.
Find all posts by this user
21-01-2014, 09:25 AM
Post: #6
RE: UPnP eventing subscription bug?
Hi,

Thanks a lot for your answer. Now I know I'm hugely pedanticWink!
I hadn't noticed the slight but true difference between 1.0/1.1 UPnP Device Architecture documents.

I'll update my code.

Have a nice day,

Denis

(21-01-2014 09:19 AM)simoncn Wrote:  
(19-01-2014 12:59 PM)Duke Wrote:  [Edit] Sorry for the confusion, but I figured (too late) that the device is MinimServer, and service ContentDirectory. Therefore I guess the issue is specific to this device.

This is not specific to MinimServer. These IDs are created by ohNet, not by MinimServer, and you would see IDs in this format for all service subscriptions hosted by the ohNet runtime.
Find all posts by this user
21-01-2014, 09:33 AM
Post: #7
RE: UPnP eventing subscription bug?
(21-01-2014 09:25 AM)Duke Wrote:  Thanks a lot for your answer. Now I know I'm hugely pedanticWink!
I hadn't noticed the slight but true difference between 1.0/1.1 UPnP Device Architecture documents.

Oops, I'd mis-read your question. I thought you'd noticed an oddity with data returned... No pedantry-related offence intended!

Thanks for raising this. We started developing against the 1.0 spec and I hadn't even thought of this area changing for 1.1. If you've written a control point that does rely on 1.1 uuid formatting rules, that provides the example app I said would justify tidying up ohNet's behaviour... I'll see when we can fit this in.
Find all posts by this user
21-01-2014, 09:44 AM
Post: #8
RE: UPnP eventing subscription bug?
No offense at all, joking...
Speaking more globally, I think this is a good example of UPnP 1.1 major problem, having specs that are not backward compatible with 1.0.
Who will ever want to fully comply with 1.1???

(21-01-2014 09:33 AM)simonc Wrote:  
(21-01-2014 09:25 AM)Duke Wrote:  Thanks a lot for your answer. Now I know I'm hugely pedanticWink!
I hadn't noticed the slight but true difference between 1.0/1.1 UPnP Device Architecture documents.

Oops, I'd mis-read your question. I thought you'd noticed an oddity with data returned... No pedantry-related offence intended!

Thanks for raising this. We started developing against the 1.0 spec and I hadn't even thought of this area changing for 1.1. If you've written a control point that does rely on 1.1 uuid formatting rules, that provides the example app I said would justify tidying up ohNet's behaviour... I'll see when we can fit this in.
Find all posts by this user


Forum Jump: