Roku Developer Program

[RokuMarkn]

There isn't a useful way to measure free space in tmp. Generally when the system gets low on memory, it gets slower and slower (paging increases) until it's so slow as to be unusable and/or triggers the watchdog. However, one thing to note is if your channel is not playing video, all the memory used for the video buffer is available for tmp. This is over 50 MB on all platforms.

--Mark

[NewManLiving]

"RokuMarkn" wrote:
. However, one thing to note is if your channel is not playing video, all the memory used for the video buffer is available for tmp. This is over 50 MB on all platforms.
--Mark

That is very useful information Mark - Thank you much. To be clear though, does the number of channels that the user has impact temp, and Is there any way to know how much is used to buffer the video when it is playing

Thank you again

[TheEndless]

"NewManLiving" wrote:
I have not looked at roFileSystem yet but you probably have. There must be a better way to determine space in the temp. Have you investigated the file system component for this purpose?

I actually have a download cache object that I use to track any data I save to tmp. When it has cached nn MBs of data (I default to 10), I trim it back to 1/2 nn using a crude LRU mechanism.

[RokuMarkn]

"NewManLiving" wrote:
To be clear though, does the number of channels that the user has impact temp, and Is there any way to know how much is used to buffer the video when it is playing

The number of installed channels has very little effect on the memory available to tmp.
There isn't really any way to determine how much memory is used by the video player.

--Mark

[NewManLiving]

"NewManLiving" wrote:
all the memory used for the video buffer is available for tmp. This is over 50 MB on all platforms.
--Mark

Thanks again Mark, that is very encouraging. Just one more clarification since I'm tired and have a very bad habit of not reading posts entirely in the first round and coming to the wrong conclusion. In the quote above does this mean that the video buffer memory of 50 mb is made available to tmp which would increase the actual size of temp, or that temp itself maxes out at approx 50 mb without the video buffer, which of course if a video was playing would decrease the 50 mb

Thanks again this has been a great help

[NewManLiving]

"TheEndless" wrote:
I actually have a download cache object that I use to track any data I save to tmp. When it has cached nn MBs of data (I default to 10), I trim it back to 1/2 nn using a crude LRU mechanism

Thank you TheEndless I also use the tmp for a cache but without having any idea of how the firmware uses it and how much I really have, my cache management system is quite tempered. Mark's information has helped tremendously. At least I have some idea of how much I can use and when not to use it

[RokuMarkn]

"NewManLiving" wrote:
In the quote above does this mean that the video buffer memory of 50 mb is made available to tmp which would increase the actual size of temp, or that temp itself maxes out at approx 50 mb without the video buffer, which of course if a video was playing would decrease the 50 mb

I mean the former. That is, tmp and the video buffer use the same pool of memory. So when video starts playing, >50 MB of space is no longer available for tmp space. Conversely, when video is not playing, that >50 MB is available for tmp.

--Mark

[NewManLiving]

Thank you that tells me all I need to know

[EnTerr]

"RokuJoel" wrote:
If you plan to wrap around each end of the grid, you'll need a mechanism to do that. This might help:

Regarding list wrap-around, there is formulaic way of normalizing the value:

idx = idx - 1   ' or +1, as case may be
idx = (idx + N) mod N

where N is your list.count(). Bonus points: it wraps correctly if step != 1, as the case might be with << and >> jumping 5 or 10 entries to the side.

[NewManLiving]

"EnTerr" wrote:

"RokuJoel" wrote:
If you plan to wrap around each end of the grid, you'll need a mechanism to do that. This might help:

Regarding list wrap-around, there is formulaic way of normalizing the value:

idx = idx - 1 ' or +1, as case may be
idx = (idx + N) mod N

where N is your list.count(). Bonus points: it wraps correctly if step != 1, as the case might be with << and >> jumping 5 or 10 entries to the side.

EnTerr - I was hoping you would join in with that big math brain of yours. Now don't stop there. Just keep those formulas coming and I will try every one of them

Thanks for your input