Roku Developer Program

[EnTerr]

"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

[TheEndless]

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

[greubel]

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

[greubel]

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

[EnTerr]

"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.

[greubel]

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

[TheEndless]

"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.

[greubel]

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

[TheEndless]

"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.. 😛

[greubel]

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.