I notice that if I kill off a CyberLink device (unclean shutdown) and restart it, then the Intel Control Point sees multiple instances of the same device. I think it is related to the fact that CyberLink is dynamically creating a new device UUID at startup, and since it uses system time, it ends up different for each invocation. When the control point sees the device announce itself the second time, it looks like it's a different device, so it adds another icon to control the second device.
I looked at the book "UPNP design by example" (Intel) and it looks like they imply that the UUID *is* dynamic, and based in part on the system time.
Devices actually based on the Intel UPNP stack however, always come up with the same, static UUID. When I override the CLink-generated UUID with a static one in my devices, the Intel control point behaves much better - a restart of a device results in the tool recognizing that it is the same device, and not instantiating a second copy of it.
One other related issue is a recommendation in Intel's white paper on designing a media server. They recommend that in order to handle the case of unexpected device shutdown, devices should send out 2 'bye-bye' messages at startup before sending their 'announce' so control points can 'clean-up' any lingering previous instances of the device.
If the UUID is static, it seems like this is not really
necessary, since the control point can figure out that
it's a new instance of the same device and reinitialize things without having to see a 'bye-bye' message.
I guess at this point I'm favoring static UUID's for my devices. Anyone have any thoughts on what the 'best practice' is with regard to this? I actually haven't pored
over the UPNP Spec yet looking for info since I'm too lazy. :)
I seem that the UUID isn't changed if you use Device::start() and stop() because the UUID is only created the construtor of the Device class.
Device dev = new Device("foge.xml");
I think the UUID shouldn't be static if you want to run the same devices on a computer.
I believe that the UUID should not change for any given device unless there is a significant change in the general environment, e.g. the host address changes, or device version changes. This enables control points to find and manage device over prolonged periods of time. Unfortunately I can't find the specific document that discusses this, so you may want to do some research and verify.
BTW - are you developing for yourself? I have an AV implementation and I'm considering an opensource release - would you be interested in helping out? The rendering architecture needs the most work.
According to the following guide, I knew that the UDN should be static.
UPnP Vendor's Implementation Guide:
I will fixed to update the UDN automatically only when the UDN is not specified in the descripton file.
Hi Satoshi -
Thanks for tracking that down - I was just about to go searching and now I don't have to! :)
So after the change it sounds like the suggested practice
1. If running only one copy of a device on a particular host,
put a unique USN in the description.xml file and the
device will always use that
2. If running more than one copy of a device on a single
host, leave the USN out of the description file so it gets
dynamically generated, otherwise there will be USN
(Yes I like to restate the obvious :) )
Sounds good to me...Thanks as usual!
Hi Tim -
I'm working for a small company that is using a variety of UPNP and other technologies to address home control and media distribution needs. We're using the Intel, Cybergarage, and (to a lesser extent Siemens) UPNP stacks to help build up our prototype systems. (Yes I like the Cybergarage stack the best!).
The powers that be are definitely committed to contributing back to the open source community, but haven't yet completely figured out their strategy. So I can't help out at the moment - hopefully in a couple of months things will be clearer in that regard and I will be able contribute somehow.
So, 2 month rain-check?
As far as UPNP renderers go, I just got hold of a Play@TV device (playattv.com) and it's pretty cool - I can get it to play music on my stereo via UPNP commands coming from the CLink package. I think video should work too, though since it wasn't designed completely from the ground up as a UPNP device, there may be some 'issues'. Nevertheless, it's the first real standalone UPNP MediaRenderer I have seen. Might be useful for testing/demoing your A/V implementation!
Be aware there is one bug with the device - see my post under 'feature requests' regarding missing 'Content-Length' headers in HTTP responses. I did hack up a workaround if you are interested.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.