I have noticed a weird behavior that might be a bug. Here's a sequence for reproducing it.
1.) Start a control point (say, some demo control point from the CyberLink examples).
2.) Start a device.
3.) Subscribe the control point to some state variable of the device. Now notifications start arriving to the control point - nice, that's exactly what we want.
4.) Now quit the control point, but not the device.
5.) Restart the control point. Now, oddly enough, notifications from the device still keep coming to the control point! And at this point, calling unsubscribe won't work anymore. And if the control point now searches the device and subscribes to the state variable again, it will receive duplicate notifications (with distinct uuids).
One workaround is to explicitly stop the control point before exit. In Java, Runtime::addShutdownHook is one way to guarantee this, but the example control
points in the CyberLink examples don't seem to bother doing this.
Just wondering whether this is a genuine bug or a specified feature.
I don't know if that is a bug...
...may be the bug is that the CP can't unsubscribe itself as receiver of the events coming from the device
..BTW, if I'll get the time I'll try to have a look to the code and see what's wrong..
FYI, as far as remember from the UPnP Standard the CP don't have to follow a "unplug from network procedure" before the shut down.
Stefano "Kismet" Lenzi
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.