Roku Developer Program

Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
EnTerr
Roku Guru

Re: Scene Graph XML: quit app by home button freeze the device

"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.
0 Kudos
joetesta
Roku Guru

Re: Scene Graph XML: quit app by home button freeze the device

"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
aspiring
0 Kudos
EnTerr
Roku Guru

Re: Scene Graph XML: quit app by home button freeze the device

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?
0 Kudos
joetesta
Roku Guru

Re: Scene Graph XML: quit app by home button freeze the device

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
aspiring
0 Kudos
EnTerr
Roku Guru

Re: Scene Graph XML: quit app by home button freeze the device

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).
0 Kudos
joetesta
Roku Guru

Re: Scene Graph XML: quit app by home button freeze the device

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
aspiring
0 Kudos
EnTerr
Roku Guru

Re: Scene Graph XML: quit app by home button freeze the device

"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 🙂
0 Kudos
tar
Visitor

Re: Scene Graph XML: quit app by home button freeze the device

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.
0 Kudos
EnTerr
Roku Guru

Re: Scene Graph XML: quit app by home button freeze the device

"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.
0 Kudos
joetesta
Roku Guru

Re: Scene Graph XML: quit app by home button freeze the device

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
aspiring
0 Kudos