Developing SceneGraph app - bricked 2 boxes

Up to 4 bricked boxes now!

I can hard factory reset the 3s but the 4 doesn't have a button so I don't think I can do that.

Also I'd prefer not having to set everything up again everytime - so if anybody has any ideas why I'd really appreciate it!

Thanks again.

The Roku 4 does have a button on the bottom, in the Rubber area, near the front, it should say "Reset" on it. Can you private message me a dropbox or other link to download a zip that reproduces the problem?

Thanks,

- Joel

Hey Joel - thanks for pointing that out! At least it's not bricked.

I've got the issue in a git stash - I'll fire you over a zip shortly.

Thanks again!

Ry.

I've had this happen on 2 different Roku 4 boxes and a Roku 4K Insignia TV, with 2 different channel codebases (most recently 1 week ago). The same package works fine after the hard reset, so I don't think its tied to a particular command or code structure. I had just assumed having to do a full reset was part of using a fairly new SDK.

I've also reverted back to using the web interface to install scenegraph zips to the device. I've noticed using my previous command line tools ("make install") occasionally results in some odd behavior where not all the xml files seem to be loaded.

I just had the exact same thing happen to my Sharp Roku TV. It happened while uploading the channel, not while the channel was running, so I don't think it's related to the channel itself. I've also been working on this channel for a couple months now without issue, so it seems it's something new.

I'm currently waiting for all of my channels to re-install after a factory reset to get it back up and running. I'll update if it happens again...

Ok, update...

It's definitely the channel that's causing the issue, and it occurs during the compile. I was able to narrow it down to two different builds, three minutes apart.. one works, the other locks up the Roku indefinitely (even after reboot), until a factory reset is done. The culprit appears to be, what I'm guessing is some sort of recursive loop that's triggered by including the same BRS file in a component that extends another component that already includes that BRS file. Removing the redundant include fixed the issue for me. Why it persists after reboot is beyond me...

For illustration purposes, in pseudo-xml/code...
BaseTask.xml

<?xml version="1.0" encoding="UTF-8"?>
<component name="BaseTask" extends="Task">
    <script type="text/brightscript" uri="pkg:/components/utilities.brs" />
</component>

ExtendedTask.xml

<?xml version="1.0" encoding="UTF-8"?>
<component name="ExtendedTask" extends="BaseTask">
    <!-- REDUNDANT INCLUDE -->
    <script type="text/brightscript" uri="pkg:/components/utilities.brs" />
</component>

I don't know if this is restricted to Tasks, as it was in my case, or if it could even be triggered by the same file being included multiple times in the same component (i.e., duplicated <script> tag), but I've already lost a couple of hours trying to track this down, and I don't care to go through the whole factory reset thing yet again, so I'll let someone else test that... 😉

UPDATE: Ok, my curiosity got the better of me. I can confirm that it happens with non-Task components as well. It does not, however, happen if the redundant <script> include is in the same file... only if it's in an extended component.

Most amusing!
I'd be inclined to think infinite loop during compilation exhausts free disk space / trashes the FS. Except how does the above cause loopiness?

Nice tracking down!

I like the fact you couldn't resist trashing another box 🙂

Thanks guys!

Ry.