Roku Developer Program

[EnTerr]

Background: I remember requesting this in the past but have not heard any comment back. It took me a while to dig it down and in retrospect i realize my suggestions often come in side note form. Yet here it is, almost three years ago:

"EnTerr" wrote:
It will be best if this can be incorporated in ECP and when received as particular http request passed as message in the event loop in the way isRemoteKeyPressed() is (new isEcpRequest()?) together will additional path and parameters. The only twist remains how to send back data for the http response. It's so simple to implement i would sort of expect it to show in the next SDK release 🙂

And one more thing remaining is figuring out what's the current channel on Roku (as to know what queries it can handle if any). That in analogy to "query/apps" and "query/icon" will be something like "query/channel" and simply return ID of the running channel (e.g. "12" for Netflix)

The former part materialized as ECP command /input by the end of 2011 (either fw 3.0 or 4.1 - ECP doc and release notes differ on that). And i don't think there is way to do the latter part yet. So i decided to write it down as an only request and even give it pompously a formal designation as in the PEPs (Python Enhancement Proposals) and since this ain't no Python, "REP" it is.

REP NB1: Implement ECP "/query/channel" to return the current channel#

As simple as that, when ECP client sends http GET /query/channel,

• return the app ID of the channel that player is currently "tuned to". E.g. '12' for Netflix, '15985' for Play-on-Roku, 'dev' for side-loaded etc. No XML nor JSON since there is no other meaningful info to return; quotes used only for readability in previous sentence.


• return '0' when player is in the home screen, '-1' if cannot give clear answer - in particular, if it is in the process of loading a channel (subject to discussion; http status 204/205?; situations: booting? in transition?)


• current behavior: since command is not implemented, return http status 400

Discussion: the purpose of this is to allow external control app to recognize if they can use channel-specific commands (like /input or direct socket connection). /input alone is only part of the picture, since the app does not even know if it is trying to shove the command in the right channel. Imagine audio/video channels eventually adding remote feedback, like sending what's playing title/author/info. So if my remote app checks /query/channel and sees say Pandora is on, it may start using Pandora-specific means of communication. The fact that it tried to launch it with /launch/28 earlier does not mean that channel is still running - someone might have exited already with physical remote or another app or the player might have spontaneously rebooted. Which is awful out-of-sync user experience - but with this help from ECP, it can know now when "/input" is talking to a brick-wall ("air talking").

Security concern: very low. Note all that is returned is the current channel#, it only allows ECP client app to know what's on screen, something that human already sees. It is not expected to return any additional params used during /launch. Thus the privacy inside individual channels is left to their implementors. Also, other vendors already do that - for example DirecTV protocol returns current channel as well as show info (and no, one does not have to authenticate to be able to use their protocol).


I am requesting consideration of this by RokuCo - as well as dev.community voices in support (hopefully).

[greno]

I would also like to see this implemented. I have an Android remote app and a corresponding Roku channel, and one simple benefit here would be that my app could know if my own channel is currently running.

Also, it doesn't seem like this would require any channel coding changes.

-Gregg Reno
Jigawatt Labs

[TheEndless]

I'll go ahead and throw my vote in for this. I don't have an immediate need for it, but I have come across situations in the past where it would have been handy.

[gonzotek]

Due to same-origin policy, Remoku probably wouldn't be able to take advantage of this. Not unless Roku were to relax that policy as requested previously.

Nonetheless, I'd like to throw a +1 support behind EnTerr's proposal, because it could enable a lot of other people's interesting use-cases.

[RokuMarkn]

Hi EnTerr,
First, thanks for a very clear and thoughtful description of exactly what you're asking for. It makes discussion much easier. Don't take the following comments as criticism of the idea, just things that need to be addressed.

1. In general there is not only one "current" channel running. The most obvious example is a screensaver running over another channel. I think there are also a few other corner cases where more than one brightscript context can be running. So this would need to be clarified; for example, to exclude screensavers.

2. This mechanism doesn't completely solve the race condition you mention in your discussion. The box could return that Pandora is running, and then 100 ms later the user could exit with the physical remote and you'd still be air talking. Perhaps a better solution would be to add a parameter to the input command to specify the id of the channel that you believe you're talking to, and to get a specific error code if the wrong one is running.

--Mark

[EnTerr]

Mark - thank you for your attention and shedding light into a corner case:

