I have an application for live streaming using roVideoScreen.
After powering Roku and starting the application live streams start almost instant, but after a couple of opening/closing the video screen the buffer time increases dramatically.
It also happens with other Roku applications.
What could be the problem?
We are seeing the same exact problem. The video stream goes from starting almost instantly to as long as 20 to 30 seconds. After a reboot of the Roku box it starts instantly again.
Can someone please help.
You can use the debug screen to check the network bandwidth that your unit is detecting. Perhaps what’s happening is initially after a reboot it thinks your network is fast but after some use it recalculates it as a slower speed that takes longer prebuffering time.
–Mark
Debug bandwidth settings screen:
Bitrate Debug Info on screen: Home 5x, Rew 3x, FF 2x
Note that there is currently a bug that makes it not interact with HLS streams properly.
–Kevin
“RokuKevin” wrote:
Debug bandwidth settings screen:
Bitrate Debug Info on screen: Home 5x, Rew 3x, FF 2xNote that there is currently a bug that makes it not interact with HLS streams properly.
–Kevin
So does this mean that this behavior I am seeing is normal due to the bug ?
No. My post was just telling you how to get to the bandwidth screen that RokuMark was referring to. I also wanted to let you know that the bandwidth screen does not currently interact with StreamFormat=“hls” streams…
The bandwidth screen should help you measure the bandwidth your box is seeing, which may be cause of the longer buffer time you are seeing.
–Kevin
We are testing with the roku box hooked up to the same network that the streaming server is on. This behaviour happens no matter how much bandwidth it has. Also the behaviour always repeats. When you restart the roku you get very fast video start times, then after a few times that you play some live streams, it slows down drastically. We will do the testing with the debug however I do not think it is a available bandwidth issue.
We have done some testing in debug. Below are our findings. As you can see it is clear that there is something going on that is not due to network bandwidth going down. As I have specified the stream server and roku are in the same network, and this behavior happens with other channels live streams as well.
Roku
Software: 2.9 - build 1529
Hardware version: model N1101
Serial number : D0D029016644
Network: roku + streaming server
Bandwidth: 100mbps
Speedtest: download → 37222; upload → 39956
Roku with playback debug enabled:
FIRST TESTS ON OUR PRIVATE CHANNEL
Max speed: 10 mbps when powering Roku
The speed decreases in time after playing live streams: 5.6 mbps, 1.2 mbps, 0.8 mbps
If the HLS bandwidth is set to 932 and Roku calculates the network bandwidth lower than 0.9:
Debug message: Cannot play 0.9 mbps stream on your 0.5 → 0.9 mbps network because starting at 5:30 the stream needs 0.7 mbsp in the next 6 seconds (0.9 mbps).
If the HLS bandwidth is set to 640 and Roku calculates the network bandwidth greater than 0.6 (eg: 0.
: the stream plays instantly
OTHER TESTS ON Spacevidcast and OUR CHANNEL
Spacevidcast (live)
19:10 → 10 mbps
19:15 → cannot play 0.8 mbps stream on your 0.6 mbps network because starting at 1:28, the streams needs …
19:16 → 1.1, 1.3 mbps
loading, please wait → makes buffer when playing and stays a lot (more than 5 minutes - it doesn’t start again)
19:22 → cannot play … on your 0.1 mbps network
19:23 → cannot play … on your 0.2 mbps network … 0.3 mbps
19:24 → cannot play … on your 0.4 mbps network
OUR CHANNEL
19:25 → 1mbps → plays instantly
19:30 → 0.7 mbps
19:34 → 1.1 mbps
Starting from a difference of 0.1 mbps between the bandwidth needed by the stream and the network calculated bandwidth the stream stays longer on the buffering phase (eg: 0.6 (or lower) mpbs stream on your 0.7 mbps network)
–reset ROKU –
OUR CHANNEL
19:48 → 10mbps
Spacevidcast
19:48 → 10mbps
19:53 → Cannot play 0.6 mbps on your 0.7 mbps network
19:40 → Cannot play 0.6 mbps on your 0.7 mbps network
19:41 → 0.8 mbps
19:56 → Cannot play 0.3 mbps on your 0.7 mbps network
Conclusions:
When powering/reseting ROKU the speed is 10mbps.
After playing some live streams the speed decreases. When it calculates the network bandwidth as beeing with 0.1 greater than the stream bandwidth, or lower the buffer time is longer.
The network speed eventually increases again and decreases again but not very significantly.
Well, it certainly looks to me like network bandwidth is the issue. Initially Roku thinks the network is 10 mbps because it hasn’t seen any traffic yet. As you start playing, it gradually homes in on the correct speed, which seems to be down below 1 mbps. The long startup times confirm this, since if it were erroneously measuring a low bandwidth which was actually much higher, the stream would start quickly. So the question is why your Roku is getting such low bandwidth from your network.
Is the Roku connected wirelessly? If so perhaps there’s some wifi interference.
–Mark
IT IS NOT THE NETWORK.
This roku box is connected with a wire to our core switch a CIsco 6509.
Our stream server is on the same network.
We have multiple Gigabit fiber pipes to the internet.
It is not the network.
As you saw in our test we did a speed test from a laptop connected to the same switch as the roku box.
This is not a network issue.
Also if i fake set the stream size below what the roku “thinks” the network speed is it starts instantly and never buffers. There is another root cause here.
PS.
I am more then willing to give you a an account on our private channel to test yourselves.
But this is happening with not just our cahnnel, and not just on one roku player.
I will confirm we are seeing the same/like issues.
Whatever methodology has changed in 2.9 is seriously flawed in getting the network speed.
We compared to wired vs wireless, etc. Using a 1.5Mbit stream. It seems the ROKU hard locks on the bitrate of the stream of sorts, where it could actually be grabbing more but remains grabbing at 1.4/1.5Mbit.
We see this more when we introduce “off net”, not local subnet routing. Local subnet routing performs much better. Is their a difference in the code ROKU is using in the TCP stack when the source of the stream is an IP which is local to the subnet the ROKU is on?
I as well can provide access to our server and private channel if you wish to test.
PM me.
Shawn
Like to add some observations, as this is definitely an issue:
Seems the ROKU (as suggested above) sets the “network connection speed” to the speed of the received segment, plus maybe some small amount.
So for example, if you have a stream, that is a live stream, and on the fly transcode, the first segment, will be at a rate that is about the stream bitrate, but less because of the initial delay. Lets say 1Mbit on a 1.5mbit stream. It then proceeds to cap itself around that. Over time watching the network statistics, i see the ROKU, rising a little by little.. say to 1.2mbit, after rebuffering once… then slowly moving upwards to 1.5mbit, some rebuffering and so on. Now, the available data on our server has grown, but the ROKU fails to get it at any faster speed. Which causes excessive rebuffering.
If i do this with a stream which is 100% available, I can slam the ROKU with a chunk of data at 10mbit speed, and it NEVER rebuffers.
Now with bandwidth the way it is, one slow segment, should not cap the ROKU. or their needs to be a better “Recovery” model in the network computation.
Question for ROKU:
Will a DISCONTINUITY TAG in an HLS m3u8, cause the ROKU to abandon it current bandwidth computation, and retry at full speed?
Am I better off serving a 2.5Mbit Commercial Pre-roll from our CDN, to ensure the ROKU believes it has a lot of bandwidth to start?
While these are not solutions, these are questions for work arounds. Being a week or so away from releasing a bunch of stuff for ROKU, we have spent a considerable amount of time working to ensure quality is above and beyond, and with this latest issue, we will not release anything without ensuring we can play content at the best possible conditions and the ROKU needs to be able to access it in the same light..
Shawn
Another note your engineering team should be aware of.
Bandwidth these days is not like having 1 PIPE, and you get whats available in it. More and more technologies in cable plant, wireless, etc utilize on demand channel bonding. Take for instance wireless 4G services (Sprint/Clear network), or Time Warner Cable (Brighthouse). Lets say you have the Turbo package from brighthouse. 40Mbit down, 5Mbit up. They dont have all that opened up to your modem. What they do is have a set portion available, call this the base. As you begin using the bandwidth, channels begin to bond and release as needed (and available). The same holds true for many ISP’s. So your initial download speed (first 20 seconds) may be say 1mbit, increasing to 1.5mbit, then you see a jump to 2.5mbit, and more… Channels are bonding. Once you stop “demanding”, channels release back down to the base.
This does not exists on a local lan, where all the bandwidth exists all the time. So when your dealing with remote content, you have a progressive increase in bandwidth many times, and each time you start up a new request, if some time has passed since the last request, the process is progressive again. Since the roku is locking in at the last segment, your defeating what is actually available.
As I stated above, would be more then happy to work with you directly, give you access to the content, etc whatever is needed to resolve the issue.
Shawn
Ok, I have done some additional playing around.
I have preloaded my HLS stream with 2Mbit, 2 Minute long, HD trailer, served from our CDN, which is quite fast.
In doing this, the ROKU again locks onto the bitrate of the HD trailer which is served to it. So when it transitions to the real media, which is 1.7Mbit, again remotely served, it hovers at 1.8Mbit when downloading the streams.
When I play a local stream (same on being played remotely), it acts entirely different, it talk 10-12Mbit runs at each segment, disregarding the the above performance.
So, my assumption is when playing remote content, it locks onto the bitrate, when it plays local, it takes all it can get, or doesnt bother doing a bandwidth test computation.
So now, my bigger issue, if I am going to have run 2-3Mbit bitrate commercials, just so ROKU can play a 2Mbit stream, the cost becomes absurd…
If I prepend the video with a 400Kbit Preroll, buffering issues…
If I dont prepend the video with any preroll, and just serve the stream @ 1.7Mbit, buffering…
If I prepend the video with a 2Mbit (slightly larger than the actual stream), I get no buffering…
So being all this is done using the SAME network… This is NOT a network issue, it is an issue in which the ROKU is computing the available bandwidth.
Additionally, one would think that when you are done playing a video, ROKU would RESET the bandwidth parameter back to 10Mbit. But it does not, so if I play a 800kbit stream, when I start the next video… It still thinks it only has 800Kbit of network bandwidth, and if the stream is biggerr… long time to load…
How we can we resolve?
Shawn
Here is an important updating after playing around with the TCP and some options.
- Disabled Nagle algorythm on the Server, allowing faster sends
- Increased buffer size to allow for slow Acking on the ROKU for TCP Packets.
Enabling these has fixed the overall speed problem in sending. So I wanted to let the ROKU folks know this, so not chasing a ghost.
BUT - The bug of computed bandwidth lingering after playing a video still exists. Meaning, lets say from within my channel I play a video, and the bandwidth from the source is 1.2Mbit to me. Video finishes, or I exit, then go to play another video, and this other video starts off believing only 1.2Mbit is available. It should reset to 10Mbit after done playing. As this other video is coming from a site which delivers high speed 8mbit to me, but because the ROKU thinks it only has 1.2Mbit, it takles 60-90 seconds to load the 2 minute commercial which is at 2Mbit…
If I reset the ROKU, and start watching the 2nd video first, the commercial starts within seconds.
So point is to the user who posted this, look at the setting on your server serving the stream, as the ROKU controls it TCP Acking very strictly, and if your using that for buffer control as we were and such, you will get only the video stream bitrate, which is not quite actually what you can get if you increase your network buffers.
And, ROKU, can we fix the big so the computed bandwitdh resets before watching new media?
Shawn
You may want to look into the Strategy content meta-data parameter. Our default stream switching strategy did change in v2.9, as we now take into account buffer fullness in addition to measured bandwidth. If you set it to “minimum-adaptation”, your app may use the v2.7 and prior default switching strategy of just using bandwidth and not buffer fullness.
–Kevin
The SwitchingStrategy parameter wasn’t set.
I tried using all the values (minimum-adaptation, full-adaptation, unaligned-segments) but it doesn’t make any difference.
If I may ask, what are you using to SERVE the streams? custom software? commercial web server?
Shawn
Damn!!!
we are having same exact issues and it is not the network
- Cannot play 1.5mbps stream on a 0.8mbps network because at so and so time stream requires 1.1mbps and it buffers.
if the player thinks that it is playing 1.5mbps stream on a 2.1mbps network it shows video super fast under seconds.
The underlying network is 10mbps
How to get rid of this problem easy way ??
can some one please suggest required settings either in APP or where we need to make the changes, this is live telecast.
rebooted roku,
and it shows playing back 1.5mbps stream on 10.0Mbps network. Video shown very fast , almost instant
second step it reduces the bandwidth playing back 1.5mbps stream on a 0.7mbps network
