self-rebooting roku's
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 ...
Forum Discussion
"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?
