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: 
EnTerr
Roku Guru

Re: Bandwidth

"RokuMarkn" wrote:
The video player has a fixed size buffer, about 50-60 MB depending on the firmware and model. It keeps the buffer as full as possible to avoid rebuffering during brief network outages or slowdowns.
"RokuMarkn" wrote:
Note that it must have been a very low bandwidth stream to play from the buffer for 10 minutes. 60 MB divided by 10 minutes is 800 kbps.

Given the file stats now, 875 MB / 110 min = ~8 MB/min.
Greubel says 10 minutes was real and not subjective time.
x10 mins = 80 MB were buffered

That's 20MB more* than maximum expected.
Which seems to show there is a problem with buffering on 2XS (maybe all 3xxx models) where this crash occurs?

(*) 20MB might be nothing to a video buffer but is a lot to app developer: if it shrinks allowable tmp/ from 30MB to 10MB, that is 3x less
0 Kudos
TheEndless
Channel Surfer

Re: Bandwidth

Have you tried issuing the "free" command via port 8080? Does that give you anything worthwhile?

Example:
             total       used       free     shared    buffers     cached
Mem: 264084 242572 21512 0 27492 110660
-/+ buffers/cache: 104420 159664
Swap: 0 0 0
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
0 Kudos
greubel
Visitor

Re: Bandwidth

Doesn't work from a Mac but here is what I got from Windows.
This is while the movie was playing at the start.


total used free shared buffers cached
Mem: 178832 170580 8252 0 2660 30512
-/+ buffers/cache: 137408 41424
Swap: 0 0 0


Update after 10 minutes

total used free shared buffers cached
Mem: 178832 169560 9272 0 1404 29328
-/+ buffers/cache: 138828 40004
Swap: 0 0 0
0 Kudos
greubel
Visitor

Re: Bandwidth

What does this mean ?

My Channel

total used free shared buffers cached
Mem: 178832 170356 8476 0 3196 29700
-/+ buffers/cache: 137460 41372
Swap: 0 0 0


RMP

RMP
total used free shared buffers cached
Mem: 178832 170476 8356 0 12180 25628
-/+ buffers/cache: 132668 46164
Swap: 0 0 0
0 Kudos
EnTerr
Roku Guru

Re: Bandwidth

"greubel" wrote:
What does this mean ?

That's the output of linux `free` util. Most relevant part is that you have 41 MB free to peruse which should be way, way enough and far from system crash. But let's see what an expert (MarkN) has to say.

See also:
"http://serverfault.com/a/85481/105576" wrote:

... The second line gives first line values adjusted... These are often more meaningful than those of first line.
... Just a short version: Linux (like most modern OS) will always try to use free RAM for caching stuff, so Mem: free will almost always be very low. Therefore the line -/+ buffers/cache: is shown, because it shows how much memory is free when ignoring caches; caches will be freed automatically if memory gets scarce, so they do not really matter. A Linux system is really low on memory if the free value in -/+ buffers/cache: line gets low.
0 Kudos
greubel
Visitor

Re: Bandwidth

The movie is appearing to take about 80m and we have 40m remaining.
What could be causing the thrashing ? Could it be the way memory is allocated ?
I have everything defined as objects under "m" to make them global. How big is a page size ?

Personally I think holding about 10% of the movie in memory is a little too much !
Comments ... Suggestions !


my channel rmp
used free used free
before 56476 122356 45200 133632
during 137396 41436 134096 44736
movie 80920 88896
0 Kudos
TheEndless
Channel Surfer

Re: Bandwidth

"greubel" wrote:
What could be causing the thrashing ?

Are you just assuming it's "thrashing" or do you have hard evidence that suggests that's the problem? If the "free" output is to be believed, it would seem memory probably isn't the issue (at least not in this sense.. see below).

One other thing to consider, that "free" isn't accounting for, is video/graphics memory. Do you have and 2D elements on screen or in memory during this (e.g., roScreen, roBitmap, etc.)? If you're overrunning the decoder buffer with 2D graphics, things can get sketchy really fast, resulting in issues ranging from simply black bitmaps displaying, to excessive buffering, to complete meltdown and reboot. If you do have 2D elements in memory, what's the output of r2d2_bitmaps when you run into this problem? I've found anything under 25 megabytes of "Available memory" (as reported by r2d2_bitmaps) will result in instability across the board when the roVideoPlayer is playing. It's particularly noticeable on the previous gen Roku 2 XD and XS, and to a slightly lesser extent on the HDMI streaming stick.
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
0 Kudos
greubel
Visitor

Re: Bandwidth

The video becomes jerky, it freezes, starts back, video breakup, audio falls off and eventually it crashes.

I'm not using roScreen or roBitmaps or and 2D graphics.
Should the command r2d2_bitmaps work if your not using roScreen ?
Only using these objects:

roArray = 225
roAudioPlayer = 1
roImageCanvas = 4
roSystemLog = 1
roAudioResource = 3
roDatagramSocket = 6
roSocketEvent = 4
roMessagePort = 3
roBoolean = 93
String = 863
roInvalid = 15
roInt = 6
roVideoScreenEvent = 1
roAssociativeArray = 336
roDeviceInfo = 1
roVideoScreen = 1
Integer = 6
roTimespan = 1
roInteger = 643
roString = 599
roInput = 1
roFilesystem = 1
roFontRegistry = 1
roFunction = 17
roByteArray = 15
roStreamSocket = 3
Invalid = 17
0 Kudos
TheEndless
Channel Surfer

Re: Bandwidth

"greubel" wrote:
The video becomes jerky, it freezes, starts back, video breakup, audio falls off and eventually it crashes.

Ahh. By thrashing, I thought you were referring to the memory i/o discussed earlier in the thread.

"greubel" wrote:
Should the command r2d2_bitmaps work if your not using roScreen ?

r2d2_bitmaps will still work (on FW 5.x+), but I can't imagine its output is relevant if you're not using any of the 2D components. That wouldn't explain it working when you capped the bandwidth anyway, so nevermind on that one all around.. 😛
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
0 Kudos
greubel
Visitor

Re: Bandwidth

First, Thanks for all the help !

I've been trying for the last week to put some sort of rational around the problem. I wrote a minimal application that would allocate memory and temp space in 1 meg blocks and then try and play a video. These are the limits I came up with on the different platforms I have. These numbers are approximated because I can't really come up with an exact allocation. From this you can see why the 3100x has problems, it has a playback limit 20 meg less than a Roku or Roku 1.

I wish the memory and temp files were separate but they are allocated out of the same memory pool. So you allocate from one and the space is removed from the other. Also it appears that the video handler with buffers takes over 80 Meg. I did try the Roku 3 with a mix of 100 meg on tmp:/ and 100 meg of memory and that worked fine but you go much over on either one and the video falters and fails.


To find the max limits, I just kept allocating until the file write failed or in the case of memory, Roku crashed.

Tmp:/ and Memory Limits

* File Space
Max tmp:/ Video Plays but anything > and Video becomes unstable or Roku Crashes
N1000 100,000,000 57,000,000
2100x 100,000,000 52,000,000
3100x 86,000,000 33,000,000
4100x 193,000,000 193,000,000

* Memory
Max Allocate
N1000 142,000,000 53,000,000
2100x 139,000,000 52,000,000
3100x 125,000,000 33,000,000
4100x 334,000,000 220,000,000

To fix my problem, I had to optimize some code, change a lot of arrays that were allocated with a static size to dynamic and remove a couple of test elements to get the package size down.

But still, I don't think the video player needs 10 minutes worth of data.
Also why are we caching a memory only device ? Like moving data from your right hand to the left, what's the point ? That's also wasting a lot of data space for cache blocks.
0 Kudos