Roku Developer Program

[RokuMarkn]

You can probably get a rough idea by creating a text file containing all your keys and values and run it through gzip. The actual amount of compression is highly dependent on the data, so if you store different values at different times (as you certainly would for a game), the size will vary. A very safe approach would be to limit your uncompressed data to 16K.

--Mark

[destruk]

16k per dev id...so if you have more than one game with the same devid - be extra cautious... but I think you know that Komag. 🙂

[EnTerr]

"RokuMarkn" wrote:
Well, it's a little complicated. [...] the whole thing is zlib compressed before storing it, and it's the compressed file that is limited to 16K. This makes it rather difficult to predict exactly how much space you will be using ...

RokuMarkn - Is this also the case with `persist`?
In my tests seems any persist_quota < 68 is ignored ("ask and you shall receive... default quota") - but which is worse, any change (increase or decrease) in larger values causes the storage content to be lost.

Which behavior is a horrible thing because how do you explain to a user that their saved game levels were be lost during app update? Moreover, there is no way to warn them not to update (channel updates are automatic). And can't take evasive action because by the time the new version is running, the old persist is gone :cry:

[Komag]

So from testing I found a couple things:

6000 keys of all the same 8 characters compresses from about 96KB down to under 16KB, but 8000 doesn't. This is silly though as they are all the same, easy targets for compression, and unrealistic.

3000 keys of all different 4 characters compresses from about 34KB down to under 16KB, but 4000 doesn't. This is closer to reality with the different keys, but still might be quite a ways off since they were all written and flushed at the same time and were sequential and are the same length.

Interestingly, I tested 20,000 keys of 8 characters and it works between sessions (user can exit channel to Home, load another channel, exit that channel, and restart my channel, and all the keys load up just fine. But a power cycle of the Roku box loses all the info, as though it was never flushed.

[RokuMarkn]

"EnTerr" wrote:

RokuMarkn - Is this also the case with `persist`?
In my tests seems any persist_quota < 68 is ignored ("ask and you shall receive... default quota") - but which is worse, any change (increase or decrease) in larger values causes the storage content to be lost.

Yes, 64K is the smallest possible persist filesystem, so smaller numbers are taken to mean 64K.

But it's not supposed to lose content if you change the persist size. It's supposed to create a new filesystem of the requested size, copy the files from the old one to the new one, and delete the old one. I haven't tested it but that's what the code says.

--Mark

[Komag]

I searched for "persist" but couldn't find a thing - is it something for Roku or just computer programming in general?

[RokuMarkn]

Persist is an NDK feature. Is that what you're referring to EnTerr?

--Mark

[EnTerr]

"RokuMarkn" wrote:
Yes, 64K is the smallest possible persist filesystem, so smaller numbers are taken to mean 64K.

Per my tests, the actual cut-off is persist_quota=67 vs 68 for some odd reason and the maximum file size under the default quota is 35840 bytes but that's small beer -

But it's not supposed to lose content if you change the persist size. It's supposed to create a new filesystem of the requested size, copy the files from the old one to the new one, and delete the old one. I haven't tested it but that's what the code says.

Unfortunately it does not do what it's supposed to. ANY change in the filesystem allocation leads to content loss; be it from default to custom (>67) quota or back, be it increase or decrease in the custom quota. I would have expected at least increase in the quota to preserve the content and decrease to preserve it if the actual content fit in the smaller quota but no - the contents gets lost. Boom! - and your save levels are toast and the app thinks this is brand new install. I am very sure of it, i did a meticulous, exhaustive testing (over 50 tests, will PM spreadsheet of the results).

I ran into this "feature" first couple of months ago, when i decided to be modest and decrease the persist_quota=16384 which Marmalade plants by default*. The reason i asked above if persist gets zlib compressed like the registry - the reason being that if it doesn't get squeezed somehow, a Roku is losing 16MB flash per Marmalade game. Which given the total of 256MB flash means some horrible things will start happening when a dozen (possibly half a dozen) Marmaladen games are installed. I can't know what things exactly but know when memory is low, things don't go well...

(*) To quote an obscure philosopher, "Ohh, marmalade!"

[Komag]

Question (for RokuMarkn?)

Does one character = 1 byte?

So if I have a half dozen registry sections, each with a single key whole value is a large string, can I simply check the length of my strings, add them up, add in a few more bytes for the various registry headers, and know pretty close how many bytes I'm using (before compression)?

[RokuMarkn]

Assuming you're using ASCII characters, one char equals one byte. Strings are stored as UTF-8, so if you're using non-ASCII chars it's more complicated.

--Mark