Roku Developer Program

[ljunkie]

Has anyone ran into an issue where the Roku does not respond to port 8060? I cannot replicate the the issue locally, but there is a user (with multiple Rokus) that cannot connect to port 8060 via the lan IP or http://127.0.0.1:8060 from within a channel. I can't say with certainty 7.1 is when this first started, but we noticed it then since the roVideoPlayer does not reset the idle time during video playback (separate issue).

[ljunkie]

I've identified the issue. It seems when the Roku is assigned a non RFC 1918 ip address, the Roku locks down port 8060 (probably due to viewtopic.php?f=34&t=88160). This is great, however this also blocks access to ECP within the channel on loopback, no so great. This has been causing some havoc in our channel with the release of 7.1. Please let me know if you (Roku) need anything else.

[EnTerr]

Your channel likes talking to itself, huh.
Is it using the external IP for that? If so, try `localhost` instead.

[ljunkie]

"EnTerr" wrote:
Your channel likes talking to itself, huh.

Yes, it does. roScreens do not allow the use of the standard screensaver (only a black out), so if you have a custom one, you must keep the Roku non-idle. The only way to do that is to use ECP to send a keypress. Ignoring the use of a custom screensaver, another issue is a custom slideshow written using the 2D API where one must also inhibit the standard black screensaver. As you can imagine, there are other things that may use the idle time of the Roku to fire event, such as a lock screen.

"EnTerr" wrote:
Is it using the external IP for that? If so, try `localhost` instead.

Sorry, I wasn't clear. I am not using the external/public IP. It makes sense to block access to the public IP, but they are also blocking access to localhost/127.0.0.1. It seems they just disable or completely block port 8060. Other ports, such as 8085 continue to work.

[belltown]

Use CreateObject("roDeviceInfo").GetIpAddrs() to find your Roku's ip address on the local network. Send your keypress ECP commands to port 8060 at the ip address(es) it returns.

[ljunkie]

"belltown" wrote:
Use CreateObject("roDeviceInfo").GetIpAddrs() to find your Roku's ip address on the local network. Send your keypress ECP commands to port 8060 at the ip address(es) it returns.

Thanks Belltown, this does not work. I am familiar with the roDeviceInfo, but here is the deal. Port 8060 is disabled in firmware 7.1 when your Roku is using a non RFC 1918 IP address. The Roku will not respond to port 8060 on the local IP address assigned or on 127.0.0.1 from within a channel. You can experience this if you give your Roku any IP address outside of the RFC 1918 address space. e.g. setup your lan (incorrectly) to use something like "11.0.0.0/24". Obviously this is wrong, but users will do this, as well as some will have their devices connected to the internet without a router/firewall (assigning real public IPs).

[RokuKC]

"ljunkie" wrote:

"belltown" wrote:
Use CreateObject("roDeviceInfo").GetIpAddrs() to find your Roku's ip address on the local network. Send your keypress ECP commands to port 8060 at the ip address(es) it returns.

Thanks Belltown, this does not work. I am familiar with the roDeviceInfo, but here is the deal. Port 8060 is disabled in firmware 7.1 when your Roku is using a non RFC 1918 IP address. The Roku will not respond to port 8060 on the local IP address assigned or on 127.0.0.1 from within a channel. You can experience this if you give your Roku any IP address outside of the RFC 1918 address space. e.g. setup your lan (incorrectly) to use something like "11.0.0.0/24". Obviously this is wrong, but users will do this, as well as some will have their devices connected to the internet without a router/firewall (assigning real public IPs).

> Port 8060 is disabled in firmware 7.1 when your Roku is using a non RFC 1918 IP address.

This isn't new behavior in firmware 7.1, but has been the case for many years.
As you describe, ECP services (port 8060) are not enabled when the Roku has a non-RFC 1918 IP address, for security reasons.
If something was working for your app prior to 7.1 and stopped working, possibly it is due to other security constraints.

I can certainly understand the wish that loopback services still worked in this situation, but it isn't set up that way as this is not a normal usage.
Do you think that some users are intentionally configuring their Rokus this way?
Perhaps the firmware should have a warning UI in the guided setup or in the settings UI if the user has this configuration.

[ljunkie]

"RokuKC" wrote:

> Port 8060 is disabled in firmware 7.1 when your Roku is using a non RFC 1918 IP address.

This isn't new behavior in firmware 7.1, but has been the case for many years.
As you describe, ECP services (port 8060) are not enabled when the Roku has a non-RFC 1918 IP address, for security reasons.
If something was working for your app prior to 7.1 and stopped working, possibly it is due to other security constraints.

Thanks for the update RokuKC. That makes sense, and after knowing this piece of info, it makes more sense. We have had other screens affected by this issue without understanding it was an issue. The fact that the video players (roVideoPlayer and roVideoScreen) no longer reset the idle time (mentioned in my initial post) was the coup de grace. We have a workaround for that now, awaiting Roku's approval, but I'd be nice if playback rest the idle time again - is that a bug or expected?

"RokuKC" wrote:

I can certainly understand the wish that loopback services still worked in this situation, but it isn't set up that way as this is not a normal usage.
Do you think that some users are intentionally configuring their Rokus this way?
Perhaps the firmware should have a warning UI in the guided setup or in the settings UI if the user has this configuration.

The users are not configuring their Roku this way on purpose, but they have misconfigured their network this way for whatever reason. While it's not valid, I can understand why one may accidentally configure their network with in invalid block, i.e. 194.168.0.x/24. Set aside an invalid configuration, it's still possible for people to have valid public IP addresses without a misconfiguration. Basically what it boils down to is finding some way to tell the Roku it's not idle.

A quick recap
1. The roVideoPlayer/roVideoScreen used to reset the idle time every 10 seconds. This no longer happens in 7.1. Can this be corrected?
2. Is there a valid way to tell the Roku it's not idle from within a channel. The ECP method was the only way, and as I take it will never work again going forward unless the Roku uses an RFC 1918 IP address. One example to clarify why this is important: A custom slide show written in an roScreen, or even roImageCanvas. Without a way to reset the idle time during playback, the Roku will initialize the the (black) screensaver rendering it useless.

[RokuKC]

"ljunkie" wrote:

1. The roVideoPlayer/roVideoScreen used to reset the idle time every 10 seconds. This no longer happens in 7.1. Can this be corrected?

I can file a report, but it might help to have more information, as I haven't heard of this issue being reported by anyone else.

"ljunkie" wrote:

2. Is there a valid way to tell the Roku it's not idle from within a channel. The ECP method was the only way, and as I take it will never work again going forward unless the Roku uses an RFC 1918 IP address. One example to clarify why this is important: A custom slide show written in an roScreen, or even roImageCanvas. Without a way to reset the idle time during playback, the Roku will initialize the the (black) screensaver rendering it useless.

We've documented a function in roAppManager which is UpdateLastKeyPressTime() that can be used to defer the screensaver activation.
Calling this should be preferred over the ECP fake keypress technique.

https://sdkdocs.roku.com/display/sdkdoc ... PressTime()asVoid

[EnTerr]

"RokuKC" wrote:
We've documented a function in roAppManager which is UpdateLastKeyPressTime() that can be used to defer the screensaver activation.
Calling this should be preferred over the ECP fake keypress technique.

https://sdkdocs.roku.com/display/sdkdoc ... PressTime()asVoid

That function was just added to docs 29 April but does not mention firmware version. What fw is it applicable to?

I lest i am told "everybody has 7.1" - somebody with lots of deployments recently was saying there is a good portion of firmware 5 out there?!