I am broadcasting a discovery message like this:
M-SEARCH * HTTP/1.1\r\nHOST: 239.255.255.250:1900\r\nMAN: \"ssdp:discover\"\r\nMX: 10\r\nST: ssdp:all\r\n
and I usually get a response from my DLNA device. But sometimes I don't.
The bigger issue, is that if I have received a response once, and I broadcast a discovery message again, I don't get a response from my device the 2nd or subsequent time.
The way I read the documentation, is that devices are required to respond to these broadcast messages.
I have two questions:
Is there a limit to how often a device will respond to discovery messages?
Is there a way to work around to force/trick it into giving me a response a second time?
Couple of possible problems I see with the M-SEARCH (or not 100% compliance in any case):
About not receiving replies: There may of course be a reason (a bug) for the missing messages but note that you absolutely cannot trust on message delivery as this is UDP and not TCP. This is why even according to spec every M-SEARCH should be sent several times.
If I recall correctly UPnP spec vaguely suggests "hundreds of milliseconds" as the minimum repeat frequency for discovery messages.
The source for all of the above is UPNP arch document or rather my memory of it. I'm almost 100% sure that DLNA has extra requirements on these things but I can't remember those off the top of my head... These possible extra requirements probably shouldn't make devices not respond to you though.
EDIT: Oh heck, I had the DLNA spec open so why not:
MX seconds plus a second or two for any network delays.(formerly known as the DCP Framework)
Specifications:
Further documentation: