"belltown" wrote:
One thing I wasn't really clear about was the "MX" header; I wasn't sure whether to leave it out, or if using it, what value to use for it. Maybe his devices are taking longer to respond to the SSDP requests, due to the number of devices, or network configuration, or something.
Ah, the MX header :). I know you are stickler for the specs, so you will enjoy this: according to SSDP, the MX header is REQUIRED and "If the search request does not contain an MX header, the device must silently discard and ignore the search request." Not so with Roku - it responds regardless if it's there - and the ECP doco actually codifies it will work w/o MX, based on the example (if they fix it now, it will break bunch of apps that believed the documentation verbatim, so better not to). I found said feature amusingly beneficial when issuing "ST: ssdp:all" - usually (with MX) i got storm of responses - routers, DirecTV - everybody reporting multiple upnp devices. Without MX though? - everybody but Roku shut up.
Also, until a few years ago there was this feature where sending SSDP with "MX: 0" would reboot Roku. All Rokus on the local network, really. Marvelous way to restart them all with a single packet. A datagram sealed with a kiss of death. A kill-a-gram?
I did notice during my own testing that there were times when one or more Rokus did not always respond to SSDP requests. I'd try again later then every device responded.
That's normal. UDP is short for "Unreliable Datagram Protocol" :P. The MX random delay was devised to decrease collisions but some loss or dupes will happen regardless.