DLNA Discoverability problems

1k views Asked by At

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:

  1. Is there a limit to how often a device will respond to discovery messages?

  2. Is there a way to work around to force/trick it into giving me a response a second time?

1

There are 1 answers

2
Jussi Kukkonen On BEST ANSWER

Couple of possible problems I see with the M-SEARCH (or not 100% compliance in any case):

  • should have an (additional) empty line in the end
  • Max value of MX is 5

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:

  • You should send more than 1 M-SEARCH.
  • Should not exceed 10 M-SEARCHes per any 200 ms period.
  • The original and duplicates should be sent inside 10 secs.
  • You should wait for replies for MX seconds plus a second or two for any network delays.

UPnP Device Architecture (UDA) documentation

(formerly known as the DCP Framework)

Specifications:

Further documentation: