Roku Developer Program

[greubel]

Would it be possible to add a couple of things to the SDK ?
1. On the search screen, leave the button focus where it is ? Would save a lot of user movement.
2. Really need more info on the device, IP address and connection status.
3. More remote control, some sort of intercept before it gets to the players.

[greubel]

Another thing that would be really nice is if the Roku would cache an image after it renders it. I've seen where someone has a real large cover.jpg that slows down the springboard movement to 20 seconds before a select takes place and another 20 seconds to get off the selection. All this is size and crop time.

Or maybe the SDK could provide a method that we could render the image to a size, rotate it and we could save it.

But that brings up another question, how much storage is available to the channel ?

[kbenson]

"greubel" wrote:
But that brings up another question, how much storage is available to the channel ?

I've tested using tmp:/ to store data, and gotten as much as 92 MB saved before it crashed.

[RokuKevin]

All good ideas....

1. The use case for saving typing is to remember recent searches with the roSearchHistory component. Are you suggesting also being able to initialize the search text box?
2. You can get the box device info via the roDeviceInfo object. Why would you need the box's ipaddr? You can test out connections, valid urls, etc... via the roUrlTransfer.Head() method.
3. We've mentioned before in this forum that a more complete remote API is in the works.

We do cache the images for our screens. However, it is important to size your images correctly. Large images take significant processor and memory resources to scale on our small box. Your channels will be much more responsive if you deliver the native image sizes for our different screens. All of these sizes are published in the component reference.

--Kevin

[TheEndless]

"RokuKevin" wrote:
2. You can get the box device info via the roDeviceInfo object. Why would you need the box's ipaddr? You can test out connections, valid urls, etc... via the roUrlTransfer.Head() method.

I can't speak for gruebel's needs, but my app requires a transcoding server to be located on the user's network, and I'd really like to be able to scan their network for that server, instead of requiring the user to know the IP and port for it. Knowing the local IP would give me an initial subnet to use for the scanning.

[greubel]

1. The use case for saving typing is to remember recent searches with the roSearchHistory component. Are you suggesting also being able to initialize the search text box?

No, the request is, after the user clicks on a button/key to leave the focus on that button/key.
I changed the behavior of the ClearButton to be a scroll key and when you click it the focus goes back to "a".

2. You can get the box device info via the roDeviceInfo object. Why would you need the box's ipaddr? You can test out connections, valid urls, etc... via the roUrlTransfer.Head() method.

I have code to scan for a server but it would be nice to know the network address to set the starting point.

My channel has no content. The "user" provides images for album art and I have no control over what he does. If there is a large image, it takes "seconds" to switch between objects.

[greubel]

Instead of the Roku loading and caching a large image and then rendering it, why not cache the rendered version ?

Going through a spring board, the image is first loaded as a unfocused object (15 sec), then as a focused ( another 15 sec) and then to defocus it ( another 15 sec). Makes for slow click response.

[EmJayBee83]

"TheEndless" wrote:

I can't speak for gruebel's needs, but my app requires a transcoding server to be located on the user's network, and I'd really like to be able to scan their network for that server, instead of requiring the user to know the IP and port for it. Knowing the local IP would give me an initial subnet to use for the scanning.

For the purposes of local auto-discovery it would be much simpler (and better), IMHO, if the Roku DVP supported the roDatagramSender() and roDatagramReceiver() objects that Bright Sign supports.

There are so many things nice consumer-friendly things that could be done if there was an effective means of doing local service auto-discovery.