Detecting Keypress Release

I have run into that issue as well.

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.

That's a tough one. Maybe ifDeviceInfo - TimeSinceLastKeypress() could be helpful in some way?

I dunno, maybe it will be rare enough to just live with it. I don't know of any way to detect the current remote status.

"BradC" wrote:

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

"RokuMarkn" wrote:

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.

"RokuMarkn" wrote:

"BradC" wrote:

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.

--Mark

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

Everything I've said in this thread applies only to IR remotes. RF remotes work differently.

I can't explain why you would ever miss a release event when using an IR remote.

--Mark

OK thank you. Could you explain why this might happen with RF remotes and if there's anything that might be done about it?