Roku Developer Program

[greubel]

My channel has been plagued by nonsense interrupts coming from both types of sockets. When I get a roSocketEvent, the sockets are not readable. Sometimes, I can do a sleep(), check it again and eventually I get data after many loops of sleep and checking.
These interrupts appear to come in bursts, hundreds at a time and then they stop. Unknown why they start or stop ???

I create 3 roDatagramSockets that I named Broadcast, Chaneru and Join.

All socket MSG ports are posted to a common MSG port and there is a single routine to distribute the interrupts.
I have been receiving numerous roSocketEvents from these sockets that when checked, skt.isReadable() returns FALSE.
Did have code to try and process these entries but because I get flooded with them, I modified the code to just
count and skip them.

While playing a 2 hour movie, I received these error counts. The log entry only gets displayed every hundred.
10:06:45.421 * LOG SKT UDP Chaneru errors = 900
10:29:04.696 * LOG SKT UDP Join errors = 1600
10:36:39.811 * LOG SKT UDP Broadcast errors = 2200

Why should a roSocketEvent be posted when there is nothing to do ?

Went to lunch and this is what I now have displayed in the BRS debug console.
* LOG SKT UPNP Connect errors = 232900
* LOG SKT UDP Join errors = 228400

Seems like a big waste of resorces and quite often I have to reboot the Roku because of the flooding.

Need some Roku support, help PLEASE !

Is there an internal trace that Roku support can run that would tell what is wrong ?

[RokuJoel]

I've passed this on to the engineer responsible for roStreamSockets and he will probably get back to you here when he has a chance, or I will pass on his comments to you. If you don't hear back in a few days, bump this thread.

- Joel

[greubel]

I don't know if it has any bearing but I often get this during garbage collection when starting up.
Sometimes it takes so long, I have to reboot the Roku.

