I’m having an issue with SSDP discovery on a Roku 2 XS running 5.0 software. It seemed to work correctly with the previous 4.9 software version but it does not respond to M-SEARCH requests as detailed in the external control guide here: http://sdkdocs.roku.com/display/sdkdoc/ … trol+Guide
It does spit out a NOTIFY message every hour or so (which is consistent with the Max-age of 3600 that it is returning) but the fact that it doesn’t respond to M-SEARCH is a problem. Is anybody else having this issue?
“Brimmstone” wrote:
It appears this has no been fixed in any of the 5.x releases to date. Again, this worked in 4.9.
Wat?
Of course it’s working, it’s too fundamental not to work.
I have an almost 3 year-old app that relies on M-SEARCH and it has been working fine (spare routers that dont support multicast).
Show the UDP datagram, what are you sending exactly and to whom?
I hate to beat a dead horse, but since I’m new to this forum I’m going to kick the pony a bit.
I’m having this problem getting SSDP Discovery to work. I’m monitoring the traffic on UDP port 1900 from my laptop while another machine is performing an M-SEARCH. I also have an AV receiver performing an M-SEARCH on the LAN. Wireshark shows these searches going out, and the AV Receiver gets a response from another PC on my network. The search for the Roku device (4200X) doesn’t produce a response from the unit, but I do get the NOTIFY messages from it every 20 minutes.
Have you tried sending the M-SEARCH query from your laptop, so you’re sure that Wireshark will show the UDP traffic between the laptop and the player?
And are the laptop and player on the same subnet? Or are you doing something fancier with multicast routing.
By the way, I’m fairly sure it doesn’t matter for Roku, but I believe technically you should include a MX: timeout line in the M-SEARCH query, e.g. MX: 3.
“RokuKC” wrote:
By the way, I’m fairly sure it doesn’t matter for Roku, but I believe technically you should include a MX: timeout line in the M-SEARCH query, e.g. MX: 3.
Yup. True on both: UPnP spec requires MX header but Roku player does not care (i just checked behavior is unchanged). Best to be compliant and send “MX: 1” though.
@LCubed - who are you sending the datagram to? Should be to 239.255.255.250. And are you listening for unicast response (i.e. direct reply)?
“RokuKC” wrote:
By the way, I’m fairly sure it doesn’t matter for Roku, but I believe technically you should include a MX: timeout line in the M-SEARCH query, e.g. MX: 3.
Yup. True on both: UPnP spec requires MX header but Roku player does not care (i just checked behavior is unchanged). Best to be compliant and send “MX: 1” though.
@LCubed - who are you sending the datagram to? Should be to 239.255.255.250. And are you listening for unicast response (i.e. direct reply)?
Yes, I’m sending the datagram to 239.255.255.250. I’m not really even listening yet. I wanted to check the response with Wireshark first to verify what I should see. I have Wireshark setup to look for traffic on port 1900, and the display filter set to (ip.src == 192.168.10.127) || (ip.src == 192.168.10.242)
.127 is the Roku, and .242 is the AMX control system sending out the multicast datagram.
So additional info:
The Roku is connected via WiFi to a Layer 2 managed switch connected to another Layer 2 managed switch which has the control system AND my laptop connected to it. One thing I could try is connecting my laptop to WiFi (like the Roku) and then seeing if I can still see the multicast datagram going out of the control system via Wireshark on the laptop. I’ll try that once I’m back from my business trip (6/19).
A carriage return, line-feed follow each line with an additional set at the end of the string.
I even set the roku to use the wired ethernet connection and connected it to the same switch as the control system sending out the datagram and the laptop running Wireshark.
I still don’t see any response from the roku unit. I don’t doubt this works, so I must be doing something wrong. I just don’t know what.
My thanks go out to those that have responded so far.
OK, so I used the Roku app on my Samsung smartphone, and it couldn’t find the Roku 3 either. When I manually put in the IP address, it worked fine. I saw the phone’s M-SEARCH datagram go out through Wireshark, but I didn’t see any response from the Roku unit.
A carriage return, line-feed follow each line with an additional set at the end of the string.
I don’t think you need the Content-Length in there. Apart from that, it looks like a valid M-SEARCH request.
I encountered similar problems. In my case, sometimes the SSDP discovery worked, sometimes it didn’t, sometimes it would only detect one Roku on the network when there were really two. This happened whether from the code running on my laptop or from the Roku IOS app. I assumed there was some router weirdness going on, but never got to the bottom of it. I changed my code to issue multiple M-SEARCH requests; usually between all the requests that would detect all the Rokus. I also did a scan of all the devices on the subnet to check which ones were Rokus. That worked 100% of the time even if the SSDP requests failed.
