I assume you're talking about an HLS stream? There's no debug command to do this, but you can omit some segments from the m3u8 for the high bitrate streams (using a DISCONTINUITY tag) and the player will switch to another stream that does contain that segment.
Thanks, Mark - can you confirm/deny that it will hls bitrates midstream at all, or is it just a best-shot guess at stream startup? I'm not actually seeing it increase at all any more when I throw it in automatic mode.
I have a transparent bridge in between my client lab and the server which artificially introduces a cap onto the bits/second (in half-second bursts) that can flow across the link. It works quite fine when testing the ios devices, QT, and apple's mediastreamvalidator, but I don't have similar luck with the Roku yet when reducing the flow below 1.5mbps.
I'm playing the stream and monitoring the flow with tcpdump to see what the roku is requesting from wowza. In general, it seems to prefer the 1.0Mbps stream and stays put to whatever it requested first. In case it's useful to someone else, the tcpdump statement I'm using on the bridge to match HTTP requests to my server is:
what I see is the roku frequently request (every 10s) most of the children .m3u8 playlists but only retrieve one stream's worth of .ts segments. It tends to start with either the 1000 or 1700kbps streams. If there's insufficient bandwidth to maintain the stream, it will go back to the buffering screen and continue to make requests, skipping some .ts segments instead of switching bitrates to a lower bitrate.
This is with the 2.8 OS installed on a brand new XD.
Any ideas? Am I doing something totally stupid?
 realized all streams are 29.97fps and keyframe-aligned to each other
I am also new with the Roku, but I have seen the same behavior, the Roku seems to select a stream and if there is not enough bandwidth to maintain it, instead of switching to a lower bitrate stream, it will rebuffer the first selected.
I really hope this can be fixed. I am also using Wowza as the server.