So, after the latest update, Windows UPnP is not happy with the service description of the DeviceProperties service. So our driver is broken again. This has been an ongoing issue. I know there's a new API, but until it's capable of replacing the UPnP API, it's not of much use to us.
Anyone else see this yet?
Page 1 / 1
Other services, BTW, still work fine. There's just something not happy with that particular one. When you try to create an IUPnPService object it croaks with a general error, which I think means it failed while processing the service description.
Wow its been a while, but AFAIK it was a namespace issue that broke the Windows api last time (~5 years ago?). I did open a bug against Windows (I work at MS) but that was several bug databases ago. Not coincidentally that's when I started to write my own UPnP stack. If you can point me to a simple repro I am happy to open another bug.
Last time, if we are talking about the same one, the issue was something with the device description. We worked around that by taking over that part of the process ourself. But, in the case of service creation, the Windows API doesn't allow for any sort of manual creation. It finds the service description itself and creates the service based on that. So we can't really work around that, without writing our own of course.
I've written a million lines of code for CQC, and I'm not opposed to writing code. But UPnP seems a bit long in the tooth at that point to put in the effort. Of course it's probably something fairly minor and, if Sonos would bother to test against the Windows UPnP interface, they could likely avoid the problem very easily.
I don't have a simple trivial example, but basically just use the Windows UPnP API to get the Sonos device and then ask to create the device properties service. That will fail if you are on the latest Sonos firmware. Even if I wrote up an example it would be relative to our own software platform, which wouldn't be something useful to MS as an example probably.
I've written a million lines of code for CQC, and I'm not opposed to writing code. But UPnP seems a bit long in the tooth at that point to put in the effort. Of course it's probably something fairly minor and, if Sonos would bother to test against the Windows UPnP interface, they could likely avoid the problem very easily.
I don't have a simple trivial example, but basically just use the Windows UPnP API to get the Sonos device and then ask to create the device properties service. That will fail if you are on the latest Sonos firmware. Even if I wrote up an example it would be relative to our own software platform, which wouldn't be something useful to MS as an example probably.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.