Roku Developer Program

[kbenson]

Ooh, that really turns up the creep factor. 🙂 I can see the people with entertainment systems on but TV's off occasionally hearing faint talking in the house because the volume is low, and having no idea where it could be coming from...

[TheEndless]

"destruk" wrote:
I was under the impression if the screensaver turned on, processing of the channel code would be paused

Nope. The screensaver runs in a completely different thread, so channel execution continues. It's actually important that it does, otherwise, in a lot of circumstances, you'd have to write custom idle handling code into your channel, which could get extremely messy (think of an audio application that stopped receiving progress updates when the screensaver kicked in... yikes!).

[RokuMarkn]

"kbenson" wrote:
Ooh, that really turns up the creep factor. 🙂 I can see the people with entertainment systems on but TV's off occasionally hearing faint talking in the house because the volume is low, and having no idea where it could be coming from...

Related story: In the early days of ReplayTV, one of our major investors was testing a unit at his house. He turned off the ReplayTV unit but left the TV on. Late at night the ReplayTV woke up and started recording a show, which caused it to start blaring the show's audio through the TV. The guy woke up, heard voices, thought someone had broken into his house, and called the police.

--Mark

[destruk]

"TheEndless" wrote:

"destruk" wrote:
I was under the impression if the screensaver turned on, processing of the channel code would be paused

Nope. The screensaver runs in a completely different thread, so channel execution continues. It's actually important that it does, otherwise, in a lot of circumstances, you'd have to write custom idle handling code into your channel, which could get extremely messy (think of an audio application that stopped receiving progress updates when the screensaver kicked in... yikes!).

So a custom screensaver will need to be required since the secondary screensaver thread eats the msg input button press of the remote too. Thanks again. If you play a video file with a silence audio track included behind the current displayed screen it prevents the screensaver from activating to begin with - it takes more bandwidth to constantly stream something that isn't seen but it seems like another solution to consider.

[kbenson]

"RokuMarkn" wrote:

"kbenson" wrote:
Ooh, that really turns up the creep factor. 🙂 I can see the people with entertainment systems on but TV's off occasionally hearing faint talking in the house because the volume is low, and having no idea where it could be coming from...

Related story: In the early days of ReplayTV, one of our major investors was testing a unit at his house. He turned off the ReplayTV unit but left the TV on. Late at night the ReplayTV woke up and started recording a show, which caused it to start blaring the show's audio through the TV. The guy woke up, heard voices, thought someone had broken into his house, and called the police.

Ha!

"destruk" wrote:

So a custom screensaver will need to be required since the secondary screensaver thread eats the msg input button press of the remote too. Thanks again. If you play a video file with a silence audio track included behind the current displayed screen it prevents the screensaver from activating to begin with - it takes more bandwidth to constantly stream something that isn't seen but it seems like another solution to consider.

If you had to go that route, you could download the audio to tmp:/ once and play from there as much as needed. That said, I don't think preventing the screensaver is the best solution, and Roku may have an issue with a channel doing that.

[TheEndless]

"kbenson" wrote:

"destruk" wrote:

So a custom screensaver will need to be required since the secondary screensaver thread eats the msg input button press of the remote too. Thanks again. If you play a video file with a silence audio track included behind the current displayed screen it prevents the screensaver from activating to begin with - it takes more bandwidth to constantly stream something that isn't seen but it seems like another solution to consider.

If you had to go that route, you could download the audio to tmp:/ once and play from there as much as needed. That said, I don't think preventing the screensaver is the best solution, and Roku may have an issue with a channel doing that.

I agree. It makes much more sense to me to have your linking screen only poll for a certain amount of time than it does to keep the Roku awake.

"destruk" wrote:
the secondary screensaver thread eats the msg input button press of the remote too

What do you mean by that? The screensaver only eats the first button pressed, in order to cancel itself. What exactly is the issue you're trying to solve? I have a feeling we're just not understanding exactly what the motivation is behind what you're trying to accomplish.

[destruk]

It's annoying that if you press a button just as the screensaver activates, you need to press the same button again to get it to do what you want it to do. Disabling the screensaver shouldn't eat the button press - it should remain in the buffer and given to the app to increase responsiveness. Would creating a custom screensaver routine be able to pass the keypress to the rest of the app?

[kbenson]

"destruk" wrote:
It's annoying that if you press a button just as the screensaver activates, you need to press the same button again to get it to do what you want it to do. Disabling the screensaver shouldn't eat the button press - it should remain in the buffer and given to the app to increase responsiveness. Would creating a custom screensaver routine be able to pass the keypress to the rest of the app?

Only with a lot of error prone shenanigans. I'm sure the screensaver eating the button is by design. Otherwise there would be side effects to exiting the screen saver. If the screensaver started before someone had selected a somewhat important function (such as to pay for the movie rental on amazon, or to purchase a channel), I would be somewhat annoyed if it was accepted without me being able to see what it was beforehand (because the screensaver was running).

As a general rule of thumb, a button/key press should never have an action that can alters the state of an application without you being able to see the state before the press. Anything else just leads to PO'd people.

[gentijo]

So I am not sure I get this.
Is Roku involved in the transaction of registering a device to a web site, or is the complete
transaction between my site and the device. From what I can see, its just the Roku Device
and the 3rd party site where the protocol supposed to be..

Roku Device Contacts 3rd party web site to get code
3rd party site gens random code
Roku Device displays code and stores in registry

User goes to 3rd party site, logs in and enters code to account.
Device is now linked.

On subsequent access, Roku Device supplies code to 3rd party side, access is granted.

Is the XML have any other meaning than just being an example how a device should
communicate with a 3rd party web site ?

Are there any mechanisms perfered to encrypt the code so the plain text code
is not transmitted ??

Thank You
John Gentilin

[RokuKevin]

You are correct that the communication is just between your channel on the box and your website.

You also have good sense to think that you should protect that communication. SSL provides sufficient protection for most. Some channels add authentication of client certs as well as outlined here:

viewtopic.php?f=34&t=27562&start=0


--Kevin