Hi,
I’m new to Scene Graph XML, there’s a problem in my current app, that when I quit app by back / home button, sometimes the device will freeze. I have added some solution to remove page components and unobserve interface field before quit. It helps a little when I quit app by back button, but the home button still makes device freeze.
Someone could me on this? Thanks in advance!
I’m still facing the same problem. Someone could help me?
It seems to me that the scene graph thread is not closing correctly. As I create a video node inside xml, and when I press home button to quit app, I can still hear the song playing even in Roku home page. What’s a good way to release memory for scene graph xml?
The problem is solved. I noticed there are many circular references in my app and they make troubles to release memory when app quit. After removing circular references, everything is charming.
How strange. It shouldn’t matter, the “orphaned objects (objects in a circular ref loop)” message is just a diagnostic, nothing bad with it.
Any particular thread that happens with? Or idea how many circ.refs?
Our SG app development is running into similar issues - pressing Home does not clear the memory. Often I can hear audio continuing indefinitely while staring at the Roku Home screen or even ater launching another app.
“joetesta” wrote:
Our SG app development is running into similar issues - pressing Home does not clear the memory. Often I can hear audio continuing indefinitely while staring at the Roku Home screen or even ater launching another app.
I ran into this same issue and tracked it down to having a reference to the video node in the global node.
“TheEndless” wrote:
I ran into this same issue and tracked it down to having a reference to the video node in the global node.
What would be a working hypotenuse here… that the global Noid survives and persists past app exit?
“the global Noid survives and persists past app exit”
From experimentation done with “free” command on port 8080 it seems that this is the case (Global Node is not removed from memory by pressing Home button, or sideloading a new zip)
“joetesta” wrote:
From experimentation done with “free” command on port 8080 it seems that this is the case (Global Node is not removed from memory by pressing Home button, or sideloading a new zip)
How does “free” help you here, it just shows amount of free disk space, see https://forums.roku.com/viewtopic.php?f … 30#p457961
“free” shows the amount of memory consumed, not disk (i assume we don’t need to discuss the difference). After exiting an app, the result of the “free” command should appear similar to the result before the app was launched. However, this is not the case with the SG app I’m trying to debug.
Unless you’re saying Roku caches app data and persists that cache after app exit? The fact the box crashes implies it’s running out of memory and the results from “free” seem to support that hypothesis. If we exit the app cleanly and delete everything while doing so (ie an “exit” feature in the app, not the Home button on remote) then “free” shows our memory has indeed been “freed”
App running: >free
total used free shared buffers cached
Mem: 379304 332052 47252 0 36084 155244
-/+ buffers/cache: 140724 238580
Swap: 0 0 0
App exited “cleanly”>free
total used free shared buffers cached
Mem: 379304 266916 112388 0 36208 94540
-/+ buffers/cache: 136168 243136
Swap: 0 0 0
App running again>free
total used free shared buffers cached
Mem: 379304 358948 20356 0 36208 154240
-/+ buffers/cache: 168500 210804
Swap: 0 0 0
App exited with Home button>free
total used free shared buffers cached
Mem: 379304 353996 25308 0 36208 155788
-/+ buffers/cache: 162000 217304
Swap: 0 0 0
Far as I can tell, the only way to get that memory back is power cycling the roku 
“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.
“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
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?
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
Oh… “One more thing!” 
- 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).
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
“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
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.
“tar” wrote:
It appears that m.global survives after Home button is pressed, and we need a way to avoid that.
I doubt thatm.globalsurvives 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.
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
