Roku Developer Program

[paps33]

I've been playing around with the /query/icon ECP command and have a few observations and questions...

1) The Content-Length header in the returned response provides the length of the actual "binary" data the icon/image consists of. However, this is not the length of the actual data portion of the roku's response to a query (see #2).

2) The data bytes returned by the roku representing the data for the icon/image are in 'string" form. For example, if some actual hex bytes from the image are 0x8950 the roku data returned is 0x38393530 (ie. 0x38 for "8", 0x39 for "9", 0x35 for "5" and 0x30 for "0"). So, a) more than double (see #4) the data needs to be transmitted/received, and b) the received data needs to be converted before use. Question: Is there a way that the true binary data could be sent?

3)The data bytes returned get received as all part of one message response. However, the data seems to be arbitrarily broken up in to sub-chunks within the whole of the message response data received. At the beginning of the data the string "0x" is inserted. All well and good. But then there may be (and are with many of the images) additional "0x"s inserted at a few arbitrary points throughout the data stream. Since the number and points of insertion are (or seem to be) random it means one must compensate for this when parsing and converting the returned data to usable image data (ie. binary). I got some pretty odd images until I caught this 🙂 . Question: Is the breaking up of the data this way really necessary?

4 Factoring in the above, it seems that if one queries and converts all the images associated with the channels a person has when they have many (or the max) channels it can take a noticeable amount of clock time. A test I ran with 19 channels was a lot slower than I had hoped for, the bulk being consumed by just the query/response transaction with the roku. I had hopes of perhaps getting and using the images for the channels one had in a GUI. Getting just the channel numbers and descriptions is fast. But when I add the image stuff in to the mix the delay is making me rethink this. It would be interesting to see how things might improve if the roku sent back the true image binary data as one complete, interrupted stream.

[renojim]

What are you using to capture the data? I just used netcat to grab a few icons and I don't see any of the behavior you stated. The data was all binary and the length was right on.

I would like to point out a typo in the documentation. The documentation says the command is 'query/icons' and it is really 'query/icon'.

-JT

[RokuMarkn]

I just tested with curl and I also don't see any of this behavior. The response is a binary PNG file and the Content-Length is the length of the binary data. It sounds like whatever set of tools you are using to capture and view the data are converting it to ASCII hex.

--Mark

[paps33]

I'm doing it programatically. I open a socket to the roku, do a send of the request, followed by a recieve of whatever comes back. So I can examine it I then am just writing it out in one shot (the whole response) to a disk file and view it in a hex editor.

[TheEndless]

Could you post the code you're using to retrieve and write the data out to file? It definitely sounds like that's probably where the issue is. You can verify that it works correctly by directly visiting the URL in your web browser (ex. http://<rokuip>:8060/query/icon/12).