Roku Developer Program

[EnTerr]

"joetesta" wrote:
"free" shows the amount of memory consumed, not disk (i assume we don't need to discuss the difference).

Doh! My bad, what was i thinking?! Probably because buffers/cache (RAM) and /tmp (also RAM) are mangled in my head...

So... perhaps some threads survive Home button? This is odd, i ass-umed all threads' interpreters are shutdown on (whatever) app exit.

[joetesta]

"EnTerr" wrote:
Doh! My bad, what was i thinking?! Probably because buffers/cache (RAM) and /tmp (also RAM) are mangled in my head...

So... perhaps some threads survive Home button? This is odd, i ass-umed all threads' interpreters are shutdown on (whatever) app exit.

No worries, I appreciate your replies! 🙂
Seems the global node is left around if not explicitly removed

[EnTerr]

I find it more useful to look at the 2nd line, where used/free are corrected by discounting buffers/cache (which are linux-managed beyond "rOS" app executor's control). Notice how neatly used+free = 379304 in all cases, unlike with the top line:

App running:       used   free
-/+ buffers/cache: 140724 238580

exited "cleanly":  used   free
-/+ buffers/cache: 136168 243136

App running again: used   free
-/+ buffers/cache: 168500 210804

exited with Home:  used   free
-/+ buffers/cache: 162000 217304

So the 1st exit freed 4556 KB, where the 2nd freed 6500 KB. Seems the opposite of what hypothesized?

[joetesta]

relatively, the numbers freed on those lines seems insignificant. If we're to go off those, this isn't a useful tool for troubleshooting the crashes. The numbers on the top line seem to trend with device crashes, but I allow that I could be imagining it.
Another factoid,
In the case where the device exits cleanly, the videoplayer works upon next launch.
In the case where the home button is pressed, invariably the videoplayer will fail on next launch

[EnTerr]

Oh... "One more thing!" 8-) - i believe /tmp is tucked under "cached". Looking at it:

App running:>                 cached 155244
App exited "cleanly">         cached  94540
App running again>            cached 154240
App exited with Home button>  cached 155788

The first exit freed 61 MB, while the second released... nada (or worse, "-1.5mb" but nvm the trifle).

[joetesta]

where do we go from here?
I believe the problem is that the app is using Global Node for storing large json and parsed results, as well as referencing video player.
Trying to figure out how we might change it so that it doesn't use Global Node; how can the data be shared across threads? In the documentation I read about "thread rendezvous" https://sdkdocs.roku.com/display/sdkdoc/Scene+Graph+Threads but trying to figure out how it's implemented or if there's a working example...?

It's interesting that there is no mention or word of caution about the issues Global Node causes in SG development; https://sdkdocs.roku.com/display/sdkdoc ... lobalScope

[EnTerr]

"joetesta" wrote:
where do we go from here?

Perhaps if @RokuMarkN drops by the thread, he can shed some light - he seems to know the storage mgmt corner well and has been most helpful on the subject in the past.

I believe the problem is that the app is using Global Node for storing large json and parsed results, as well as referencing video player.

My gut feeling is this is a bug in the current implementation, which is easy for the Co. to fix and will be. Some-such like /tmp files not being deleted on one kind of exit - whereas being deleted in the other case. Probably shouldn't sweat it for the long term.

Trying to figure out how we might change it so that it doesn't use Global Node; how can the data be shared across threads? In the documentation I read about "thread rendezvous" https://sdkdocs.roku.com/display/sdkdoc/Scene+Graph+Threads but trying to figure out how it's implemented or if there's a working example...?

Oh, that. That rat-hole - the darkest, scariest corner of rSG i am aware about. The randezvous is how Noid fields are implemented, not something you can explicitly use. Not sure it's fixable ever. When you grok the consequences, let me know if i am right to be afraid 🙂

[tar]

Hello everyone, I have similar problem described here https://forums.roku.com/viewtopic.php?f=34&t=96090
It appears that m.global survives after Home button is pressed, and we need a way to avoid that.

[EnTerr]

"tar" wrote:
It appears that m.global survives after Home button is pressed, and we need a way to avoid that.

I doubt that `m.global` survives Home exit.

Why don't you test it? Set a variable Foo="bar" in m.global and after Home exit and on next start of your app check what the value of Foo is - if m.global persists, the value from the 1st run will be there.

[joetesta]

I think tar is right.  The variables are not available on next app launch but they are also not released from memory (cache?).  either way, pressing home does not fully release the memory (or whatever you want to call it) that was used by global node, leading to big problems, such as video component will never work again until box is rebooted, or box will just reboot itself without warning.  As you said EnTerr, 

a bug in the current implementation, which is easy for the Co. to fix and will be