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.