Slowed Debugging Response From Roku2

Archived
1

We just picked up a Roku2, and the debugger seems to print at about 1/10 the speed of the previous model. For example, print times were almost instantaneous with the previous model, where with the Roku2 it takes a good 10 seconds sometimes to show debugger messages.

I’ve even had a couple cases where it doesn’t print anything at all, and I have to restart the Roku2 to clear the “session”.

Anyone else having this issue?

Thanks
Jay

2

I didn’t notice this, but it does seem to take significantly longer to side-load a dev channel, and sometimes when you press ctrl-c to interrupt a newly side-loaded channel, instead of dropping you at the console, it exits the channel.

  • Joel
3

I’ve always had that problem with Ctrl-C on every firmware release. Sometimes it works, sometimes it exits the channel. I get the same thing trying to use a stop statement.

-JT

4

“renojim” wrote:
I’ve always had that problem with Ctrl-C on every firmware release. Sometimes it works, sometimes it exits the channel. I get the same thing trying to use a stop statement.

-JT
I think we may have had this conversation before, but I only have that problem when using PuTTY. It doesn’t happen with the built-in windows telnet client for me, but I much prefer PuTTY’s features over that (particularly its multi-line copying).

5

We have. :grinning_face_with_smiling_eyes: :wink: I’m pretty sure I’ve also seen it with Window’s telnet, but like you I much prefer PuTTY, so it’s been a long time since I’ve tried it. It’s odd how sometimes it works with PuTTY and sometimes it doesn’t. Have you seen it happen using a stop statement?

-JT

6

“renojim” wrote:
We have. :grinning_face_with_smiling_eyes: :wink: I’m pretty sure I’ve also seen it with Window’s telnet, but like you I much prefer PuTTY, so it’s been a long time since I’ve tried it. It’s odd how sometimes it works with PuTTY and sometimes it doesn’t. Have you seen it happen using a stop statement?

-JT
I have. I’ve also seen it happen while connecting when I’ve already hit a break point (or crashed), but haven’t connected via telnet yet. I’m 95% sure it’s extra line feeds that PuTTY is sending to the box, which makes me think it has something to do with the echo settings, but I can’t figure out which connection setting to adjust to fix it.

7

I think unchecking “Return key sends Telnet New Line instead of ^M” helps, but it’s still hit or miss. It would be nice if a stop statement would always remain in the debugger.

-JT