Roku Developer Program

[EnTerr]

Seems I discovered a bug in the new 5.4 firmware yesterday. The behavior is that a single-buffered roScreen has 50/50 chance of showing on screen - and when it does not show, program does not exit abruptly; everything works smooth - except roScreen is not visible, instead the "Loading..." poster stays there. I think this is 5.4-related because it happens on HDMI Stick and also on 3100 player with 5.4 - but not on Roku3 with 5.3. When i noticed it, I tested by launching the code 10 times one after another, ECP or remote - and in half the cases roScreen shows up, in the rest it does not; there was no particular pattern (e.g. not "every other time").

Here is the code viewtopic.php?f=34&t=64834#p437652 - followed by discussion with TheEndless, who - much obliged! - vetted it on his device, noted it does not happen with double-buffered roScreen and came with the theory that it depends on when (i.e. in which buffer) the loading screen got interrupted by the creation of roScreen. Great thinking! Seems to me a very likely explanation.

Severity: if this is indeed 5.4-related behavior, it may mean channels built on single-buffered roScreen will have 50% chance of meatballs - i mean seemingly not working. Repeating the start once or twice more will work.

[TheEndless]

"EnTerr" wrote:
and when it does not show, program does not exit;

Did you define a message port for the screen? The code you posted in the other thread didn't. I'm not sure what you mean by "program does not exit," but that part could be related to your Wait() waiting indefinitely on a non-existent port.

[EnTerr]

"TheEndless" wrote:
Did you define a message port for the screen? The code you posted in the other thread didn't. I'm not sure what you mean by "program does not exit," but that part could be related to your Wait() waiting indefinitely on a non-existent port.

It means "program behaves as expected" - i'll add "abruptly" above. roScreen comes with existent port, it would be interesting to discuss why (and what happens if program does not drain the queue - does it overflow and/or crash eventually) - but that's another story.

[TheEndless]

"EnTerr" wrote:
It means "program behaves as expected" - i'll add "abruptly" above.

Gotcha.. I was reading it as though you were saying you couldn't get it to exit on keypress, because the Wait hung indefinitely.

"EnTerr" wrote:
roScreen comes with existent port, it would be interesting to discuss why (and what happens if program does not drain the queue - does it overflow and/or crash eventually) - but that's another story.

Really? That is interesting. Did you discover that by accident? Good question about draining the queue.. that would be a memory leak, but I suppose it'd be pretty rare to have a screen that you didn't listen to.

[EnTerr]

"TheEndless" wrote:

"EnTerr" wrote:
roScreen comes with existent port, it would be interesting to discuss why (and what happens if program does not drain the queue - does it overflow and/or crash eventually) - but that's another story.

Really? That is interesting. Did you discover that by accident? Good question about draining the queue.. that would be a memory leak, but I suppose it'd be pretty rare to have a screen that you didn't listen to.

Yes. Being a newb, i wondered: if nobody is listening, does roScreen still send messages? (compare, "If a tree falls in the forest...") - so i checked getMessagePort(). Little did i know that all (other) ro-components come with port = invalid. Go figure. It's probably peculiarity of the implementor, after all roScreen is oddball in that it has no Show()/Close() and does not stack with the other components.

[RokuJoel]

Verified this on 3100x on 5.4 b3339 - is that the build version you are on EnTerr?

- Joel

[EnTerr]

"RokuJoel" wrote:
Verified this on 3100x on 5.4 b3339 - is that the build version you are on, EnTerr?

5.4.3358
But also on 5.4.2525 on Stick #3500, hence i believe behavior is endemic to 5.4.*

[coolbits]

Hi,
Can anybody please provide a fix for this problem?

Thanks in advance,
Chandana