Roku locking up / freezing

Unlikely that it's related to a software update. The box automatically checks for updates on boot up, which would explain the change after the reboot.

If you were playing a game that uses roScreen, it could be that the graphics memory in that game isn't being managed properly, which could result in a reboot. The Roku 2 XD and XS are particularly volatile with the 2D API, if memory isn't managed correctly.

Yes, "Software Version" under Settings is the same as the firmware version.

(Technically, unless the lock up is happening in a channel you're working on, this should probably be in the general forum.)

I think I've narrowed it down to the automatic update happening at the same time I'm trying to upload my app in dev mode.

Doubtful. The box only checks for or installs updates when it's idle, unless you manually start the process.
It does check for and install updates as part of booting up however. That may be what you see.

Player freezing confirmed.

I have seen the same behavior before (player crashes after left alone overnight in a game) and was not at all surprised - but after seeing this post decided to repeat on purpose what i have experienced, in a more controlled manner. Here is the recipe:

1. Take a Roku 2XS (#3100)


2. Install this channel


3. Start the app. Peruse or not - but then leave the player to marinate in the app overnight (no matter which level/gallery screen)


4. Next day come back to the player, it will be at black screen (screensaver kicked in) - press a button to wake it up


5. Observe the app is still responsive to the remote (not hanging).


6. Now press Home. You'll hear a sound, screen may blink - but remains with the same image (from the channel, does not switch to home screen)


7. Mission accomplished - player is catatonic and does not respond to any remote stimuli (repeat presses of Home don't cause beep)

Observations on the player while it is in this stupor state:

• reboot watchdog never kicks in


• tcp/ip stack is up, ECP commands are responded to, albeit not acted on:

  $ curl -i -d '' 'http://192.168.1.25:8060/keypress/home'
  HTTP/1.1 202 Accepted
  Server: Roku UPnP/1.0 MiniUPnPd/1.4
  Content-Length: 0
  
  $ curl -i -d '' 'http://192.168.1.25:8060/launch/12'
  HTTP/1.1 503 Service Unavailable
  Server: Roku UPnP/1.0 MiniUPnPd/1.4
  Content-Length: 0
  
  $ curl 'http://192.168.1.25:8060/query/apps'
  <apps>
  	<app id="12" type="appl" version="3.1.6040">Netflix</app>
  	<app id="28" type="appl" version="3.2.21">Pandora</app>
  	...    
  </apps>
  



• console at 8085 picks up the phone, and so does 8080:

  >free
               total       used       free     shared    buffers     cached
  Mem:        169208     158000      11208          0      37732      53720
  -/+ buffers/cache:      66548     102660
  Swap:            0          0          0
  



• None of the known unpublished Konami codes work, except the reboot (which works and causes restart after a wait)

My player is on 6.2.3453 (updated 4/27 7:32pm), as compared to OP's 6.2.3321. And dev42 told me it wasn't my app where his player locked up - so it seems we have systemic issue - not specific to firmware build or single channel.

"TheEndless" wrote:
... it could be that the graphics memory in that game isn't being managed properly, which could result in a reboot.

This isn't a reboot - it is a complete paralysis, different symptom.

"kc8pql" wrote:
The box only checks for or installs updates when it's idle, unless you manually start the process.

Wrong, my dear Sir.
After reboot (~7pm) my box was "Last checked: Apr 28 2:07pm" - which shows it did check "behind my back", while the channel was running and the player was not idle (per most meanings of "idle"). And it took on itself to check again at 7:21pm - which means it may check more than once daily. So the check cannot be excluded as a factor.

Confirmed here as well.

Roku 2 XS, Model 3100X, version 6.2 build 3321.

I've had the Roku lock up and freeze numerous times when playing Retaliate. It seems to happen most often when there are lots of key presses involved in a short span of time, usually when I'm plowing through the several consecutive rows of alien spaceships, raising and lowering the shields in quick succession as I pass through each row. The screen freezes and will not respond to any key press (not even Home) (nor will it respond to key presses via the IOS Roku app). The audio keeps playing for a few seconds longer (I guess until it gets to the end of its current loop).

Telnet access still works. r2d2 works and does not appear to indicate a memory problem:

>r2d2_bitmaps
RoGraphics instance 0x1c6b5aa0
address    width height bpp     size name
0x106ae5f0   960    720   3  2826240 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_background.png
0x16f70128   404    148   4   266240 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_button_easy_0.png
0x1060a038   404    148   4   266240 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_button_easy_1.png
0x16f286d8   404    148   4   266240 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_button_normal_0.png
0x16f7b308   404    148   4   266240 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_button_normal_1.png
0x1c6e7a20   404    148   4   266240 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_button_hard_0.png
0x1c6e9ea0   404    148   4   266240 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_button_hard_1.png
0x1cfd80b0   404    148   4   266240 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_button_extreme_0.png
0x1064e3f0   404    148   4   266240 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_button_extreme_1.png
0x106cab98   404    148   4   266240 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_button_donate_0.png
0x106813d0   404    148   4   266240 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_button_donate_1.png
0x10051ff8   900    160   4   593920 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_logo.png
0x10071078   534     70   4   208896 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_subtitle.png
0x1000cba8   592     36   4   155648 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_romans.png
0x16fea458   782     24   4   102400 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_scripture_1.png
0x1066b548   813     24   4   106496 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_scripture_2.png
0x13c222f0    68     89   4    36864 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_ship_top.png
0x1c28f298    68     89   4    36864 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_ship_left.png
0x16f3d8d8    68     89   4    36864 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_ship_right.png
0x16f71ea0     9     22   4     4096 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_bullet.png
0x16f25600     9     22   4     4096 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_enemy_bullet.png
0x106b24d8   130    130   4   102400 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_shield.png
0x1cfbbbd0    54     67   4    24576 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_enemy_1.png
0x1c26d1d8    59     89   4    24576 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_enemy_2.png
0x1c665ae0   960    720   3  2826240 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_background.png
0x1c243eb8     4    720   3    94208 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_line.png
0x1000b278    34     34   4    16384 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_explosion_0.png
0x13ce50f0    34     34   4    16384 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_explosion_1.png
0x1c26c368    34     34   4    16384 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_explosion_2.png
0x1c279748    34     34   4    16384 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_explosion_3.png
0x1c266338    34     34   4    16384 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_explosion_4.png
0x1c68f0f8    34     34   4    16384 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_explosion_5.png
0x1002b108    68     68   4    36864 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_playerexplosion_0.png
0x16f9bcf8    68     68   4    36864 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_playerexplosion_1.png
0x10050168    68     68   4    36864 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_playerexplosion_2.png
0x1c26afe0    68     68   4    36864 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_playerexplosion_3.png
0x16f9cbc8    68     68   4    36864 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_playerexplosion_4.png
0x1c25b2c0    68     68   4    36864 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_playerexplosion_5.png
0x1cf02068    68     68   4    36864 /tmp/plugin/JCAAAAhMqnSF/pkg:/sprites/spr_playerexplosion_6.png
0x1c66d608  2048     42   1    98304 /Netflix/Fonts/common/DejaVuSans-Bold.ttf 47
Available memory 28698560 used 10301440 max 39000000

ECP keypress commands are accepted, but don't have any effect on the screen:

C:\>curl -v -X POST "http://192.168.0.6:8060/keypress/home"
*   Trying 192.168.0.6...
* Connected to 192.168.0.6 (192.168.0.6) port 8060 (#0)
> POST /keypress/home HTTP/1.1
> User-Agent: curl/7.41.0
> Host: 192.168.0.6:8060
> Accept: */*
>
< HTTP/1.1 202 Accepted
< Server: Roku UPnP/1.0 MiniUPnPd/1.4
< Content-Length: 0
<
* Connection #0 to host 192.168.0.6 left intact

The last time this happened, I had just re-booted the device a few minutes prior and done nothing else subsequently, other than launch the Retaliate channel (although on other occasions the device had been running for hours or days since the last re-boot, sometimes idle, sometimes not).

"EnTerr" wrote:
Player freezing confirmed.

I have seen the same behavior before (player crashes after left alone overnight in a game) and was not at all surprised - but after seeing this post decided to repeat on purpose what i have experienced, in a more controlled manner. Here is the recipe:

1. Take a Roku 2XS (#3100)


2. Install this channel


3. Start the app. Peruse or not - but then leave the player to marinate in the app overnight (no matter which level/gallery screen)


4. Next day come back to the player, it will be at black screen (screensaver kicked in) - press a button to wake it up


5. Observe the app is still responsive to the remote (not hanging).


6. Now press Home. You'll hear a sound, screen may blink - but remains with the same image (from the channel, does not switch to home screen)


7. Mission accomplished - player is catatonic and does not respond to any remote stimuli (repeat presses of Home don't cause beep)

I saw this earlier today when I loaded up Tangrams on my stick, but hitting home multiple times eventually (maybe 60 seconds or so) brought it out of its stupor, and all was fine and dandy again. It definitely was not related to any update checks. In fact, it happened the first time I ran the channel, and only about 5 minutes after boot up, so it wasn't related to extensive time in the channel, either. I know you won't like hearing this, and are welcome to argue, but this is the first time I've ever seen this happen, and it only happened with your Tangrams channel (I tested several other 2D API based channels after that, for unrelated reasons), so I'd suspect it's related to something that you're doing in the channel itself. The fact that it happens when killing the channel with the Home button would lead me to believe the box is getting hung up trying to release the graphics memory or something. When it happened earlier, I shrugged it off as an anomaly, but since your repro steps here utilize that channel, I don't think it's a coincidence (I also don't think it's coincidence that it seems to be restricted to the 3xxx family). Now, to be clear, I'm not suggesting that you're doing something wrong in your code, only that your code may be doing something that's tripping the box up. You seem to be good at finding code that does that.. 😉

"TheEndless" wrote:
I saw this earlier today when I loaded up Tangrams on my stick, but hitting home multiple times eventually (maybe 60 seconds or so) brought it out of its stupor, and all was fine and dandy again. It definitely was not related to any update checks. In fact, it happened the first time I ran the channel, and only about 5 minutes after boot up, so it wasn't related to extensive time in the channel, either. I know you won't like hearing this, and are welcome to argue...

Wait, wait - you haven't seen "this", what you describe sounds like "that" - something completely different.
Whatever you observed does not sound at all like what me and dev42 described. Yours happened (once? is it repeatable?) when starting the app, what i describe happens after many hours of being left alone and is reproducible. You are welcome to report different issue specific to Tangrams (and i am glad to hear it early rather than later) but let's not bunch it with the "overnight freezes".

Were you hearing any "audio feedback" (roAudioResource "select") when hitting Home repeatedly?
It's my understanding dev42's was a non-Tangrams app, did you miss that part?

"EnTerr" wrote:
Wait, wait - you haven't seen "this", what you describe sounds like "that" - something completely different.

Sorry, it seems I lost some important details in the multiple edits I made to my last post. I experienced "this"...

"EnTerr" wrote:
6. Now press Home. You'll hear a sound, screen may blink - but remains with the same image (from the channel, does not switch to home screen)

"EnTerr" wrote:
Yours happened (once? is it repeatable?) when starting the app, what i describe happens after many hours of being left alone and is reproducible.

Not when starting the app... when exiting the app with the Home button. Maybe that's a coincidence, but it seems like a pretty big one.
As for whether it's reproducible or not, I haven't tried it again, but I will tomorrow and let you know.

"EnTerr" wrote:
Were you hearing any "audio feedback" (roAudioResource "select") when hitting Home repeatedly?

I don't think so. I was actually going to mention that I wasn't convinced hitting Home multiple times actually had anything to do with it finally responding, but decided not to in the end.

"EnTerr" wrote:
It's my understanding dev42's was a non-Tangrams app, did you miss that part?

No, I did not miss that part. I was responding to your specific example, but dev42 never mentioned which game he was playing...

"EnTerr" wrote:
Whatever you observed does not sound at all like what me and dev42 described. You are welcome to report different issue specific to Tangrams (i am glad to hear it early rather than later) but let's not bunch it with the "overnight freezes".

dev42 said it originally happened when he was "trying to upload (his) app in dev mode" and again when he was playing a game, neither of which sounds anything like what you described. Neither has anything to do with "overnight freezes" either (nor does belltown's example, for that matter). The common behavior/features that prompted me to comment were "locking up/freezing" when exiting the app, and the 3xxx models, which are notorious (in my experience) for having memory issues with the 2D API.

The lock up happened once. Didn't try to track it down. The same issue appeared -- while developing my own app -- "back in the day" around the time when I posted things about corrupting the Roku Main menu... which to this day I wish I had taken a picture/video of! In *all* cases, unlike(?) EnTerr's, it wasn't reproducible and if memory serves, happened shortly after uploading the zip file. IOW, I've played the game in question a few times and it only happened that once *and* in regard to locking up while in dev mode, <sarcasm>I'm now a super programmer and don't make mistakes.</sarcasm>

I can only guess and as this thread has suggested, I'm a bit off in my assumptions. I'd be curious about garbage collection, memory fragmentation, ref-counts growing too large, & how 2D graphics memory is freed when exiting a dev app via "Home"... but are any of those valid concerns?

Besides, any true game coder allocates memory just once...at the beginning... even on the Roku. 8-)

My app does use roScreen and I'm on the infamous(!?) Roku 2XS.

I am just curious as to whether this has any specific bearing on my game Retaliate. Or if the problem is being experienced to the same degree with other games (I see one other is mentioned here) . I am about to be publishing an update here soon and if there is anything I can do to minimize these crashes I'd like to do so.

One quick question. Do we have any reports of this happening among non-developers, that is, on Rokus that don't have developer mode enabled? I have no idea why that would even matter, but you never know. We all seem to be having this happen amongst some timeframe near to when we side loaded a channel.

I know I'm not handling memory perfectly. However, As you can see in belltowns post I am not even close to meeting the memory limit, nor do I believe it's close to the limit of any current gen devices. If you look at it close enough though you will see that the main menu bitmaps are still in memory while you're playing the game, and I even have the background loaded into memory twice... I will for sure fix the background being loaded twice in the next update but I don't know if it's necessary to delete and recreate the bitmaps for the main menu every time the fuction to start a round is called. Again I have plenty of space between me and the memory limits.

Please let me know if we think this is at all relevant to the particular channel; and if so, if there is anything I can do to help minimize the problem.

Cheers

P.S. If any of you developers are interested in trying out the next update before it's published I'd be glad to hear your feedback. Just PM me and I'll get you the code.

"dev42" wrote:

Besides, any true game coder allocates memory just once...at the beginning... even on the Roku. 8-)

I guess this isn't me :oops:

Should I be doing this? Currently I am creating the bitmaps when I call the function for either my score screen or my gameplay screen. When the while loop within those functions is broken, the bitmaps automatically remove themselves from memory. Should I change this so that my bitmaps are all created as global variables when the game starts? If I did this I would literally have everything loaded into memory at the same time. Which to me seems unnecessary and could even put me close to the limit (especially considering the amount of content I'm adding in with the next update)

Any tips appreciated. I really am still a novice with this.