Leaked bsc instances:
  roAssociativeArray refcnt= 1 addr=0x14311e0
            roString refcnt= 1 addr=0x12672f0 [auto-run-dev]
  roAssociativeArray refcnt= 1 addr=0x143d5e0
            roString refcnt= 1 addr=0x12f8198 [homescreen]
       roMessagePort refcnt= 8 addr=0x1317c28
              roList refcnt= 1 addr=0x11feba0
  roAssociativeArray refcnt= 1 addr=0x14e1a08
            roString refcnt= 1 addr=0x1259f18 [homescreen]
       roMessagePort refcnt= 6 addr=0x1385bc0
              roList refcnt= 1 addr=0x1394550
       roSocketEvent refcnt= 1 addr=0x3f13b640
       roSocketEvent refcnt= 1 addr=0x4893f678
       roSocketEvent refcnt= 1 addr=0x4896d7d8
       roSocketEvent refcnt= 1 addr=0x489d55f0
  roVideoScreenEvent refcnt= 1 addr=0x46c0cc70
       roSocketEvent refcnt= 1 addr=0x4896ceb0
       roSocketEvent refcnt= 1 addr=0x48940380
       roSocketEvent refcnt= 1 addr=0x3f112028
       roSocketEvent refcnt= 1 addr=0x48988570
  roVideoScreenEvent refcnt= 1 addr=0x46c2ba50
       roSocketEvent refcnt= 1 addr=0x3f138b10
       roSocketEvent refcnt= 1 addr=0x4896c290
       roSocketEvent refcnt= 1 addr=0x4890a948
       roSocketEvent refcnt= 1 addr=0x48940360
  roVideoScreenEvent refcnt= 1 addr=0x3eab1bb0
       roSocketEvent refcnt= 1 addr=0x4896ccd0
       roSocketEvent refcnt= 1 addr=0x4896c7d0
       roSocketEvent refcnt= 1 addr=0x489fc5b0
       roSocketEvent refcnt= 1 addr=0x48988590
  roVideoScreenEvent refcnt= 1 addr=0x46c3d630
       roSocketEvent refcnt= 1 addr=0x3f1261c8
       roSocketEvent refcnt= 1 addr=0x4899bf70
       roSocketEvent refcnt= 1 addr=0x489d5668
       roSocketEvent refcnt= 1 addr=0x4896b170
  roVideoScreenEvent refcnt= 1 addr=0x3ea112d8
       roSocketEvent refcnt= 1 addr=0x4896c170
       roSocketEvent refcnt= 1 addr=0x3f1255c8
       roSocketEvent refcnt= 1 addr=0x48923878
       roSocketEvent refcnt= 1 addr=0x489d5630
       roSocketEvent refcnt= 1 addr=0x48988028
       roSocketEvent refcnt= 1 addr=0x3f1255e8
  roVideoScreenEvent refcnt= 1 addr=0x3ea82c68
       roSocketEvent refcnt= 1 addr=0x489d5288
       roSocketEvent refcnt= 1 addr=0x4896c5b0
       roSocketEvent refcnt= 1 addr=0x4896bce0
       roSocketEvent refcnt= 1 addr=0x48989820
       roSocketEvent refcnt= 1 addr=0x4893fb28
       roSocketEvent refcnt= 1 addr=0x4899bfe8
  roVideoScreenEvent refcnt= 1 addr=0x46c0f560
       roSocketEvent refcnt= 1 addr=0x48988048
       roSocketEvent refcnt= 1 addr=0x489662e8
       roSocketEvent refcnt= 1 addr=0x4899bf20
       roSocketEvent refcnt= 1 addr=0x48923898
       roSocketEvent refcnt= 1 addr=0x48966308
       roSocketEvent refcnt= 1 addr=0x48966328
       roSocketEvent refcnt= 1 addr=0x48988958
       roSocketEvent refcnt= 1 addr=0x489fc5d0
  roVideoScreenEvent refcnt= 1 addr=0x46b7ce38
       roSocketEvent refcnt= 1 addr=0x4896bf70
       roSocketEvent refcnt= 1 addr=0x48988610
       roSocketEvent refcnt= 1 addr=0x4899bee0
       roSocketEvent refcnt= 1 addr=0x489238b8
       roSocketEvent refcnt= 1 addr=0x4896bd00
       roSocketEvent refcnt= 1 addr=0x4899bfb8
       roSocketEvent refcnt= 1 addr=0x4896bdd0
       roSocketEvent refcnt= 1 addr=0x489fb9a8
       roSocketEvent refcnt= 1 addr=0x4890a6c0
       roSocketEvent refcnt= 1 addr=0x48923858
       roSocketEvent refcnt= 1 addr=0x48966268
       roSocketEvent refcnt= 1 addr=0x48989628
       roSocketEvent refcnt= 1 addr=0x48988630
       roSocketEvent refcnt= 1 addr=0x489d5530
       roSocketEvent refcnt= 1 addr=0x4896db28
       roSocketEvent refcnt= 1 addr=0x48966248
       roSocketEvent refcnt= 1 addr=0x48989868
       roSocketEvent refcnt= 1 addr=0x4896c810
       roSocketEvent refcnt= 1 addr=0x48923818
       roSocketEvent refcnt= 1 addr=0x3f138678
  roVideoScreenEvent refcnt= 1 addr=0x46b97f20
       roSocketEvent refcnt= 1 addr=0x4890a700
       roSocketEvent refcnt= 1 addr=0x48923838
       roSocketEvent refcnt= 1 addr=0x4896c340
       roSocketEvent refcnt= 1 addr=0x4896c7f0
       roSocketEvent refcnt= 1 addr=0x48988110
       roSocketEvent refcnt= 1 addr=0x4896c360
       roSocketEvent refcnt= 1 addr=0x489fb978
       roSocketEvent refcnt= 1 addr=0x4896b150
       roSocketEvent refcnt= 1 addr=0x3f126258
       roSocketEvent refcnt= 1 addr=0x489885f0
       roSocketEvent refcnt= 1 addr=0x489fc9e0
       roSocketEvent refcnt= 1 addr=0x4896db48
       roSocketEvent refcnt= 1 addr=0x489d5570
       roSocketEvent refcnt= 1 addr=0x4893f658
       roSocketEvent refcnt= 1 addr=0x489238d8
       roSocketEvent refcnt= 1 addr=0x489fb940
       roSocketEvent refcnt= 1 addr=0x3f126288
       roSocketEvent refcnt= 1 addr=0x489fc648
       roSocketEvent refcnt= 1 addr=0x3f1386c0
       roSocketEvent refcnt= 1 addr=0x48966288
       roSocketEvent refcnt= 1 addr=0x489fc668
  roVideoScreenEvent refcnt= 1 addr=0x3ea4c2b8
       roSocketEvent refcnt= 1 addr=0x489d5550
       roSocketEvent refcnt= 1 addr=0x48984ce8
       roSocketEvent refcnt= 1 addr=0x3f138ab0
  roVideoScreenEvent refcnt= 1 addr=0x3ea47a00
       roSocketEvent refcnt= 1 addr=0x4890a6e0
       roSocketEvent refcnt= 1 addr=0x4896c3a8
       roSocketEvent refcnt= 1 addr=0x3f1262a8
       roSocketEvent refcnt= 1 addr=0x489888e8
       roSocketEvent refcnt= 1 addr=0x4899b7b0
       roSocketEvent refcnt= 1 addr=0x48988908
       roSocketEvent refcnt= 1 addr=0x4899be50
       roSocketEvent refcnt= 1 addr=0x489fbd78
       roSocketEvent refcnt= 1 addr=0x4893f5b8
       roSocketEvent refcnt= 1 addr=0x489888b8
       roSocketEvent refcnt= 1 addr=0x4896b1b0
       roSocketEvent refcnt= 1 addr=0x489fbd18
       roSocketEvent refcnt= 1 addr=0x4896cd10
       roSocketEvent refcnt= 1 addr=0x4899b7d0
       roSocketEvent refcnt= 1 addr=0x4893f638
       roSocketEvent refcnt= 1 addr=0x489d5450
       roSocketEvent refcnt= 1 addr=0x489d53a0
  roVideoScreenEvent refcnt= 1 addr=0x46c25168
       roSocketEvent refcnt= 1 addr=0x489237f8
       roSocketEvent refcnt= 1 addr=0x4896c038
       roSocketEvent refcnt= 1 addr=0x489fbd38
       roSocketEvent refcnt= 1 addr=0x4896ccf0
       roSocketEvent refcnt= 1 addr=0x489fbd58
       roSocketEvent refcnt= 1 addr=0x4896d4d0
       roSocketEvent refcnt= 1 addr=0x4893eb38
       roSocketEvent refcnt= 1 addr=0x4896ba18
       roSocketEvent refcnt= 1 addr=0x3f125608
       roSocketEvent refcnt= 1 addr=0x489d5610
       roSocketEvent refcnt= 1 addr=0x4896b430
       roSocketEvent refcnt= 1 addr=0x4897b158
       roSocketEvent refcnt= 1 addr=0x4896ba38
       roSocketEvent refcnt= 1 addr=0x489d5748
  roVideoScreenEvent refcnt= 1 addr=0x46c606c8
  roVideoScreenEvent refcnt= 1 addr=0x46b46c18
  roAssociativeArray refcnt= 1 addr=0x48948958
            roString refcnt= 1 addr=0x4896b190 [homescreen]
