I am playing with ECP and my Roku. When I use SSDP to discover my box, it gives me back the correct IP, but after a while the IP seems to have changed for the box and the SSDP call still gives me back the old IP address. Here is one of the responses:
HTTP/1.1 200 OK
Cache-Control: max-age=300
ST: upnp:rootdevice
USN: uuid:7F248787-B5DF-4C7B-8C9A-00DDEE3B9242::upnp:rootdevice
Ext:
Server: Roku UPnP/1.0 MiniUPnPd/1.4
Location: http://192.168.1.101:8060/
The last part of the IP seems to change from 101 to 100 pretty regularly, which might be my network and DHCP. Regardless, I would have expected the SSDP discovery to still work and always give me back the current IP address of my Roku.
If I soft reset my Roku, the SSDP starts to give me the correct IP again. Is this a known bug?
I have a Roku LT.
“destruk” wrote:
I fyou use mac address dhcp reservation, your roku will always be assigned the same IP.Which is a great solution for a single user, but for a remote developer hoping to support many users…? I’m planning on adding documentation to Remoku about how to add a dhcp res., since javascript can’t make use of the ssdp discovery anyway. But for remotes written in more permissive operating environments, we’d hope that the ssdp response would return the correct value..
OP, I’ve seen other people report the same issue (after dhcp re-assignment, ssdp discovery reports old address). I don’t know if Roku is tracking it yet.
For a remote developer with multiple users, how do you get past their firewall from outside the network? I don’t think you cdan have a solution for a standard IP address using DHCP, because when they turn off a device and turn others on, there isn’t a way to have that kind of control without using a dhcp reservation or disabling dhcp entirely. You’d probably really want a Roku with a built in modem and router into the same unit, which increases cost and complexity.
“destruk” wrote:
For a remote developer with multiple users, how do you get past their firewall from outside the network? I don’t think you cdan have a solution for a standard IP address using DHCP, because when they turn off a device and turn others on, there isn’t a way to have that kind of control without using a dhcp reservation or disabling dhcp entirely. You’d probably really want a Roku with a built in modem and router into the same unit, which increases cost and complexity.What? I’m not following.
The problem (for the OP) is that the ssdp response from a Roku can be wrong (for instance: the Roku has a dhcp-provided address of 192.168.1.100, but tells you it’s at .101 when you send the ssdp request). It’s a Roku bug. It can be worked around (as you suggested) by setting dhcp reservation, so that the Roku never gets confused, but part of the reason Roku added the discovery protocol is so that network remotes can always find the Rokus on the local network, without needing static/reserved ip addresses.
If it’s not working, how else would you fix it without requiring Roku to release an update? Would it even be possible to scan the network for the known MAC address of the roku devices on the network and then match them up to what the IP address should be, or is that not possible?
A bug report was filed today. In the meantime, if the connection fails, you could try the ugly but-usually-workable brute-force method: attempt to connect in succession to every ip address on the subnet on port 8060.
Wow! I am thrilled that a bug was filed. Hopefully it will be fixed. Would that come out as an automatic firmware update?
Because discovery is unreliable for this reason right now, I am debating whether to just type in the IP address. If I fail to connect I can go back to the settings screen and look up the correct one, re-enter and try again.
Paper-Clip reset always works, but it is just a workaround. Having a discovery feature discover the wrrong thing is worse that having no discovery mechanism in my opinion. If this gets fixed, would it be a fix for all Roku models? I’d love to test my little remote on more rokus and in different network configurations, but I don’t have that luxury.
“ajb2011” wrote:
Having a discovery feature discover the wrrong thing is worse that having no discovery mechanism in my opinion
if you make an http request (with a timeout of course so your process doesn’t get hung up waiting) to the port, you should be able to detect if it is a Roku pretty easily, by the resulting XML data, specifically the FriendlyName tag. I think some of the iPhone Roku remote apps might use this method, or something similar, as an alternative to SSDP.
“RokuJoel” wrote:
A bug report was filed today.
No bug existed on file for this one already?? It’s been a known/reported issue with the wireless interface since before the 2.9 firmware. Phil Irey (developer of DVPRemote) and I discovered it and reported it back in November of last year…
The Endless - I think it was your original post that gave me the workaround of a soft reset, so many thanks. I am just glad a bug is logged now, although I’d love to know the turnaround on somethng like that, if it is, in fact something Roku thinks should be fixed.
RokuJoel, are you referring to the case when the IP is wrong, that I just send it an http request to verify? The problem with that is, on my home network that IP is not associated with any device anymore. I also do not want to implement my own network scanning to try and find the device. I’d prefer SSDP to work as advertised, but I appreciate the suggstion.
if you make an http request (with a timeout of course so your process doesn’t get hung up waiting) to the port, you should be able to detect if it is a Roku pretty easily, by the resulting XML data, specifically the FriendlyName tag. I think some of the iPhone Roku remote apps might use this method, or something similar, as an alternative to SSDP.
Joel
Opening hundreds of hanging TCP connections is a horrible idea, please do not suggest it!
“ajb2011” wrote:
If I soft reset my Roku, the SSDP starts to give me the correct IP again. Is this a known bug?
Yes, it as known, long-standing bug - to me at least and i bet to every single remote app that uses ECP discovery. The SSDP implementation is atrocious, i think i lamented that in couple of postings already. Roku did not pay attention so far but since they released iPhone remote last week, probably will now - check that many of the negative reviews are because of this.
You don’t need to reset the player for a fix - instead you can:
a) power-cycle it (unplug power for couple of seconds) or
b) (with physical remote) repeat the network setup again - that does it
if you make an http request (with a timeout of course so your process doesn’t get hung up waiting) to the port, you should be able to detect if it is a Roku pretty easily, by the resulting XML data, specifically the FriendlyName tag. I think some of the iPhone Roku remote apps might use this method, or something similar, as an alternative to SSDP.
Joel
Opening hundreds of hanging TCP connections is a horrible idea, please do not suggest it!
I think the idea is to ping all the IPs to see what replies - and then open the TCP connection between those addresses that are in use - in most home LANs you’re talking about fewer than 10 devices. The roku always replies to ICMP.
“EnTerr” wrote:
Opening hundreds of hanging TCP connections is a horrible idea, please do not suggest it!
I think the idea is to ping all the IPs to see what replies - and then open the TCP connection between those addresses that are in use - in most home LANs you’re talking about fewer than 10 devices. The roku always replies to ICMP.
Check the thread above, RokuJoel said:
“RokuJoel” wrote:
… if the connection fails, you could try the ugly but-usually-workable brute-force method: attempt to connect in succession to every ip address on the subnet on port 8060.
But i hear you on the icmp ping idea. That will work - that is unless some router has automated protection from network scans (i.e. mass icmp trips blockage)
ok, I sure hope they fix it - that would be easiest. This makes me wonder what other issues have been mentioned that aren’t ‘officially on a bug list’ ?
“destruk” wrote:
ok, I sure hope they fix it - that would be easiest. This makes me wonder what other issues have been mentioned that aren’t ‘officially on a bug list’ ?
If I were hired by Roku to work it out with the developers (which seems they did… at last!), I’d mine this forum for ideas, dream and suggestions - it is quite fertile. On the other hand, maybe each of us should summarize their desires/misgivings/ideas and email them upstream - as Tom Markworth suggested in a comment here: http://blog.roku.com/blog/2011/12/15/in … -388362030
And speaking about bitching, WTF is the SDK for this year’s firmware, “rOS” 3.x and 4.x?!? DevHome still shows 2.9 as the latest. Are we waiting on Santa Clause to bring updated SDK? The old man better ship it overnight, 'cause the weekend is coming
“EnTerr” wrote:
And speaking about bitching, WTF is the SDK for this year’s firmware, “rOS” 3.x and 4.x?!? DevHome still shows 2.9 as the latest. Are we waiting on Santa Clause to bring updated SDK? The old man better ship it overnight, 'cause the weekend is coming
According to Joel earlier today (viewtopic.php?f=34&t=46212#p313444), they’re working on it right now, so hopefully that means soon.
Interesting that over 10 years later this is still happening on a Now TV roku stick
Model 3801UK running firmware 10.5.3
No real impact - other than wasting time investigating why i was seeing a lot of http connection errors in log files for an IP address that does not exist on my network and no traffic from it when checking with wireshark !
After some time investigating tracked it to this problem where an IP address change does not get reflected in the SSDP Search response !