"RokuMarkn" wrote:
1. In general there is not only one "current" channel running. The most obvious example is a screensaver running over another channel. I think there are also a few other corner cases where more than one brightscript context can be running. So this would need to be clarified; for example, to exclude screensavers.

I could not find conceptual description of how screen savers work on Roku (code example is not documentation), my understanding so far is that the active channel gets paused and screen saver runs until interrupted, is that not the case? In particular i am foggy on what happens if channel Foo is running in regular mode when screen saver kicks-in and the chosen screensaver is Foo as well (i.e. Foo advertised itself as screen saver and was chosen in Settings); is new context spawned - or call is forced within regular Foo - or no saver is called - or crash happens.

But let me do some hand-waving about the intent of /query/channel, perhaps that gives the answer for this and other corner cases: it is expected to return the channel# that is currently having control of the screen and (potentially) is receiving the user input. The one that is active front and center; that "has the focus" in Windows parlance; the "first responder" on Apple NS/Cocoa platform. Whether there are other contexts in the background (suspended/zombies, main menu) does not matter.

The idea is that the ECP client can check what is on screen right now (at very coarse level: channel#) and also know who will get it if sending a button press. If screen saver is on, first input will get consumed and SS terminated, right? So it is useful /query/channel to indicate when screen saver is on. Accordingly, remoting app then may opt not to disrupt player's slumber - or to send "superfluous" keypress to dispense with the S/S and then it can check "the real" channel and send inputs to it. Now what exactly /channel returns during screen saver time may not be important - it might be say fixed "-2" or the screen saver channel number negated (i can't think of why knowing exact SS is useful, if they cannot receive input) - but knowing when is napping matters.

2. This mechanism doesn't completely solve the race condition you mention in your discussion. The box could return that Pandora is running, and then 100 ms later the user could exit with the physical remote and you'd still be air talking. Perhaps a better solution would be to add a parameter to the input command to specify the id of the channel that you believe you're talking to, and to get a specific error code if the wrong one is running.

True, does not completely solve it - but this REP is not trying to address all of /input's issues, of which this is just example. /channel would have multiple uses - for example showing channel-name in title bar (or another, non-obtrusive place) of remoting app; like so (mockup):

automatically popping custom control elements (subject to channel maker volunteering the means, say song name/artist/cover). I have some thoughts related to your idea though but let me open separate thread as not to de-focus.

PS. i just realized that as "free bonus" we'd get a bit improved "accessibility" to the player. Accessibility for disabled people (specifically blind or of low vision). iPhone/iPad have a "VoiceOver" accessibility setting that reads aloud as touching screen elements (and so does Android, it is called "TalkBack" there). Never heard of it? - chances are you have better than 20/70 vision. I had no idea of those settings either but learned there are legally-blind Roku users that use them, more here. Some day RokuCo may be able to put as much effort in accessibility as Apple/Google did - but in the mean time the mobile remote apps can help.

-nas

[pirey4]

I'd like to see this functionality as well. I can definitely see use cases where this would be helpful.

Thanks,

phil

[EnTerr]

I got my hands on Netgear NeoTV (NTV300) today and their app already shows current channel, no muss no fuss:


ps. a smudge: FB extra icons is obnoxious (but oh, joy - does not work)

[RoomieRemote]

Roomie would also like to see this of course.

I would note that at this point we have not seen any real ECP improvements since 2011. There are now many other protocols out there for set tops, some licensed, some open, some heavily secured, some not, but regardless the majority, basically all, provide significantly more than ECP. At the very least, basically everything out there can display things like "I'm playing Amazon Video now, the program playing is called 'Lost, season 2, episode 12', the position is 0:38:12". Further, somewhat fewer but still most allow setting that position to a different place. These kinds of relatively simple features solve real deficiencies in the Roku platform. Obviously a lot of the metadata itself would be up to each app and that's just fine.

Feel free to contact me offline if you'd like far more detail than you likely need. My basic point is that looking at this thread is like saying ECP is now version 1.0.0, and you want ECP 1.0.1 when it is actually 3 years later and time for ECP 4.0.1. So is this a good idea? Sure. But the actual need here is so much greater that spending the time to dev and QA just this seems like a bit of a waste when really a much larger task is warranted that can all be QA'd together.

Thanks.

[RokuJoel]

I doubt our partners (including the developers on this forum) would like people to be able to data mine what their customers are watching on our platform - they could use it to compete against you.

- Joel