------ Running ------

[TheEndless]

"greubel" wrote:
I don't know if it has any bearing but I often get this during garbage collection when starting up.
Sometimes it takes so long, I have to reboot the Roku.

Leaked bsc instances:
  roAssociativeArray refcnt= 1 addr=0x14311e0
            roString refcnt= 1 addr=0x12672f0 [auto-run-dev]
  roAssociativeArray refcnt= 1 addr=0x143d5e0
            roString refcnt= 1 addr=0x12f8198 [homescreen]
       roMessagePort refcnt= 8 addr=0x1317c28
              roList refcnt= 1 addr=0x11feba0
  roAssociativeArray refcnt= 1 addr=0x14e1a08
            roString refcnt= 1 addr=0x1259f18 [homescreen]
       roMessagePort refcnt= 6 addr=0x1385bc0
              roList refcnt= 1 addr=0x1394550
       roSocketEvent refcnt= 1 addr=0x3f13b640
       roSocketEvent refcnt= 1 addr=0x4893f678
       roSocketEvent refcnt= 1 addr=0x4896d7d8
       roSocketEvent refcnt= 1 addr=0x489d55f0
       ...
------ Running ------

That's actually the previously running channel closing, not the new one starting up, which seems to indicate you have a ton of roSocketEvents that were never dequeued.
It also looks like a Roku 1 trace, which is probably important information from a debugging perspective for the engineers.

