self-rebooting roku's

"jbrave" wrote:
There's a bunch of users raisin' a rukus about their Roku boxes rebooting. On its own, mine does, once in a while, for no obvious reason, however, I'm becoming a firm believer that most if not all of more frequent spontanious reboots of Roku boxes that occur on a more frequent basis are almost 100% related to print statements in the code that print to the console. Tracking down the spot where my app causes the roku to reboot has led to a print statement, every single time. Now the code itself may be in some way responsible - but whatever conditions are created within the roku environment by the code, its the print statements that "break the camels back" as it were, causing the box to reboot. Printing URL's seems to be the major cause. It isn't predictable ahead of time that any given print statement will cause a reboot, but ones that do cause a reboot every time.

So, I'm thinkin': dev's , just pull all your print statements from the production version of your app before publishing, your app might be much more stable.

- Joel

Have you ever been able to reduce the problem that causes the reboot to a small channel that just does what's required to get it to reboot? If you can post something up here that's reproducible I'd like to take a look. We've been able to crash the box multiple different ways (trying to hand a WAV to roAudioPlayer, too many AudioPlayer instances of less than a second in length started in succession (testing), iterating without calling reset() first (fixed), etc.), but I don't believe with a print statement.

Also, since print statements aren't shown unless it's a side-loaded channel, it brings up the question of how they disable them? Do they just not show the STDOUT, or are they mapping the print function to a NOP?

Well, it would be out of the context of the surrounding code and data structures, so I don't know how much it would help, I actually did post a slightly sanitized version of it last time I mentioned this topic. I essentially track reboots down by putting a print statement on every line in the area where the reboot happens. The last one to actually print gives me an idea what the line is.


?m.api+"/tracks.xml"+m.ckey+"&limit="+lim.tostr()+"&offset="+ofs.tostr()+"&order=hotness"

printing this will usually cause a reboot. So instead I print:
"/tracks.xml"+m.ckey+"&limit="+lim.tostr()+"&offset="+ofs.tostr()+"&order=hotness"

Without the http://api.servername.com printing, there is no reboot.

More from the same function, note the commented out line in red - that's where another 100% repeatable reboot occured (which is why it is commented out )

m.url=m.api+"/tracks.xml"+m.ckey+"&limit="+lim.tostr()+"&offset="+ofs.tostr()+"&order=hotness"
' ?"/tracks.xml"+m.ckey+"&limit="+lim.tostr()+"&offset="+ofs.tostr()+"&order=hotness"
? "set m.urlxfer"
m.xfer.setURL(m.url)
? "set m.xferresult"
m.xferResult= m.xfer.GetToString()
'?now 'printthe result, actually don't because this will kill the roku"
'print"transfer-result"+m.xferResult

edit - more last night I posted this thread because I was attempting to make changes to the m.url line and when I duplicated the changes to the ? "/tracks.xml..." line - without the http:// - I got a reboot.

"kbenson" wrote:
Also, since print statements aren't shown unless it's a side-loaded channel, it brings up the question of how they disable them? Do they just not show the STDOUT, or are they mapping the print function to a NOP?

RokuKevin has said that excessive prints can slow down a published channel, so they must do something.

-JT