I’m going to ask first then research later ( maybe :roll: )
I have a Roku 2 XS - 3100X running software version 6.2 - build 3321
While in dev mode I’ve had the Roku lock up a few times. It has taken time to find the possible cause and 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.
Today it happened while I was playing a game on the Roku. Game locked up. No access to “Home” button. After 2 power-cycles, I noticed spiffy new Star Wars wallpaper and the time-stamp of the update was pretty close to when things locked up.
Can anybody confirm this?
Also, is “software version” the same as “firmware version”?
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.
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:
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.
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:
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).
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:
Start the app. Peruse or not - but then leave the player to marinate in the app overnight (no matter which level/gallery screen)
Next day come back to the player, it will be at black screen (screensaver kicked in) - press a button to wake it up
Observe the app is still responsive to the remote (not hanging).
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)
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, I’m now a super programmer and don’t make mistakes.
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.
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.
Besides, any true game coder allocates memory just once…at the beginning… even on the Roku.
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.
Besides, any true game coder allocates memory just once…at the beginning… even on the Roku. 8-)Should I be doing this?
Do not do this…
I’m fairly certain that dev42 was joking…
Besides, any true game coder allocates memory just once…at the beginning… even on the Roku. 8-)Should I be doing this?
Do not do this…
I’m fairly certain that dev42 was joking…
Oh lol. Thanks TheEndless. I was somewhat confused. I know there are a few things I need to fix as far as memory allocation, which I have already outlined in my post. But this was pointing me in a completely opposite direction lol. I was thinking how to have less items in memory at any given moment, and he says to put them all in…
“Romans_I_XVI” wrote:
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 took my Roku 2XS out of developer mode and re-booted then went straight into playing Retaliate again. After a few games, the Roku hung again. As before, the audio continued playing for a few more seconds then stopped. After a while longer the (blank) screensaver kicked in. I pressed the home key, which removed the screensaver, showing the game screen on display. I tried over the next 10-15 minutes to get back to the Roku home page, but the Home key had no further effect, nor did any other key. The game hung in roughly the same spot as it has often (but not always) hung on previous occasions. My only recourse at this point was to re-boot the Roku.
It may be that there’s something funky going on with your code. However, the Roku still shouldn’t hang like that no matter what is going on with your code. The Home key is always supposed to get you back to the home screen.
Thanks belltown for all the testing and feedback. I want to get you involved with testing the latest unpublished version before I submit it to Roku. I will send you a PM with the access code.
I notice that the screenshot shows the game frozen while one of the “scripted events” as I refer to them is occurring. Now this may be far fetched but I believe in the current published version I accidentally left a print statement uncommented which fires right before one of those “scripted events” occurs.
We have discussed here some of the strange adverse affects leaving print statements in can have. viewtopic.php?p=483939
Anybody think this is a potential cause?
Again belltown I will PM you the code and you can see if it’s reproducable in the latest build.
Well, reviewing that, it sounds like trying to print something invalid will cause a crash - Is there any chance a value trying to be printed could be invalid there?
No. If the variable it’s printing would somehow be invalid it would crash the game anyway. The variable just says which event got selected to run.
Plus it shouldn’t matter regardless. Should just crash the app, not freeze the entire Roku. I guess I was referring more to the strange dependency on the network.
I could be way off though. It’s really tough to figure out. Maybe it’s as simple as my game running the Roku CPU too hard and it just gives up lol. I know for sure on the slower devices it can have a hard time keeping up with everything that needs to be drawn to the screen.
Also there is still the fact that holding down any button creates a huge performance hit, I have no idea why but just play my game on a Roku 1 and you will know exactly what I mean. Since holding down buttons is like %90 of my game, this could also be an issue.
“Romans_I_XVI” wrote:
Also there is still the fact that holding down any button creates a huge performance hit, I have no idea why but just play my game on a Roku 1 and you will know exactly what I mean. Since holding down buttons is like %90 of my game, this could also be an issue.
If i remember, holding down a button on the IR remote continuously fires the “button down” IR code (you can check with the front camera of your phone). I don’t remember if that’s received repeatedly as B/S event (and if so, streamline the code) but someone is handling that in the player.
My code is not set to even pay attention to say, the fast forward button or the * button. But these will all have the same ill effects. It doesn’t matter what button it is or whether brightscript is doing something with it or not.
