have a message port and make the mistake of typing
print port
in the console
now I have an eternal stream of the word invalid and I can’t kill it. Have to actually pull plug, nothing else works to get the debugger back.
- Joel
There’s an interesting bug! I don’t get exactly the same result, but it definitely screws up the box. I only get invalids if I keep pressing Ctrl-C. Issuing an ECP launch/dev command oddly enough took me back to the main menu, but nothing works except “Settings”. I can preview a screensaver, but it’s obvious that something is eating up cycles and I can’t get into the screensaver’s custom settings. This is a case where the reboot remote sequence comes in handy.
-JT
We ran into that non-functioning home screen problem about once a week while developing KidPaint. I think it was a combination of crazy code and a less mature environment at the time. I haven’t seen this particular behavior in months now.
kbenson, I’ve seen the behavior you described as well and as you said I haven’t seen it in months either. It’s as if the main application thread doesn’t get properly killed. I was never able to come up with a repeatable example, until now. :mrgreen:
-JT
The port is a global m.port, defined like this (totally untested code but similar):
sub main
v=init()
v.exec()
end sub
function init() as object
return {port:createojbect("romessageport")
scrn:createobject("roposterscreen")
exec:dostuff}
end function
function dostuff()
m.scrn.setmessageport(m.port)
stop
end funtion
then ?m.port
More annoying port stuff:
given a port m.port
and an object like a springboard
p.setmessageport(m.port)
x=p.getmessageport()
?x
roku now needs to be rebooted…
While crashes and reboots certainly aren’t ideal, why exactly are you trying to print message ports to the console anyway?
According to the component reference, x=object.GetMessagePort() should tell me what if any port the screen is set to. Instead if results in having to reboot when I print.
I"m trying to figure out why I’m not getting any messages on a port when I’ve set the screen to point to it. The port exists (global), the screen exists (local) both exist in the current context. Once I hit the message loop, nothing further happens unless I hit break, or the home button.
- Joel
Oh, also, I just felt like bitching and moaning.
- Joel
“jbrave” wrote:
According to the component reference, x=object.GetMessagePort() should tell me what if any port the screen is set to. Instead if results in having to reboot when I print.
All I can find in the component reference is that it says it returns the message port. The distinction in implied use is subtle, but there. You aren’t supposed to print a message port. Printing it would probably just give you a listing of it’s object type.
I"m trying to figure out why I’m not getting any messages on a port when I’ve set the screen to point to it. The port exists (global), the screen exists (local) both exist in the current context. Once I hit the message loop, nothing further happens unless I hit break, or the home button.
Are you creating message ports as needed, or passing around existing ones? I’m pretty sure the purpose of the GetMessagePort() method is to make it easier to access existing ports for re-use.
was trying to pass one around. As it turns out, if you don’t create a button on a springboard, it appears you don’t get any messages period, so the problem is essentially solved.
- Joel
“kbenson” wrote:
We ran into that non-functioning home screen problem about once a week while developing KidPaint. I think it was a combination of crazy code and a less mature environment at the time. I haven’t seen this particular behavior in months now.
I’ve been seeing this behavior recently, but I don’t have a reliable way to reproduce it. It seems to happen when roUrlTransfer.GetToString takes awhile or fails, but I don’t have anything beyond that.
It results in a mostly non-responsive home screen. I can move left and right to different channels, but pressing OK does nothing. You can’t launch any channels at all. The only way to fix it is a reboot.
I saw this quite a bit whenever the roAudioPlayer would crash (back when I was working on my SiriusXM and SHOUTcast channels), but haven’t seen it much since. Are you doing anything with the roAudioPlayer by any chance?
“TheEndless” wrote:
I saw this quite a bit whenever the roAudioPlayer would crash (back when I was working on my SiriusXM and SHOUTcast channels), but haven’t seen it much since. Are you doing anything with the roAudioPlayer by any chance?
I’ve been seeing it semi-frequently lately with the following scenario:
-
On an roPosterScreen, attempt to load an RSS XML feed on isListFocused()
-
Create an roUrlTransfer object, set my URL, SSL cert file, and basic authentication header.
-
Call roUrlTransfer::GetToString() to retrieve my XML feed of videos (something will go wrong here)
The GetToString() call never finishes, but the channel doesn’t hang or crash. I can still move around the UI, but pressing Enter doesn’t do anything. I can get back to the main menu if I press the Home button, but I can’t launch any channels. A reboot is required.
Eventually if I wait long enough, the GetToString() call will finish, and I’ll see the debug print statement that I put after it. The weird thing is, I’ll get this print statement after I’ve already pressed the Home button, after I’ve already been on the main Roku menu for a good while. After that point, I can launch channels again. I would think that pressing the Home button would kill anything/everything associated to my channel, but that doesn’t seem to be the case when this scenario occurs.
I’m not sure why the GetToString() call is acting weird. It could be that the server I’m accessing isn’t behaving at that exact moment, but even if that was the case, it shouldn’t make the Roku behave that way.
The UI screens run in a different thread than your application code, so that would explain why you’re still able to use the UI while doing the web request. It sounds like your web request is taking a really long time to return for some reason. While it definitely sounds like something funky is going on with the Roku in that situation, there are some things you can do to work around it…
First, for long web requests, I’d recommend either putting up a “Please Wait…” dialog or clearing the currently displayed content items and displaying a “retrieving…” message, so the user can’t browse around during the request, particularly if you’re loading in response to a poster selection.
Second, I’d recommend using a AsyncGetToString model, so you can specify a timeout, instead of hanging indefinitely. The urlUtils.brs file in the videoplayer example has a nice example of how to do this in a way that behaves like the GetToString synchronous method, while providing the ability to timeout on longer than expected requests. You can further extend that example by capturing ResponseCode and ResponseHeaders if you have a need for them.
