6.1 roGridScreen issues

In the new firmware, on flat-movie, show() needs to be called after SetupLists and SetListinames and setcontentlist, but before setfocusedlistitem, otherwise setfocusedlistitem is ignored/doesn't work.
As for the not loading until the row is selected, I'd guess they are being loaded, just not displayed - because they are displayed faster when the row is moved to than they were before.

"destruk" wrote:
In the new firmware, on flat-movie, show() needs to be called after SetupLists and SetListinames and setcontentlist, but before setfocusedlistitem, otherwise setfocusedlistitem is ignored/doesn't work.
As for the not loading until the row is selected, I'd guess they are being loaded, just not displayed - because they are displayed faster when the row is moved to than they were before.

Thanks for the response. This isn't great news for me. My app relies on being able to call setFocusedListItem while the screen is being displayed. Otherwise the UI becomes inconsistent. I don't suppose there's any way to work around this new limitation?

On the second point, I agree they are definately being loaded offscreen and just not rendered until selected. But this is a horrible regression... It results in the screen being largely empty. It also appears that when the row is initially selected, the horizontal scroll position is not the default, and it 'jumps' to the selected item. Overall, the user experience is made significantly worse by these issues.

Perhaps someone from Roku can comment on these regressions?

Note: I'm seeing this behaviour on at least "flat-16x9", "flat-movie", and "flat-portrait". Although, "flat-portrait" seems to still draw loading posters, so the grid isn't empty from the start. Seems there's some inconsistency here.

"Rek" wrote:
This isn't great news for me. My app relies on being able to call setFocusedListItem while the screen is being displayed. Otherwise the UI becomes inconsistent. I don't suppose there's any way to work around this new limitation?

Why can't you call SetFocusedListItem() immediately after you call Show()?

"Rek" wrote:
On the second point, I agree they are definately being loaded offscreen and just not rendered until selected. But this is a horrible regression...

I'm not seeing this behavior at all. Can you provide an example of the content-metadata you're providing to the screen? Maybe there's something in the way you have it defined that's causing the behavior you describe...
Are you seeing it on other grid screen based channels? If not, then that's further indication that it could be something specific to your code.

"TheEndless" wrote:

Why can't you call SetFocusedListItem() immediately after you call Show()?

I call setFocusedListItem() after calling show() when the screen is initially opened. This is intended to set the default selection, and used to work fine. I also call setFocusedListItem() during the screen's lifetime in certain instances. For example, if the user navigates to an item on the grid, a springboard is presented with a "Delete" option. If the selected item is deleted by the user, then the springboard is closed, I must remove the deleted item from the grid, and select another instead.

I also use the first row of the grid as sort options. So, if the grid data must be reloaded, I am forced to call screen.setupLists(rowCount) and re-create each row. After this happens, I need to ensure the first row has the correct sort option selected.

"TheEndless" wrote:

Are you seeing it on other grid screen based channels?

I am seeing the image snapping behaviour on SNAGFILMS and PLEX. I have not clearly seen setFocusedListItem() fail on other channels, but it's hard to notice since I'm not 100% sure when it's supposed to be called in those channels.

"Rek" wrote:
I call setFocusedListItem() after calling show() when the screen is initially opened

Gotcha. Destruk's suggestion was to make sure you were calling it after show, and you said that wasn't great news for you, so I assumed you were calling it before.

I believe I may have just seen what you're describing, but it's completely random for me (happened 4 out of 10 times trying to reproduce it), and it's only the first row that didn't load. I start focus on the second row on this particular flat-16x9 grid, so that could be why. I can also only get it to happen in this particular channel, while I have a lot more grid screen channels that don't exhibit it. It also only seems to be happening on my Roku 3. I can't reproduce it on the other boxes.

"TheEndless" wrote:

"Rek" wrote:
I call setFocusedListItem() after calling show() when the screen is initially opened

Gotcha. Destruk's suggestion was to make sure you were calling it after show, and you said that wasn't great news for you, so I assumed you were calling it before.

I believe I may have just seen what you're describing, but it's completely random for me (happened 4 out of 10 times trying to reproduce it), and it's only the first row that didn't load. I start focus on the second row on this particular flat-16x9 grid, so that could be why. I can also only get it to happen in this particular channel, while I have a lot more grid screen channels that don't exhibit it. It also only seems to be happening on my Roku 3. I can't reproduce it on the other boxes.

I'm seeing it on a Roku 3 as well (will test on a Roku 2 later today). The images not being displayed is consistent for me. They don't show up until the row they are in is focused. However, setFocusedListItem() appears to fail randomly for me -- each time the screen opens, I call screen.setFocusedListItem(0, 3). Sometimes it works, but most of the time it selects the last item in the row. I've also seen it select the first one in the row.

Have you been able to reproduce the setFocusedListItem() error? Can someone from Roku verify if this is a firmware issue?

Update: Neither of these issues appears on the Roku 2. It looks like its a Roku 3 related problem.

"Rek" wrote:
Have you been able to reproduce the setFocusedListItem() error? Can someone from Roku verify if this is a firmware issue?

Update: Neither of these issues appears on the Roku 2. It looks like its a Roku 3 related problem.

I think a good example of the setFocusedListItem() bug is the WatchESPN channel. While I don't know for sure what the code does, I know it used to set each row's focus to the first item while now it's completely random as you go down the rows on a Roku 3 (haven't tested a Roku 2 XS). I see the same behavior on my own SomaFM channel where I know the focus is set to the first item in each row. It has a very sparse grid and exhibits other strange behavior as you go down the rows that is probably related to this bug.

-JT

Depending on how long it takes your channel to load the thumbnails, you might need to include a sleep(250) or so after Show but before setfocusedlistitem().
ie - loading from my local LAN, I don't need sleep, but loading from my internet webserver I do because of latency.

After the upgrade I noticed the same issue with my channels, in my experience this looks like a "side effect" of an improvement done in the code. Possibly with the late fetch of the cover images.

Joel, any comments from the developer team ?

"destruk" wrote:
Depending on how long it takes your channel to load the thumbnails, you might need to include a sleep(250) or so after Show but before setfocusedlistitem().
ie - loading from my local LAN, I don't need sleep, but loading from my internet webserver I do because of latency.

Thanks for that, it looks like the sleep has resolved the issue. Images are still 'popping' in, but at least the channel is functional. Cheers!