As I’m sure a lot of you do, I use the statement “msg = wait(0,port)” inside a while loop all over the place. I had assumed that the only way to get past that statement was to have a valid event for whatever component(s) port was associated with. I couldn’t figure out why my code would crash on “print type(msg), msg.GetMessage()”. After I split the print into two statements, I found out sometimes msg == invalid. That was something I did not expect and I suppose the validity of msg has to be checked every time. I wasn’t bothering to check the type of msg if I was only using one type of component and a timeout of 0.
“greubel” wrote:
What type of object is port associated with ?
I’ll have to double check, but I think it’s associated with both an roImageCanvas and roVideoPlayer. It’s something that I’m just using to test different things, so it’s not like it’s anywhere near being a finished channel. I was just printing out the messages as my loop received them and not acting on them. It may just be pressing the Home button that causes this - some sort of screwed up event dispatching while the channel is being killed. I guess if it’s only the Home button that causes it then it may not be a big deal, but I still wasn’t expecting it and it seems kind of sloppy if the Home button can cause strange events to be dispatched.
I haven’t experienced this, but I could see the home button causing something like this.
The home button used to send an event that could be caught as a message, but apparently some apps weren’t the best behaved and they needed a way to ensure you could get to the home screen.
It’s interesting if it is caused by the home button. If there’s sufficient time before the app is actually killed, it’s possible you could detect invalid events and use them to initiate some small cleanup routine, if quick enough. Of course, doing so would probably be using an undocumented “feature”, frowned upon by Roku, and subject to stop working at any point if they changed the behavior.
If you receive an unknown event in your event loop, you should ignore it; then just continue processing other events. Roku may occasionally add new events, and if your event is written to exit on unknown events, any future events that Roku may add will cause your application to misbehave.
That is from the component reference guide. That may be what you are experiencing.
On a related note, I have been having some strange issues with the Home button and errors being thrown, but I will start another thread for that.
“mainmanc” wrote:
On a related note, I have been having some strange issues with the Home button and errors being thrown, but I will start another thread for that.
My understanding is that there are currently NO guarantees about behavior, besides returning to the home screen, once the home button is pressed. I believe it was stated by a Roku employee that if you want to keep some sort of state, you need to save periodically. Other people have noted odd errors showing up when the home button is pressed, and that’s probably to do with the application being uncleanly shut down (killed). I think the general consensus, or at least Roku’s position, is to ignore these.
“mainmanc” wrote:
On a related note, I have been having some strange issues with the Home button and errors being thrown, but I will start another thread for that.
My understanding is that there are currently NO guarantees about behavior, besides returning to the home screen, once the home button is pressed. I believe it was stated by a Roku employee that if you want to keep some sort of state, you need to save periodically. Other people have noted odd errors showing up when the home button is pressed, and that’s probably to do with the application being uncleanly shut down (killed). I think the general consensus, or at least Roku’s position, is to ignore these.
I am not having an issue with state, but it certainly is misleading when an error is thrown up on the console. As a programmer, that justs drives me nuts every time I see it . If it is indeed a situation based on the “unexpected” return to the Home screen (which is appears to be) there should be at least some mechanism to either suppress or handle a clean return internally, instead just throwing an error, in my opinion.
“mainmanc” wrote:
I am not having an issue with state, but it certainly is misleading when an error is thrown up on the console. As a programmer, that justs drives me nuts every time I see it . If it is indeed a situation based on the “unexpected” return to the Home screen (which is appears to be) there should be at least some mechanism to either suppress or handle a clean return internally, instead just throwing an error, in my opinion.
My guess would be that it’s not actually returning and invalid msg, but instead killing the “wait” itself so msg is never set, in which case, it would be your code’s responsibility to handle that situation, not the Roku.
I think the bottom line is that you have to test for msg being invalid after every wait. I was going under the assumption that the only way you could get an invalid message was if the timeout was something other than zero.
“mainmanc” wrote:
I am not having an issue with state, but it certainly is misleading when an error is thrown up on the console. As a programmer, that justs drives me nuts every time I see it . If it is indeed a situation based on the “unexpected” return to the Home screen (which is appears to be) there should be at least some mechanism to either suppress or handle a clean return internally, instead just throwing an error, in my opinion.
My guess would be that it’s not actually returning and invalid msg, but instead killing the “wait” itself so msg is never set, in which case, it would be your code’s responsibility to handle that situation, not the Roku.
Yeah, that would make sense. What do you recommend as the best approach to handle those situations through code?
“mainmanc” wrote:
I am not having an issue with state, but it certainly is misleading when an error is thrown up on the console. As a programmer, that justs drives me nuts every time I see it . If it is indeed a situation based on the “unexpected” return to the Home screen (which is appears to be) there should be at least some mechanism to either suppress or handle a clean return internally, instead just throwing an error, in my opinion.
My guess would be that it’s not actually returning and invalid msg, but instead killing the “wait” itself so msg is never set, in which case, it would be your code’s responsibility to handle that situation, not the Roku.
Yeah, that would make sense. What do you recommend as the best approach to handle those situations through code?
EDIT: Actually this looks more like the issue I’m talking about. http://forums.roku.com/viewtopic.php?f=34&t=28472&start=0
I actually have “If msg = invalid” checks in all of my wait loops. To be fair, though I have a timeout in most of my waits because I use them as timers as well. In general, it’s probably a good practice to check all of your objects for validity, especially since the SDK doesn’t provide any kind of error handling. Adding an “If msg <> invalid Then” to your wait loop should prevent the crash, and won’t hurt to have regardless.
Something strange I’ve come across that I haven’t understood…
To learn more about what events come to a port, I’ve had ‘print type(msg)’ lines. And a few times when I pressed home, the box would get stuck in an endless loop printing ‘invalid’. And part of the time when that would happen, I would get back the the channel list, but I wouldn’t be able to get into any channel unless I rebooted roku. Just curious if anyone else has seen that error, and knows the reason.
-Kevin
“YungBlood” wrote:
Something strange I’ve come across that I haven’t understood…
To learn more about what events come to a port, I’ve had ‘print type(msg)’ lines. And a few times when I pressed home, the box would get stuck in an endless loop printing ‘invalid’. And part of the time when that would happen, I would get back the the channel list, but I wouldn’t be able to get into any channel unless I rebooted roku. Just curious if anyone else has seen that error, and knows the reason.
-Kevin
I’ve seen the latter issue after trying to open an audio file in the roAudioPlayer with an incorrect StreamFormat. I can’t say I’ve seen the infinite loop on Home issue, though.
I haven’t seen the endless loop of invalids, but I’ve seen two dozen or more. I have seen the issue where you can navigate the main channel menu, but not select anything. I haven’t come up with a reproducible case that causes it, though. I thought pressing Home killed the channel outright, but it makes me think it’s not 100% reliable.
Well my scroll buffer on my telnet client is 200 lines, and it’s maxed out the scroll buffer… I agree if it can lock on the main channel selection, it’s not a true kill. Also, I’ve hit the home key, then gone back into my app, and my tmp:/ files were still there part of the time.
-Kevin
It seems there are a number of bugs reported in this thread…
I’ve got:
Playing audio with an incorrect streamformat in the audio player causes the firmware to crash
wait() with a zero timeout sometimes returns an invalid message (this should not happen, are you sure it’s invalid and not a different unknown message type?)
Hitting the Home button does not clean up tmp:/ files for the channel.
Hitting the Home button sometimes causes invalid messages to be sent to the app in a loop.
I don’t see how 2) or 4) could happen. Would be great if someone has a reproducible case for these.
I’ll look through my test code and see if I can find the best reproducible code that demonstrates this “invalid” problem. What I can say is when I was still learning about brightscript, I had these lines in my loops:
Re: 2) & 4),
It’s definitely invalid. It’s definitely caused by pressing Home. And, I don’t even have to send you anything. Try the custom video player example from the v2.6 SDK. You’ll notice what I thought was an unnecessary “if msg <> invalid” right after a “msg = wait(0, m.port)” in the EventLoop() function. Add an “else, print msg”, start it up, wait for it to print a couple of “startup progress” messages and then press home. It doesn’t do it every time, but it does it most of the time.
. If it is indeed a situation based on the “unexpected” return to the Home screen (which is appears to be) there should be at least some mechanism to either suppress or handle a clean return internally, instead just throwing an error, in my opinion.