I’m told by a moderator that I run the risk of being banned as a spammer if i mention my DMC device by name. lol. You know who you are. 
You can contact me by email if you need further details or developer credentials. I wrote a DMC. I found bugs with your product. Both bugs have relatively survivable workarounds. Both should be fixed if you expect DMCs to work with your device.
Two bugs, reported here because I have idea where else I would report them.
- XML Parsing rules are actually incorrect. > does NOT require escaping in XML text. So, for example, the following is a legal XML fragment:
<x:element><encodeed-element></x:element>
equivalent in all respects to
<x:element<encoded-element></x:element>
But the WD TV Live Plus DMR pretty much crashes if you send this sequence in an AVRenderer soap packet. Encoding >s with & escapes works around the problem. other devices handle this fine. it took me a while to figure out what it was that sent WD TV Live Plus into death spirals. There it is.
- WD TV Live Plus AVRenderer service returns invalid DIDL when encountering upnp namespaces declarations in track metadata. It seems to do textual substitutions to splice the element into the DIDL item returned by media info calls to the AVTransport service, rather than generating XML via from-first-principles XML parsing and generation. To replicate the problem, send AVtransport:SetAVTransportURI using the verbatim didl:item metadata provided by the Twonky server on a WD World Book II. let the track start, and then call GetMediaInfo, or GetPositionInfo. The didl:item returned in getMediaInfo:CurrentURIMetata or GetPositionInfo:TrackMetaData is not valid XML. The issue: the DMR seems to have attempted to move xmlns declarations from the res element to the topmost item element, but it has a bug. The xmlns declarations are malformed in are malformed (the DMR seems to have miscounted and ignroed the last one); as a result, upnp:duration apperas in the element without a valid xmlns declaration anywhere in the fragment, and XML parsers at the DMC end will throw “invalid XML” exceptions". The workaround: don’t send upnp:position attributes on the DIDL element when calling setAVTransportURI (which avoids the requirement for the DMR to wrote an xmlns:upnp= namespace declaraion in the DIDL item, and thereby avoids the bug).
The impact is severe for DMCs without a workaround, becuase they won’t be able to get ANY transport status information from the DMR. My DMC writes custom metadata specifically for WDTV devices.
Regards,
Robin Davies.
Author of a DMC That Shall Not be Named.
2.5). You guys REALLY need to return SOAP errors for messages you don’t like for one reason or another. Makes it VERY difficult to debug against your device. There are a number of other peculiarities your device has that escape me now. One has to debug in the dark because the DMR just accepts the messages, while performing no action.
- Oh yeah. You seem to have a fairly large resource leak when media streams are terminated at the sender end. The device gets slower and slower and eventually crashes when the HTTP connection is terminated by the sender. It’s not unreasonable to expect ContentDirectory services to go offline mid-stream. I saw it quite often while debugging, where this happens at a fairly abusive rate. The issue would be more subtle IRL, but would definitely crash the device reasonable often (e.g. a router reboot stands about a 1 in 4 chance of taking the DMR down, I think. Rough estimate).
