I added a feature to our app to detect “long presses” - when the user is holding down a directional key, the focus keeps moving until the key is released. Problem is that sometimes the roku does not detect that the key has been released and the focus keeps moving indefinitely until the user presses a new key. This seems to happen more with older-style remotes and with roku stick devices. I’m trying to figure out if there’s another way to detect that the user is not holding down the key any longer.
Is there a way to detect the current state of the remote (pressed / not pressed) other than listening for key release events?
tyvmia
I use it to cheat when playing a space game I’m writing. At least for now.
The remote sends the keyup code, but it doesn’t mean the roku receives it, so if you hit a button, then aim the remote away when you release it, often that never gets received.
The only thing I know of would be to cancel any key holds on any new keypress. So if they hold down the right key, and you never receive that key up, but you receive a new key, of course the right button has been released since only one key at a time works in bs.
The remote sends the keyup code, but it doesn’t mean the roku receives it, so if you hit a button, then aim the remote away when you release it, often that never gets received.
Actually that’s not how the IR remotes work. While holding down a button, the remote repeatedly sends a key code. When you release the button, it stops sending the code. The Roku software generates a release event when it detects that it is no longer receiving the key code. So it shouldn’t be possible to miss a release event simply by pointing the remote away when you release the button.
IR remotes are basically simple flashlights. There’s no way to query the current state, or in fact to send any information or commands from the Roku to the remote.
Actually that’s not how the IR remotes work. While holding down a button, the remote repeatedly sends a key code. When you release the button, it stops sending the code. The Roku software generates a release event when it detects that it is no longer receiving the key code. So it shouldn’t be possible to miss a release event simply by pointing the remote away when you release the button.
IR remotes are basically simple flashlights. There’s no way to query the current state, or in fact to send any information or commands from the Roku to the remote.
–Mark
Good point. Well, I sure can’t say why it works, but it does work. Seems to only work on the roku TV if that matters.
I just made a test case channel that does nothing but dump the events to console, and absolutely can’t get it to happen there. So far every down has an up. I’ve clearly gone insane because I know this was happening, but I also understand why it’s impossible.
The remote sends the keyup code, but it doesn’t mean the roku receives it, so if you hit a button, then aim the remote away when you release it, often that never gets received.
Actually that’s not how the IR remotes work. While holding down a button, the remote repeatedly sends a key code. When you release the button, it stops sending the code. The Roku software generates a release event when it detects that it is no longer receiving the key code. So it shouldn’t be possible to miss a release event simply by pointing the remote away when you release the button.
IR remotes are basically simple flashlights. There’s no way to query the current state, or in fact to send any information or commands from the Roku to the remote.
–Mark
Can you be more specific? Perhaps explain the different types of remotes in use: Using the 2D I do not see repeated codes, just the keypress when pressed and the keypress + 100 when released. I use a flag to keep tract of the last key pressed to perform continuous behavior. But I have experienced a “lost” key up event from time-to-time. You can set a timer to get around this if its that big a deal but I am curious about your statement. I just tested it again using ROKU 4 and its packaged remote, and I only get the down and release codes, no matter how long I hold the button down.
I was referring to how the remote itself behaves. The events delivered to Brightscript use a different paradigm. If you look at the remote through a cellphone camera, you will see that while you hold a button down, the remote is sending continuous codes. (Well not actually continuous; it repeatedly sends 180 ms codes with a 30 ms gap between codes.) When you release the button it stops sending. The firmware sends one press event to Brightscript when it receives the first code, and synthesizes a release event when it fails to get another code in the expected time.
Thanks for clearing that up. Perhaps you know something about the new ROKU app. The last time I checked (it has been a couple of months, perhaps something changed ), holding down any of the scroll icons resulted in an extra set of key press being sent to the device when the icon was released. ( At least this occurs in my own channel ); however, This does not occur with a single key down/up only when holding down the icon for continuous scroll. This behavior was not present in the old app and is not consistent with the way the remote works. I have verified the extra sequence in my own code. As there really is no way to tell what device is sending commands it cannot be intercepted and ignored
While holding down a button, the remote repeatedly sends a key code. When you release the button, it stops sending the code. The Roku software generates a release event when it detects that it is no longer receiving the key code.
If that’s the case, why are we experiencing the behavior where the firmware believes the keypress is still held after it’s been released, and how can this be resolved?
Does this only apply to IR remotes?
tyvmia
“NewManLiving” wrote:
Thanks for clearing that up. Perhaps you know something about the new ROKU app. The last time I checked (it has been a couple of months, perhaps something changed ), holding down any of the scroll icons resulted in an extra set of key press being sent to the device when the icon was released. ( At least this occurs in my own channel ); however, This does not occur with a single key down/up only when holding down the icon for continuous scroll. This behavior was not present in the old app and is not consistent with the way the remote works. I have verified the extra sequence in my own code. As there really is no way to tell what device is sending commands it cannot be intercepted and ignored
Huh, that’s an interesting one. It could be either because of change of what “Roku by Roku” app ECP-sends has changed - or it might be a change in the firmware too. How does my “old faithful” remote app (https://itunes.apple.com/us/app/remote- … d438407178) behave with your channel? That is if you are about iOS. If both apps (mis)behave the same, we blame it on the firmware (or your channel ). If they differ - it may be the app.
“RokuMarkn” wrote:
I was referring to how the remote itself behaves. The events delivered to Brightscript use a different paradigm. If you look at the remote through a cellphone camera, you will see that while you hold a button down, the remote is sending continuous codes. (Well not actually continuous; it repeatedly sends 180 ms codes with a 30 ms gap between codes.) When you release the button it stops sending. The firmware sends one press event to Brightscript when it receives the first code, and synthesizes a release event when it fails to get another code in the expected time.
Right, that’s a good one - preview through phone’s camera. Subject to whether the camera has an IR filter - e.g. my iPhone5s can’t see the IR LED at all - then iPhone4 sees it, very bright - then iPhone6 sees it again, as dim violet.
A few years ago i was into IR codes and remember Roku remote actually sent 2 distinct NEC codes per button… but since you say there is no “key up” IR code, it might be the two codes might been “key-down” (sent once), followed by “key-down-repeat” (multiple times). Which ummm… doesn’t seem to make a difference for this thread.
Given that, seems it must be some issue with the firmware, doesn’t it? Like either keyUp event does not get synthesized or gets dropped from the queue. There might be something in BradC’s method (e.g. imagine waving remote to the side mangles the IR repeat code enough to confuse the receiver) but i can’t reproduce it in RokuTV’s main screen - @BradC , does it have to be in B/S app?
Huh, that’s an interesting one. It could be either because of change of what “Roku by Roku” app ECP-sends has changed - or it might be a change in the firmware too. How does my “old faithful” remote app (https://itunes.apple.com/us/app/remote- … d438407178) behave with your channel? That is if you are about iOS. If both apps (mis)behave the same, we blame it on the firmware (or your channel ). If they differ - it may be the app.
I will try yours out and see. However, the application responds as expected with all remotes and with the old ROKU app. So I do not see where the channel code is even the issue but I’ll look at that again . A simple print statement reveals the extra set of commands as received when the icon is released. This is what I’m am concerned with
I had it happen again earlier today on a different channel, and just now I was able to recreate it yet again in the space channel… I’m looking at it right now.
I will have to try to track it down when I get more time, or just blow off the stuff I really really need to be doing. heh. At this point I really want an easily reproducible test case.
I don’t understand how it can happen. Logically it shouldn’t be possible. I thought perhaps 2 codes could come in within one “cycle” but that doesn’t matter, because when I put a delay in the test channel, the codes are simply cached and still are read in sequence. There should be no way to miss an “up” code once it’s generated.
perhaps something else is interfering with the port that we haven’t considered.
Fortunately (at least that’s how I see it), since the basic situation ought to be impossible, it must be an internal software bug of how the Roku handles the remote, and thus it should be fixable via a software/firmware update.
Unfortunately, I don’t have a whole lot of faith that will ever happen, because I don’t get the feeling Roku is very committed to being a solid gaming platform, which is where this occasional missed key release problem matters most.
“EnTerr” wrote: @BradC, does it have to be in B/S app?
AWESOME Point EnTerr.
I was assuming it would, and that there was probably something wrong with my code.
But after farting with the remote for 5 minutes, I was just able to get it to happen on the main roku screen. Yaaaaay.
it’s scrolling indefinitely now, as I type (with both hands obviously) and my remote is lying beside me with no buttons pressed.
Wooooo. I’m not crazy. I can’t say how it happens, but this absolutely happens and it’s not in my head. I almost want to take a video to prove it but it’s 1am and I guess for me watching those icons go by is enough to make me happy I’m not insane.
“BradC” wrote:
I was just able to get it to happen on the main roku screen. Yaaaaay.
it’s scrolling indefinitely now, as I type (with both hands obviously) and my remote is lying beside me with no buttons pressed.
… watching those icons go by is enough to make me happy I’m not insane.
THAT is the point we should stress to Roku, that this can happen to their main interface, making Roku seem buggy to EVERYONE who uses it, so they should fix this!
I was able to get this to happen a couple more times, scrolling the other way too. I may try it on other roku players as well, but I’m goint to sleep now.
At least for now.
). If they differ - it may be the app.