[greubel]

This usually occurs after I run the app and either debug it using the telnet console or modify the code and then try a reload.
I would think that the sockets would get closed when the app errors or exits.
Like I said, sometimes the queue is so bad that I have to reset the box and start over.

[TheEndless]

"greubel" wrote:
This usually occurs after I run the app and either debug it using the telnet console or modify the code and then try a reload.
I would think that the sockets would get closed when the app errors or exits.
Like I said, sometimes the queue is so bad that I have to reset the box and start over.

My point was, the dump is from the running channel exiting, not the new channel starting up. On the Roku 1, it spits out all of the leaked references. On the Roku 2, it just displays something along the lines of "Note: GC - Found 30 orphaned objects (objects in a circular ref loop)."

The fact that there are that many roSocketEvents that haven't been handled seems odd, and would suggest you either have a message port assigned to a socket that you're not listening to, or something else is seriously wrong. Likewise, the fact that it's on a Roku 1 is probably very important, as the roSockets interface isn't going to be as up to date as the one on Roku 2/3. Are you seeing the same behavior on a Roku 2?

[greubel]

It appears not to have garbage traces when reloading on the Roku2. Haven't looked at the 3.
I try and do most of my development on the Roku 1. Lowest platform.

[greubel]

Any news from RokuMEmerson ?
I get nothing back from PMing him !

[RokuJoel]

I believe he has responded to you now via email.

- Joel

[greubel]

Message flooding resolved ! I hope !
I have a common message port for all my objects and had a simple msg=wait(25,port) loop.

while true
msg = wait(25,port)
if msg <> invalid
if type(msg) = "somebody"
... DO Something
elseif type(msg) = "somebody else"
... DO Something
end if
end if
end while

Well this works fine until you throw sockets into the mix. The Wait() and WaitMessage() functions use a selection mask like the UNIX select() function for sockets. So if you have multiple sockets in the read or write ready state, you will get multiple messages queued to the port. When you process the returned msg and do the wait again, you will get more messages for the same ready states. So now you have a bunch of messages on queue for the same state. Say you test for socket.isReadable(), you should be able to unload the data on the first instance but for the remaining messages on the queue for that socket, isReadable() returns false. I was getting this condition in the thousands. Which caused a lot of unnessary processing and making everything eratic, a remote click could take seconds. I also have a need to do a POST and RECV which I acquire a message port just for that socket. Well the wait() on that port, even though it's unique to that socket, still acts globally. So you can get states from OTHER sockets. I thought it weird that they were testing for "is this my socket" in the examples.

This works.
m.scrport is a port just for screens so I could get the remote clicks faster,
m.port is for everthng else and sockets.

NOTICE the wait() isn't EVEN on the one that is associated with the sockets

while true
msg = invalid
Drain_Port( m.scrport, m.SCR_Queue ) ' Look for remote click
Drain_Port( m.port, m.MSG_Queue ) ' Look for everything else

if m.SCR_Queue.Count() > 0
msg = m.SCR_Queue.Shift()
elseif m.MSG_Queue.Count() > 0
msg = m.MSG_Queue.Shift()
else
msg = wait( 10, m.scrport ) <----------- why should this work ????
end if

if msg <> invalid
if type(msg) = "somebody"
... DO Somethimg
elseif type(msg) = "somebody else"
... DO Somethimg
end if
end if
end while

Sub Drain_Port( port as object, queue as object )
msg = port.GetMessage()
while msg <> invalid
queue.Push( msg )
msg = port.GetMessage()
end while
End Sub

I think it is a BUG that wait() doesn't check what the port is associated with and that you can get multiple messages for the same event.

Many Thanks to RokuMEmerson !!