We developed an ECP driver for use with Control4 and it has been working great. Unfortunately, our first client with a Roku 2 is seeing issues with the driver that we’ve not seen before on v1 hardware. Has there been any changes to the way ECP works on the new hardware or has the legacy port/codes on 8080 been deactivated or altered in any way?
Again these errors are only occurring on v2 hardware.
What are the issues you’re seeing? I don’t believe the Roku2 should operate any differently via ECP than the legacy products.
“diamonddesign” wrote:
We developed an ECP driver for use with Control4 and it has been working great. Unfortunately, our first client with a Roku 2 is seeing issues with the driver that we’ve not seen before on v1 hardware. Has there been any changes to the way ECP works on the new hardware or has the legacy port/codes on 8080 been deactivated or altered in any way?
Again these errors are only occurring on v2 hardware.Are you using ECP (as described in the ExternalControlGuide.pdf of the SDK), or the older telnet codes (port 8080)? With ECP, I haven’t run into any problems on the Roku 2. I haven’t ever tried the telnet codes, however.
“RokuPatrick” wrote:
What are the issues you’re seeing? I don’t believe the Roku2 should operate any differently via ECP than the legacy products.
The problem is that they keypress commands were broken for the Netflix channel and Channel Store prior to the Roku 2. As a workaround, you could use the legacy telnet commands on the Roku 1 to navigate reliably but the telnet commands don’t appear to be work (or work the same) on the Roku 2.
I reported the problem with the ECP keypress commands in the Netflix channel a while back (last September) and it was further discussed in this thread http://forums.roku.com/viewtopic.php?f=34&t=33713.
The problem that the follwing commands don’t work on the Netflix Channel, the channel store, and probably other places as well:
/keypress/Left
/keypress/Right
/keypress/Fwd
/keypress/Rew (not even with Rev instead of Rew)
The commands work on the main screen though.
An easy way to see the problem is to do the following from a unix command line: echo -e ‘POST /keypress/Right HTTP/1.1\r\n\r\n’ | ncat 192.168.1.148 8060
In the Netflix channel and in the channel store, when you execute the command above, you hear the sound like the command was received but the cursor doesn’t move off the current selection.
If you execute the same command above on the main springboard, you hear the sound and the cursor moves right as you would expect.
Without support for these commands, some things are very hard to do since keydown/keyup timing isn’t reliable.
Are there plans to fix this?
Thanks,
phil
I did some additional investigation with the telnet commands and they definitely work differently on the Roku 1 and Roku 2.
If I telnet to a Roku 1 on port 8080 and type “press left”, the Roku 1 will move the cursor 1 poster to the left. If in the same session, I type “press left” again the Roku 1 will move the cursor 1 poster to the left. This pattern will continue as many times as I wish to repeat it.
If I telnet to a Roku 2 (XS) on port 8080 and type “press left”, the Roku 2 (XS) will move the cursor either 1 or 2 posters to the left. I can’t find a pattern for whether it will be 1 or 2 posters but so far it seems to move that amount each time. This is clearly much different than the Roku 1.
If just telneted to the Roku 2 (XS) on port 8080 and typed “press right”. The Roku 2 (XS) moved the cursor one poster to the right (with the tick sound) and then made the “OK” button sound but did not select the poster was on. When I typed “press right” again in the same telnet session, it brought up the “Options Screen” (change channel position, show channel description, etc.).
I know the telnet commands aren’t technically supported but they are the only workaround I could come up with for commands in the published API which do not work on some of the main channels.
Any thoughts on a way ahead would be appreciated.
Thanks,
phil
Phil is correct.
We first developed a driver for Control4 based 100% on the ECP. However, we quickly found that 4 channels were “broken” and one of those was Netflix which happens to be the primary channel that most people use. The navigation buttons (up down left right) were the ones that wouldn’t work and act as Phil stated. The only reliable work around was using the old codes on 8080 for up/down/left/right and using the new commands on 8060 for everything else. Fortunately, this worked like a charm and lots of Rokus have been sold to Control4 customers since this development (I can track the driver downloads easily).
Phil had actually mentioned a few months ago to me by email that if they ever kill legacy support his app and our driver would stop working reliably. Now it appears that this has been done without a fix for the new commands, i.e., they’ve killed support for the old commands without a fix for netflix and a few other grid based channels.
I should have said any new problems on the roku 2. My experience has been the same. Sorry for the confusion.
“gonzotek” wrote:
I should have said any new problems on the roku 2. My experience has been the same. Sorry for the confusion.
For me the new problem is that the telnet commands on port 8080 seem to provide random results on the Roku 2. This is very different than the Roku 1 where the behavior was consistent. (I know you said you did not try the telnet commands yet…)
Patrick or anyone else have any suggestions on this?
Will either the /keypress commands that don’t work in the Netflix channel on both the Roku 2 and Roku 1 be fixed or will the legacy telnet commands be fixed on the Roku 2?
I’d like to have my ECP application work uniformly on both the Roku 1 and Roku 2.
If you fix the /keypress commands the Netflix channel, will these fixes be rolled out to the Roku 1 and Roku 2 simultaneously? If the fixes aren’t rolled out simultaneously, is there any way for an ECP app to tell what version of firmware a particular box is running? Without this, I won’t be able to migrate until it is rolled out for both platforms since this would break Roku 1 users.
Thanks,
phil
Also,
I’m not sure if Roku development actually pays attention to threads like these but I know of tons of units that have been sold recently that were forced to buy v1 instead of v2 to get the product to work with Control4. Some elected to go with AppleTV instead. When amazon and other places run out of stock on v1, they will all go with other products.
There are over 1,000,000 installs out there so I wouldn’t take this lightly.
At least reply and say, sorry we aren’t going to either make netflix work properly (I realize they probably developed their own channel) or reopen what we turned off in V2 hardware so I can at least get to developing a driver for another product. Personally, I’m in a different position than Phil/Pirey4 as I can release a v1 driver and a v2 driver if you got the /keypress command working properly for grid based channels like netflix but what makes the most sense is reopening the legacy controls.
“pirey4” wrote:
Will either the /keypress commands that don’t work in the Netflix channel on both the Roku 2 and Roku 1 be fixed or will the legacy telnet commands be fixed on the Roku 2?I’d like to have my ECP application work uniformly on both the Roku 1 and Roku 2.
If you fix the /keypress commands the Netflix channel, will these fixes be rolled out to the Roku 1 and Roku 2 simultaneously? If the fixes aren’t rolled out simultaneously, is there any way for an ECP app to tell what version of firmware a particular box is running? Without this, I won’t be able to migrate until it is rolled out for both platforms since this would break Roku 1 users.
Thanks,
phil
I can’t help with most of your questions, but you can at least tell what model number a box is (which at least tells you if it’s a 1 or a 2) via ECP. If you pull and parse the xml from http://ROKU_IP:8060/ you get something like this, which has modelName/modelNumber nodes :
<root xmlns="urn:schemas-upnp-org:device-1-0" xmlns:ms="urn:microsoft-com:wmc-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device ms:X_MS_SupportsWMDRM="true">
<dlna:X_DLNADOC xmlns:dlna="urn:schemas-dlna-org:device-1-0">DMP-1.00</dlna:X_DLNADOC>
<deviceType>urn:schemas-upnp-org:device:MediaRenderer:1</deviceType>
<friendlyName>Roku Streaming Player</friendlyName>
<manufacturer>Roku</manufacturer>
<manufacturerURL>http://www.roku.com/</manufacturerURL>
<modelDescription>Roku Streaming Player Network Media</modelDescription>
<modelName>Roku Streaming Player 3050X</modelName>
<modelNumber>3050X</modelNumber>
<modelURL>http://www.roku.com/</modelURL>
<serialNumber>ABC14R000XYZ</serialNumber>
<UDN>uuid:7F248787-B5DF-4C7B-8C9A-00DDEABCXYZ</UDN>
<UPC/>
<serviceList>
<service>
<serviceType>urn:schemas-upnp-org:service:RenderingControl:1</serviceType>
<serviceId>urn:upnp-org:serviceId:RenderingControl</serviceId>
<SCPDURL>/RenderCtl.xml</SCPDURL>
<controlURL>/UD/?0</controlURL>
<eventSubURL>/?0</eventSubURL>
</service>
<service>
<serviceType>urn:schemas-upnp-org:service:ConnectionManager:1</serviceType>
<serviceId>urn:upnp-org:serviceId:ConnectionManager</serviceId>
<SCPDURL>/ConnMgr.xml</SCPDURL>
<controlURL>/UD/?1</controlURL>
<eventSubURL>/?1</eventSubURL>
</service>
<service>
<serviceType>urn:schemas-upnp-org:service:AVTransport:1</serviceType>
<serviceId>urn:upnp-org:serviceId:AVTransport</serviceId>
<SCPDURL>/AvTransport.xml</SCPDURL>
<controlURL>/UD/?2</controlURL>
<eventSubURL>/?2</eventSubURL>
</service>
<service>
<serviceType>urn:roku-com:service:ecp:1</serviceType>
<serviceId>urn:roku-com:serviceId:ecp1.0</serviceId>
<controlURL/>
<eventSubURL/>
<SCPDURL>ecp_SCPD.xml</SCPDURL>
</service>
</serviceList>
<presentationURL>/</presentationURL>
</device>
</root>
I’d probably check the modelNumber against a list of Roku1 models, and if it doesn’t appear, assume it’s a roku2. I don’t think we’ll get any more roku1 models, but there may be new roku2 models at some point, so this should make it somewhat future-proof.
“pirey4” wrote:
Will either the /keypress commands that don’t work in the Netflix channel on both the Roku 2 and Roku 1 be fixed or will the legacy telnet commands be fixed on the Roku 2?I’d like to have my ECP application work uniformly on both the Roku 1 and Roku 2.
Isn’t the use of /keydown followed by /keyup after delay a suitable alternative?
“EnTerr” wrote:
“pirey4” wrote:
Will either the /keypress commands that don’t work in the Netflix channel on both the Roku 2 and Roku 1 be fixed or will the legacy telnet commands be fixed on the Roku 2?I’d like to have my ECP application work uniformly on both the Roku 1 and Roku 2.
Isn’t the use of /keydown followed by /keyup after delay a suitable alternative?
If you want to reliably move a specified number of times in a particular direction, it is very difficult to do with /keydown and /keyup. For example, if you want to move exactly 42 titles to the right, how do you time the /keydown and /keyup sequences to do this? I put a lot of effort into trying to find a way to use the /keydown and /keyup but was unable to use these commands with reliable results.
Thanks,
phil
“pirey4” wrote:
“EnTerr” wrote:
Isn’t the use of /keydown followed by /keyup after delay a suitable alternative?
If you want to reliably move a specified number of times in a particular direction, it is very difficult to do with /keydown and /keyup. For example, if you want to move exactly 42 titles to the right, how do you time the /keydown and /keyup sequences to do this? I put a lot of effort into trying to find a way to use the /keydown and /keyup but was unable to use these commands with reliable results.
Ah yes. I hear you loud and clear. Unfortunately Roku doesn’t.
I remember testing scrolling (5x and 1x) on Netflix on queue of ~200 to scroll to a position and back and noted how unreliable it is. I tried different delays and in 10-20% of the cases it will not return to the exact same place it started. I am guessing the queue loop drops messages (overflow?). And since there is no way to inquire where in the queue current position is, that leads to bad UI experience.
I have asked for a queue-grid-goto(Y,X) kind of ECP command for Netflix channel in particular with not much of a response on that.
viewtopic.php?f=34&t=39386&start=15#p262557
“EnTerr” wrote:
“pirey4” wrote:
“EnTerr” wrote:
Isn’t the use of /keydown followed by /keyup after delay a suitable alternative?
If you want to reliably move a specified number of times in a particular direction, it is very difficult to do with /keydown and /keyup. For example, if you want to move exactly 42 titles to the right, how do you time the /keydown and /keyup sequences to do this? I put a lot of effort into trying to find a way to use the /keydown and /keyup but was unable to use these commands with reliable results.Ah yes. I hear you loud and clear. Unfortunately Roku doesn’t.
I remember testing scrolling (5x and 1x) on Netflix on queue of ~200 to scroll to a position and back and noted how unreliable it is. I tried different delays and in 10-20% of the cases it will not return to the exact same place it started. I am guessing the queue loop drops messages (overflow?). And since there is no way to inquire where in the queue current position is, that leads to bad UI experience.
I have asked for a queue-grid-goto(Y,X) kind of ECP command for Netflix channel in particular with not much of a response on that.
viewtopic.php?f=34&t=39386&start=15#p262557
A queue-grid-goto(Y,X) ECP command would definitely provide the functionality I need.
In the absence of this proposed command, I achieved reliable performance on the Roku 1 by stringing together sequences of legacy “press left”, “press right”, “press up”, “press down” telnet commands since the “equivalent” commands documented in the Roku External Control Guide (/keypress/Left, /keypress/Right, /keypress/Fwd, /keypress/Rev) do not work on the Netflix channel. Unfortunately, these legacy commands no longer work on the Roku 2 (as well as the /keypress/Left, /keypress/Right, /keypress/Up, /keypress/Rev commands on the Netflix channel).
Consequently, my External Control Protocol application (DVPRemote), has less functionality when used with the Roku 2 than when used with the Roku 1.
For telnet commands, try using only the first letter (e.g., press r) on the R2s. Works for me.
-JT
“renojim” wrote:
For telnet commands, try using only the first letter (e.g., press r) on the R2s. Works for me.-JT
Thank you! What you recommended appears to work.
I did a little experimentation and found that concatenated single letter commands also appear to work on the Roku 2 but don’t work on the Roku 1. For example, “press lllllrrrrr” goes left 5 posters and then right 5 posters which is where you started from. Assuming this was supported capability, it would actually be useful if it was provided on the Roku 1 as well.
I’d still like to see the /keypress commands fixed on the Netflix channel on both the Roku 1 and Roku 2 so that I could use only documented/supported ECP features in my ECP app.
