Roku Developer Program

Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Rek
Visitor

Re: App freezes when network unplugged

"belltown" wrote:
Does your channel continue to work when you unplug your ethernet cable if you remove the Print statements?

Does your channel continue to work when you unplug your ethernet cable if you have not previously opened port 8085 to view the console log?

Once you open port 8085, e.g. using Telnet, to examine your log activity, the Roku appears to open a port for transmitting log messages to your Telnet client. If the communication link between the Roku and the Telnet client terminates, it seems that after a while (perhaps when the internal console buffer fills), the channel hangs. When the connection to the Telnet client restarts, the channel resumes, all the logs that were being held in the console buffer are sent to the Telnet client, followed by any new log entries. The log timestamps will show the delay while the channel was hung.

I've seen this behavior a lot when debugging a channel from my laptop. When I put the laptop to sleep (thus severing the network connection between the Roku and the Telnet client), the channel continues to run for a little while then hangs. After I resume my laptop the console log spews forth a bunch of stored log messages then the channel continues. I don't get this behavior if I exit from Telnet before putting the laptop to sleep.

I just read RokuMarkn's comment. I think he's saying the same thing.


Ah, okay. I've confirmed that this is the same behaviour I'm seeing. So as long as the logs are stripped from production, and the user isn't connected through telnet it'll stay responsive. Cheers!
0 Kudos
belltown
Roku Guru

Re: App freezes when network unplugged

"Rek" wrote:
Ah, okay. I've confirmed that this is the same behaviour I'm seeing. So as long as the logs are stripped from production, and the user isn't connected through telnet it'll stay responsive. Cheers!

Someone correct me if I'm wrong, but ... The Print statements only do anything in a side-loaded development channel. Once you're done with testing and have uploaded the channel to the Channel Store (even if as a Private Channel), then the Print statements aren't actually logging anything anywhere, so there's no real need to strip them out in a production version.
0 Kudos
Rek
Visitor

Re: App freezes when network unplugged

"belltown" wrote:
"Rek" wrote:
Ah, okay. I've confirmed that this is the same behaviour I'm seeing. So as long as the logs are stripped from production, and the user isn't connected through telnet it'll stay responsive. Cheers!

Someone correct me if I'm wrong, but ... The Print statements only do anything in a side-loaded development channel. Once you're done with testing and have uploaded the channel to the Channel Store (even if as a Private Channel), then the Print statements aren't actually logging anything anywhere, so there's no real need to strip them out in a production version.


We strip them because we have a lot of logging, and it often has work associated with it:


' Several function calls here. getDebugString() builds a string with an int, so it's not very quick.
' Plus there's an extra intToStr and string concat in the message itself.
' By stripping this line entirely, we save a lot of execution, even if the final `print` wouldn't
' have done anything anyways.
log_e(m.getDebugString(), "The value is: "+extValueToStr(x))
0 Kudos
Komag
Roku Guru

Re: App freezes when network unplugged

I have noticed that heavy printing really slows down some operations, sometimes a LOT, but I don't know if that translates to a completed channel (private or public) - I always assumed it would.
0 Kudos
Romans_I_XVI
Roku Guru

Re: App freezes when network unplugged

Same here komag. I think "Roku probably ignores print in a .BRS", but just for safekeeping I comment out all my print statements anyway before I publish.

Better safe than slow.
0 Kudos
TheEndless
Channel Surfer

Re: App freezes when network unplugged

"Romans_I_XVI" wrote:
Same here komag. I think "Roku probably ignores print in a .BRS", but just for safekeeping I comment out all my print statements anyway before I publish.

Better safe than slow.

Actually, I don't think this is the case. I'm 99% sure the published version of the channel is identical to the side-loaded version, and I've actually had crashes in published channels that were the result of invalid objects in a "print" statement. You probably should, as a best practice, always reduce the debug output before publishing a channel.
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
0 Kudos
Komag
Roku Guru

Re: App freezes when network unplugged

In another mod I did, I used to have ALL my print commands actually call another print function:
Instead of
PRINT("Printing some test feedback text")

I would have something like
doPrint("Printing some test feedback text", sy)

and have the following:
FUNCTION doPrint(text, sy) ' sy stands for "system associative array" with important keys/values
IF sy.printOn THEN PRINT(text)
END FUNCTION

Then just before release you can simply set sy.printOn to FALSE
0 Kudos
renojim
Community Streaming Expert

Re: App freezes when network unplugged

I've never removed prints from any of my channels. No adverse effects. Trying to print an invalid object will cause a crash, but I've never seen any other problem. A slew of prints may have an impact on speed in a published channel, but I haven't done any measurements and I've never had a need for that many prints.

-JT
Roku Community Streaming Expert

Help others find this answer and click "Accept as Solution."
If you appreciate my answer, maybe give me a Kudo.

I am not a Roku employee.
0 Kudos
TheEndless
Channel Surfer

Re: App freezes when network unplugged

"renojim" wrote:
I've never removed prints from any of my channels. No adverse effects. Trying to print an invalid object will cause a crash, but I've never seen any other problem. A slew of prints may have an impact on speed in a published channel, but I haven't done any measurements and I've never had a need for that many prints.

-JT

It tends to have a more significant impact when using the 2D API when higher framerate is important.
My Channels: http://roku.permanence.com - Twitter: @TheEndlessDev
Instant Watch Browser (NetflixIWB), Aquarium Screensaver (AQUARIUM), Clever Clocks Screensaver (CLEVERCLOCKS), iTunes Podcasts (ITPC), My Channels (MYCHANNELS)
0 Kudos
EnTerr
Roku Guru

Re: App freezes when network unplugged

"belltown" wrote:
Someone correct me if I'm wrong, but ... The Print statements only do anything in a side-loaded development channel. Once you're done with testing and have uploaded the channel to the Channel Store (even if as a Private Channel), then the Print statements aren't actually logging anything anywhere, so there's no real need to strip them out in a production version.

I suspect prints in non-side-loaded app get redirected to log file, which gets uploaded to Roku heavens asynchronously. Dog forbid that being done synchronously, it would cause freezes like the described on buffer full and network down. That latter theory should be easy to check with network sniffer.
0 Kudos