Roku Developer Program

[rjune11111]

I've seen messages on this forum claiming that an ECP launch of an already running channel app should re-launch that channel, but on my Roku 2 XS running v4.8 (build 1178), I'm seeing such launch attempts fail, for all channels. The POST gets back a 200 OK response, but the channel does not re-launch, the old invocation remains running (see below). If the channel is not already running, the same POST causes the expected launch to happen.

I can't remember for sure, but I think that re-launch used to work. Could this be a 4.8 regression? Thanks!

Launched Channel Store, scrolled down a few lines, then invoked the following. Channel Store did not re-launch.
$ curl -v -d "" http://192.168.20.111:8060/launch/11
* About to connect() to 192.168.20.111 port 8060 (#0)
* Trying 192.168.20.111...
* connected
* Connected to 192.168.20.111 (192.168.20.111) port 8060 (#0)
> POST /launch/11 HTTP/1.1
> User-Agent: curl/7.24.0 (i686-pc-cygwin) libcurl/7.24.0 OpenSSL/1.0.1c zlib/1.
2.7 libidn/1.22 libssh2/1.4.0
> Host: 192.168.20.111:8060
> Accept: */*
> Content-Length: 0
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 200 OK
< Content-Length: 0
< Server: Roku UPnP/1.0 MiniUPnPd/1.4
<
* Connection #0 to host 192.168.20.111 left intact
* Closing connection #0

[gonzotek]

Confirmed via my web remote Remoku, re-launching fails while channel is running. I'm certain this is a change in behavior from earlier firmware releases.

"rjune11111" wrote:
I've seen messages on this forum claiming that an ECP launch of an already running channel app should re-launch that channel, but on my Roku 2 XS running v4.8 (build 1178), I'm seeing such launch attempts fail, for all channels. The POST gets back a 200 OK response, but the channel does not re-launch, the old invocation remains running (see below). If the channel is not already running, the same POST causes the expected launch to happen.

I can't remember for sure, but I think that re-launch used to work. Could this be a 4.8 regression? Thanks!

Launched Channel Store, scrolled down a few lines, then invoked the following. Channel Store did not re-launch.
$ curl -v -d "" http://192.168.20.111:8060/launch/11
* About to connect() to 192.168.20.111 port 8060 (#0)
* Trying 192.168.20.111...
* connected
* Connected to 192.168.20.111 (192.168.20.111) port 8060 (#0)
> POST /launch/11 HTTP/1.1
> User-Agent: curl/7.24.0 (i686-pc-cygwin) libcurl/7.24.0 OpenSSL/1.0.1c zlib/1.
2.7 libidn/1.22 libssh2/1.4.0
> Host: 192.168.20.111:8060
> Accept: */*
> Content-Length: 0
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 200 OK
< Content-Length: 0
< Server: Roku UPnP/1.0 MiniUPnPd/1.4
<
* Connection #0 to host 192.168.20.111 left intact
* Closing connection #0

[MSGreg]

I can confirm that ECP does launch from the "viewing all channels" home screen, and does not relaunch if already in the same channel using 4.8 Build 1178.

I *believe* it does launch even if a different channel is running.

I don't know what the 4.7 and prior response was.

[RokuKevin]

I've filed a bug.

--Kevin

[rjune11111]

As a workaround to this issue, we have our companion mobile app send a Home key press via ECP prior to sending the launch command. But we've seen some weird effects, like:

1) Sometimes one home key press doesn't work, but sending two consecutive presses prior to sending the launch command does.
2) When sending two presses followed by a launch, sometimes we see our channel start to launch, then we get returned immediately to the Home screen.

Our mobile app is pipelining the two Home key presses and the launch command on the same connection and waiting for the HTTP responses from each post before performing the next. But it seems as though the Roku might be executing some part of the ECP command processing asynchronously in such a way that the commands can actually be executed in a different order from the send order. Can anyone with knowledge of how ECP commands are processed confirm if that is really the case? Thanks!

[gonzotek]

"rjune11111" wrote:
As a workaround to this issue, we have our companion mobile app send a Home key press via ECP prior to sending the launch command. But we've seen some weird effects, like:

1) Sometimes one home key press doesn't work, but sending two consecutive presses prior to sending the launch command does.
2) When sending two presses followed by a launch, sometimes we see our channel start to launch, then we get returned immediately to the Home screen.

Our mobile app is pipelining the two Home key presses and the launch command on the same connection and waiting for the HTTP responses from each post before performing the next. But it seems as though the Roku might be executing some part of the ECP command processing asynchronously in such a way that the commands can actually be executed in a different order from the send order. Can anyone with knowledge of how ECP commands are processed confirm if that is really the case? Thanks!

I can't confirm the possibility of the asynchronous processing, but I can share that one reason two presses of Home may be required is that if a screensaver is running, the first home press only stops the screensaver, requiring the second press to get back to the home screen. Looking forward to a response from Roku about the rest of your question!

[rjune11111]

Thanks gonzotek, I think you're right about the need for two Home key presses.

Another point of reference regarding the out-of-order event processing by the Roku -- it happens more frequently if we're playing media in another channel app (specifically, Pandora) at the time we send the Home/Home/launch sequence. Maybe ECP remote key presses are sent off to one event queue (current channel's?) for asynchronous processing while ECP launch operations are sent off to some unrelated queue, or processed synchronously? Anyway, any insight and/or workarounds from the Roku team would be appreciated, thanks!

[rjune11111]

"rjune11111" wrote:
As a workaround to this issue, we have our companion mobile app send a Home key press via ECP prior to sending the launch command. But we've seen some weird effects, like:

1) Sometimes one home key press doesn't work, but sending two consecutive presses prior to sending the launch command does.
2) When sending two presses followed by a launch, sometimes we see our channel start to launch, then we get returned immediately to the Home screen.

Our mobile app is pipelining the two Home key presses and the launch command on the same connection and waiting for the HTTP responses from each post before performing the next. But it seems as though the Roku might be executing some part of the ECP command processing asynchronously in such a way that the commands can actually be executed in a different order from the send order. Can anyone with knowledge of how ECP commands are processed confirm if that is really the case? Thanks!

Can anyone from Roku comment on the apparent out-of-order ECP command processing? We see this quite a bit and it's a pain, so an understanding of how to make this workaround reliable would be much appreciated.

On a related note, any hints on when a firmware update containing a fix for the original issue might show up would also be a big help. Thanks!!!