Roku Developer Program

[Komag]

What has changed to make my Roku 3 reload everything and give a message saying to get a micro sd card? This just started happening recently

[squirreltown]

It seems to think it's out of channel space right?  Are you developing on this one? Ever since firmware 7.-ish my roku3 is just weird. More often than not it takes two attempts or more to sideload something,  and it's cumulative  - if I reboot the box it behaves normally, but over time it gets worse to the point where sometimes i'll have to use the browser ( normally run a script to sideload ) and it will be saying " not enough space" for a 1 mb .zip. Deleting the channel completely and uploading will work after that but it's clear the Roku is confused - or it's holding on to data and is indeed full. ( I have less than 20 channels and no games)
OR you recently downloaded a game/channel that is much bigger than you might think?

[EnTerr]

I do know of a thing that cripples purple turtles - apologies for sounding like a broken record. But there are likely others - i just don't know them.

I have a general proposal for the Co though:
Make the "Channel Info" discretionary screen (Konami komando HHHUULRLRL) show the amount of storage taken by each app.

Discussion:

• The size number shown should total the sizes of bundle, persist_storage and any other paraphernalia of significance. There is no use of itemizing how much is code and how much data


• Show the size in the same units, so it's easy on the eye to scan the list for offenders to purge. Don't confuse us by flipping between KB and MB, just use KB rounded to a whole or MB rounded to one digit past decimal


• I'd probably prefer said list sorted by size, descending - but maybe there is a reason to remain sorted alphabetically


• Can you add the channel id (number) for each app? To make space, shorten the verbosity of "- Version 4.2 - build 132" (if someone cannot guess what "4.2.132" is, they lack the ability to comprehend that screen in the first place) 

[RokuMarkn]

EnTerr, how would your proposed "size" display work if the app is not loaded?  There are two possibilities, but I see issues with both.

1. Display the actual amount of space that the app is currently using on the box.  But then GiantMegaGame would appear to use only 4K one day and 20 MB the next day.

2. Display the amount of space the app would use when it is downloaded.  I'm not sure we actually have that information, but assuming we do, the number would be fairly meaningless as far as helping the user understand his space usage.

Perhaps what you really want is the amount of space that can't be ejected when the app is unloaded?  This would be somewhat more useful, but harder for the average user to understand.

--Mark

[squirreltown]

Mark, I'd be curious why RokuCo seems to be so tight lipped about all things memory.

R2D2_bitmaps does not appear in the documentation ( OK bad example)
Different models have different amounts of graphix memory, which seems to be pretty arbitrary ( when I was developing on a 2XS, it suddenly had 4 mb more one day because someone decided to change something in the firmware) and:
I cannot ask the box programmatically how much memory the box is using right now.
If a new model is released, and I ask questions here regarding this, the best answer is "buy one and let us know".

[RokuMarkn]

"squirreltown" wrote:
I cannot ask the box programmatically how much memory the box is using right now.

Because the answer would pretty much always be "all of it".  That's how Linux systems work.  Memory gets used until it fills up, then older stuff gets swapped out for newer stuff.  It's pretty hard to represent memory usage with a single number, or even a set of numbers, in such a way that's understandable to someone who isn't intimately familiar with the details of Linux memory management.

But, and this demonstrates some of the confusion that can occur, your question has nothing to do with the topic of this thread.  R2D2 uses RAM.  The SD card dialog appears when the system is low on NVRAM, a completely different kind of memory.

--Mark

[squirreltown]

"RokuMarkn" wrote:


But, and this demonstrates some of the confusion that can occur, your question has nothing to do with the topic of this thread.  R2D2 uses RAM.  The SD card dialog appears when the system is low on NVRAM, a completely different kind of memory.

--Mark

Ok sorry. I do know they are different.

[EnTerr]

"RokuMarkn" wrote:
EnTerr, how would your proposed "size" display work if the app is not loaded?  There are two possibilities, but I see issues with both.
1. Display the actual amount of space that the app is currently using on the box.  But then GiantMegaGame would appear to use only 4K one day and 20 MB the next day.
2. Display the amount of space the app would use when it is downloaded.  I'm not sure we actually have that information, but assuming we do, the number would be fairly meaningless as far as helping the user understand his space usage.
Perhaps what you really want is the amount of space that can't be ejected when the app is unloaded?  This would be somewhat more useful, but harder for the average user to understand.

Doh! "The [pure and simple] truth is rarely pure and never simple" 🙂

Having #1, the "resident" or "locked" storage by the app is the crucial part because when that space is "eaten", it's gone and the only way to free is to delete the app. 

A clue on #2 (as the swappable part?) also seems desirable, since it may affect swapping if e.g. 2 humongous non-resident bundles keep kicking each other out (or one huge can kick dozen smaller etc). But hey, if #1 is readily available and #2 is not, we can start with #1 and deal with #2 later.

My immediate inclination is to display both, say in "resident+non_resident" form (i like how the `+` clearly shows one number does not include the other). Trying to mock it up with entities i know:

Tangrams 1.1.0 (#59088, 0.0+1.8MB)
Agario 1.2.0 (#75560, 0.0+2.0MB)

In this example, neither app has >0.05MB (the round-off) resident - and the bundles are 1.8 and 2.0MB each. I cannot think of a simpler way to represent the situation (the numbers' meaning can be further explained to those who want to know in the forum/blogs; after all this is Konami Komando screen) - but it's akin to locked/wired memory + swappable process memory in the RAM case. 

[EnTerr]

So i checked how "the others" do it. When in doubt - check with the rest. In this case it's a chance to stand on the shoulders of giants. I looked at iOS, Android and Windows (mobile) - and they all readily show both "code" and "data" sizes occupied by each app. Ditto for FireTV/AndroidTV/AppleTV (which are just flavors of the former). "Code" is the bundle and loosely corresponds to our "swappable", where "data" is the non-swappable part. And if even Apple does it, which is someone to look up to re UX... then yeah.

I hope that the Co. can fit 2 numbers, "resident" and "non-resident-but-currently-present". And if not - then the sum of both because that's the immediate concern of the owner - or CSR who has to handle a support call. How much in size is the "non-resident-nor-present-now" (AKA unloaded bundle) - big whoop, whoever wants to see that specific one, make sure to run that very channel and check that value immediately...