Roku Developer Program

Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
renojim
Community Streaming Expert

roSlideShow flawed?

After spending several days going through the examples, analyzing the events that are triggered by the roSlideShow component, and digging through tcpdump logs, I have to question whether the roSlideShow component is flawed.

From my analysis, here's what the slide show component does:
When the slide show is started, requests go out for the first five images in the Content List. The size of the images doesn't seem to matter; it's always five. After the first image is displayed (for 5 seconds in my app), the isPlaybackPosition message is received for the next image, the request goes out for the sixth image, and the isRequestSucceeded message is received when the sixth image has been completed. This all goes along nicely until the final image is received and I assume cached in the Roku DVP. I haven't tried the case of having more images than could fit in the RAM of the Roku, so I can't say what happens at that point. Anyway, at this point the slide show can be paused and the user can manually move forwards and backwards through the slide show and everything just works.

However, here's a different scenario:
It begins like the last one, namely the slide show is started, the requests go out for the first five images, but before the slide show switches to the second image, the user pauses the slide show. Now is where the problem lies. Moving forwards manually works just fine because the Roku DVP has already received those images. But, moving backwards does not work as expected. Let's take the example of 10 images in the slide show. Pausing the slide show on the first image and then pressing the left remote button to go backwards to the 10th image I would think would produce a request from the Roku to the server for the 10th image, but it doesn't happen. The roSlideShow component sends the isRemoteKeyPressed indicating that yes indeed the left remote button was pressed, the isPlaybackPosition is received indicating the new playback position for the 10th image, namely number 9, but that's it. There's never any request sent to the server for the 10th image and obviously there's never any isRequestSucceeded message received for the image.

I'd call that a flaw. Since the app has no way of knowing what has been cached in the Roku, it's not possible to try to manually set the playback position and then wait for the isRequestSucceeded message because if the image is in the cache already the message will never come. Also, mucking with the playback position seems to confuse the component, but that's a topic for another thread.

Comments or suggestions?
-JT
Roku Community Streaming Expert

Help others find this answer and click "Accept as Solution."
If you appreciate my answer, maybe give me a Kudo.

I am not a Roku employee.
0 Kudos
3 REPLIES 3
RokuKevin
Visitor

Re: roSlideShow flawed?

I've confirmed this behavior an opened a bug on it.

--Kevin
0 Kudos
renojim
Community Streaming Expert

Re: roSlideShow flawed?

Thank you! I was going nuts. I thought it was something I was doing wrong.

-JT
Roku Community Streaming Expert

Help others find this answer and click "Accept as Solution."
If you appreciate my answer, maybe give me a Kudo.

I am not a Roku employee.
0 Kudos
destruk
Binge Watcher

Re: roSlideShow flawed?

This bug still exists in 2.9 firmware - for those trigger happy users who press the buttons a whole lot in roSlideshow, it still skips/misses caching images and doesn't update the screen.
0 Kudos