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 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.
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:
I enter the channel, sign in, and my collection comes back empty and so the row is hidden: screen.setListVisible(2, false)
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.
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…
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.
“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.
“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.
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.
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.
Are you using a mixed-aspect-ratio grid? If so, I can confirm that it can crash/reboot the roku in the right conditions. It was always related to m.SetVisibility(index, boolean).
“malort” wrote:
Are you using a mixed-aspect-ratio grid? If so, I can confirm that it can crash/reboot the roku in the right conditions. It was always related to m.SetVisibility(index, boolean).
Yeah, I probably should have stated that up top; I forgot that the mixed-aspect-ratio grid particularly particular.
I woke up this morning thinking that may be the problem, and sure enough. When I just changed it to a flat-movie grid, it behaves without issue.
With the m-a-r grid, updating row visibility triggers an roGridScreenEvent (isListItemFocused, with the out of band index and data values), while updating visibility on the flat-movie grid doesn’t trigger any events.
@malort , did you find a way around the crash, or did you abandon the m-a-r grid?
“renojim” wrote:
I just bounds check the results and do nothing if the results make no sense.
Yeah, I was isolating these results, but still had the crash.
Also @TheEndless , sorry I haven’t gotten some sample code together. I spent last evening refactoring and haven’t finished throwing together the example. I suspect now that any mixed-aspect grid will replicate, but still want to test that with a simple example.
I did not find any clean workaround. I did find that stacking a screen on top before toggling visibility could help, but obviously that is not clean at all.
This was in my notes and it’s crazy
stack a new screen on top ( dialog or another gridscreen )
set the visible row to false ( or opposite hidden to visible )
sleep 500ms
set list item focused to a row that is invalid, I.E. row 999, index 0
I should also not, that I believe I was able to still reboot the roku randomly, even including the crazy steps above. The only foolproof way to not reboot the roku, is to use placeholders for empty rows (never hide), again, not optimal.
“malort” wrote:
Are you using a mixed-aspect-ratio grid? If so, I can confirm that it can crash/reboot the roku in the right conditions. It was always related to m.SetVisibility(index, boolean).
Yeah, I probably should have stated that up top; I forgot that the mixed-aspect-ratio grid particularly particular.
I woke up this morning thinking that may be the problem, and sure enough. When I just changed it to a flat-movie grid, it behaves without issue.
With the m-a-r grid, updating row visibility triggers an roGridScreenEvent (isListItemFocused, with the out of band index and data values), while updating visibility on the flat-movie grid doesn’t trigger any events.
@malort, did you find a way around the crash, or did you abandon the m-a-r grid?
“renojim” wrote:
I just bounds check the results and do nothing if the results make no sense.
Yeah, I was isolating these results, but still had the crash.
Also @TheEndless, sorry I haven’t gotten some sample code together. I spent last evening refactoring and haven’t finished throwing together the example. I suspect now that any mixed-aspect grid will replicate, but still want to test that with a simple example.
Gah. I think I figured out my problem, and now I feel silly…
Since I’m using mixed-aspect-ratio grid, I need to call screen.SetDescriptionVisible(bool) on every isListItemFocused focused event. I thought I was capturing these strange values to keep setDescription from being called, but apparently I wasn’t. There isn’t a thing to set a description visible on, so boom.
if msg.isListItemFocused() then
print"list item focused | current show = "; msg.GetIndex()
' changing mixed rows causes the description (BoB) to be hidden
screen.SetDescriptionVisible(true)
to
if msg.isListItemFocused() then
print"list item focused | current show = "; msg.GetIndex()
if msg.GetIndex() >= 20 AND msg.getData() > 80000
print "strange message"
else
' changing mixed rows causes the description (BoB) to be hidden
screen.SetDescriptionVisible(true)
should fix it. It did for my channel, at least.
I feel like I have egg on my face. Thanks @TheEndless , @renojim , and @malort for your time. Lessons learned.
FWIW, I just ran into this exact same issue on a different gridscreen type (flat-16x9), on a channel that has worked fine for years. The crazy item index event seems to be a new introduction in the 6.1 firmware, and only seems to happen on the Roku 3.
