Roku Developer Program

[mbrakken]

I made some changes to a channel I'm developing and now I have an intermittent crash and system reboot occurring. I'm still working to isolate the conditions that lead to it, but I have a question about some data I'm receiving right before the crash which I feel may provide some insight.

The code block that I crash from is:

while true
		print "Waiting for message"
		msg = wait(0, m.port)
		print "Got Message:";type(msg)
		if type(msg) = "roGridScreenEvent" then
			print "msg= "; msg.GetMessage() " , index= "; msg.GetIndex(); " data= "; msg.getData()
			if msg.isListItemFocused() then
				print"list item focused: "; msg.GetIndex()
				[do more things]
			end if
			[do more things]
		end if
end while

and the console output looks like:

Waiting for message
Got Message:roGridScreenEvent
msg=  , index=  21 data=  8947853
list item focused:  21
Waiting for message
Connection closed by foreign host.

So I make it through one iteration of the for loop and then crash out.

GetIndex() returns either 20 or 21 in these circumstances, and GetData() returns 8947848, 8947849, 8947853, etc.

Of note, too: I don't have 22 rows on the grid screen. I have 3, at indexes 0 through 2. I suspect I can avoid the crash by handling GetIndex() results that are unexpected (like 21), but I'm wondering why I'm getting a message with these index and data values and what they might mean.

Additionally, I just noticed that I don't always crash after receiving these index/data values, I just crash most of the time.

I appreciate any insight. Thanks.

[TheEndless]

I think we'd need some more information to help isolate the issue. Can you share the code that initializes the grid screen? Has the grid fully populated when you get this crash? Also, what model Roku are you testing on? That bizarre getData() value is reminiscent of an old 3.x firmware issue with the grid screen, so if you're using a legacy Roku, that's important information.

[mbrakken]

I'm working on a Roku 3, model 4200X running 5.6 build 60.

The crash occurs after I go back to the grid screen and try to update it based on some conditions.

I've just narrowed the crash down to a call to

screen.setListVisible(int, bool)

When I comment out that one line, everything is fine. Also, when I call that in the debug console, the first event message I get back matches the index and data values that precede the crash (although I don't crash when I call them in the console).

Interestingly, the crash seems to occur when either:
1) I enter the channel, sign in, and my collection comes back empty and so the row is hidden: screen.setListVisible(2, false)
2) I enter the channel already authenticated with an empty collection (so I hide the row via screen.setListVisible(2, false) before calling screen.Show() without a crash), navigate to a poster screen for an object, add it to my collection, and then go back to the initial grid screen. When the row switches from not visible to visible I crash: screen.setListVisible(2, true)

It does not crash if I already have something in my collection (the row is visible), add a new object, and go back to the grid screen, even though the same code runs when I go back as it does for case #2 above. Presumably, this is because I'm not changing the visibility of the row when I call screen.setListVisible(2, true).

So it seems like the crash occurs when I make a call to screen.setListVisible() while I'm inside the event listen loop ( eg. after I call screen.Show() ) and it changes the visibility of the row. I'm wondering if there's a render race that's happening and it chokes, since the crash occurs while images are trying to render. I'm going to try changing the order of some things and see if that has an affect.

[TheEndless]

That crash sounds vaguely familiar. One thing you could do to work around it is set the initial content list to a single "loading" item, so the list is never empty. If you have data, you just replace the content list, and if not, you hide it.

And before EnTerr calls me on it, this is definitely a bug that Roku should fix. I'm only suggesting a workaround as a stop gap... 😉

[mbrakken]

Ech. I realized I deleted some contextual information. In case it's not evident, if someone is logged in to the channel there's a content row ("Your Collection") on the main grid screen that I hide or show based on whether it's empty or not. There are user actions that can add things to that row, for which I update visibility if it goes from empty to not empty.

[TheEndless]

"mbrakken" wrote:
Ech. I realized I deleted some contextual information. In case it's not evident, if someone is logged in to the channel there's a content row ("Your Collection") on the main grid screen that I hide or show based on whether it's empty or not. There are user actions that can add things to that row, for which I update visibility if it goes from empty to not empty.

I assumed as much. My suggestion is to always have content in the row before you show or hide it. If you have no content, then call SetContentList() with a single element array with a dummy "Loading" item in it.

That being said, though, are you calling SetListVisible(2, True) before or after you update the row's contents with the new Collection items? You may try swapping the two calls to see if that addresses the crash.

[mbrakken]

Thanks for helping me out, @TheEndless.

"TheEndless" wrote:
My suggestion is to always have content in the row before you show or hide it. If you have no content, then call SetContentList() with a single element array with a dummy "Loading" item in it.

That being said, though, are you calling SetListVisible(2, True) before or after you update the row's contents with the new Collection items? You may try swapping the two calls to see if that addresses the crash.

Unfortunately, I've tried both of these to no avail, at least not consistently. So far, the only thing that seems to keep the system from crashing/rebooting is putting in

if msg.GetIndex() >= 20
	sleep(5000)
end if

to slow things down when these events occur. I may see how short of a delay works (500ms was too short to prevent a crash), but obviously this is not an ideal solution.

Unfortunately, I think I need to resort to rebuilding the screen if the number of rows needs to change. In theory, show/hide presents a better user experience since it wouldn't interrupt their browsing experience, but a screen rebuild is better than a system reboot...

Is there a way to file a bug report on this? This crash makes gridscreen.setListVisible() pretty much useless, at least in this circumstance.

[TheEndless]

I know it doesn't help you, but I've used the grid screen in countless channels without running into this behavior (other than one vague recollection of something similar), including when showing/hiding rows, so I'm inclined to say that there's something different in the way you're working with the screen that's triggering it. Can you produce a simpler example that reproduces it that you can share? That'd be the best way to a) get it into Roku's queue for a bug fix, and b) see if we can come up with a workaround that doesn't require you to sleep.

[mbrakken]

Sure. I'll stub out a 2 screen channel that [I hope] reproduces the problem and post it here. Thanks.

[renojim]

I recall getting GetData() and/or GetIndex() results from a grid screen isListItemFocused() message that are wildly out of bounds, but I didn't do any investigating to see what causes it. I just bounds check the results and do nothing if the results make no sense.

-JT