Buggy behavior arrowing through Now Playing menu, menu position jumps out of place

[BrettB]

I think they do actually have separate keyboard scan codes though, which is probably why there is several names for them, even though they are for the same logical key.

Yeah, that's what I meant.

[mvallevand]

For reference UI clients don't use keyboard scancodes they are based on the MVP table Key Code table here https://www.rst38.org.uk/mediamvp/protocol.html (where the 33/34 come from) Of note there is no remote page up/down or prior/key. Having the EPG navigate by page, day or "screen" makes use some other keys and sub has to do a lot of remapping to make it all work.

Martin

[mmortal03]

My keyboard generates "Next" and "PageUp" for the PageUp/PageDown keys.

Thanks, I've experimented further with that in mind, and made some sense of it now.

On the Roku remote, changing "Prior" to "Channel+", and "PageDown" to "Channel-" reverses the channel changing direction in Martin's app, on Live TV, for a long-press on the Up and Down arrows, as well as reversing the channel changing direction of the short-press FF and RW buttons. Also doing this reverses the short-press FF and RW paging direction on the Now Playing menu.

However, for some reason, this modification *has no effect* on the paging direction for the *long-press* Up and Down arrows on the Now Playing menu. The paging direction is not altered in this particular long-press case -- it remains the same as with the default key maps.

For the Roku the long keys you are using are only really only tested to change channels while watching live. I don't want to change the definition of channel up to change to a lower channel.

Yeah, I don't think it should be changed, either, but hopefully you can figure out the cause of the inconsistency that I just described!

Edit: I didn't see your last post. Maybe that explains it. It's only for the long-press situation, though, but maybe that explanation still holds.

Sub is right that the best option is probably to increase the time of the long press, but I don't want to change the default since sending a short press when a long press is desired is not welcome behavior either.

I get what you're saying, but how much would you have to increase the time of the long press before people actually started to notice that latter problem, though? Keep in mind that I'm currently getting long presses instead of short presses pretty consistently. 

To do the science on this, I'm imagining that there might be some sweet spot that's slightly higher than 500ms, but we'd have to do testing of that, and we'd need a better understanding of the source of the latency in my setup as compared to yours. Maybe there's some way of dealing with this latency I'm experiencing elsewhere in the code to improve performance, without modifying the long press threshold? If that's the case, might there be a way to dynamically calculate the latency on a system and automatically adjust it accordingly? Maybe it's not even my system, but something to do with the different types of Roku remotes?

[mvallevand]

I expect the source of the latency is you are reading the screen between the press and release points I use to calculate the press duration.  You probably need to learn to release and read.  There really isn't time for reading even if I doubled it.

Since I send channel keys you might not be able to remap them not sure if it sends things into an infinite loop but it might be worth a try.

I've offered my suggestion on how a future change could help here,. I am not really interested in going against a 10+ old Android standard for such a minor issue.

Martin

[mmortal03]

I expect the source of the latency is you are reading the screen between the press and release points I use to calculate the press duration.  You probably need to learn to release and read.

Wow, that's not what I'm doing at all; you've got to give me more credit than that. During testing, I've been pressing and releasing as quickly as possible, and then checking the result on the Now Playing menu. The source of the latency is clearly coming from elsewhere, not me being slow at releasing the trigger.  

Would having me order you a Roku Streaming Stick 3600X on eBay make you more interested in getting to the bottom of this?

Is the Roku remote you're testing with the IR remote or the RF remote? Just an idea, but maybe there's more latency in the RF remote, which is the one I'm using? I'd like to think that that's not the case, as the RF remote has little latency in general, so maybe the remote type doesn't matter and it's coming from some other part of my system, but I'm willing to buy you a 3600X to rule it out.

I am not really interested in going against a 10+ old Android standard for such a minor issue.

I think the Android standard makes sense in a low latency environment, but there's some source of higher latency in my case. If you were experiencing the problem, you wouldn't think it was minor.

[mvallevand]

Thanks for the offer but I don't really need to test this further. I am not saying you are reading the information 500ms is pretty fast, I am thinking that you could be easily distracted by a 100ms while watching the cursor change. Until those extra unexpected screen jumps that NextPVR does (as noted in NextPVR.exe on Windows) there is no good test platform, you'd have to wait 2 or 3 seconds between presses as I explained earlier to avoid those collisions.

I expect that RF has more latency but I have never noticed the OSD dialog pop up unexpectedly which would come from a long press hitting OK, and I hit OK a lot during testing, so to me I feel the timeout is appropriate. I will watch for that issue, and for user concerns about that popup and in the meantime you can watch to see if sub allows more server-side configuration.

Martin

[mvallevand]

I did think of a test that you could try. Start Live TV and during playback hit the OK key quickly which should popup the OSD. Let that OSD expire and keep repeating the test. If the channel change OSD comes up frequently then we know the delay is too short. I will try the test name time I am running Windows. My PC is a Mac right now, set up for testing nlite.

Martin

[mmortal03]

I did think of a test that you could try.  Start Live TV and during playback hit the OK key quickly which should popup the OSD.  Let that OSD expire and keep repeating the test.  If the channel change OSD comes up frequently then we know the delay is too short.  I will try the test name time I am running Windows.  My PC is a Mac right now, set up for testing nlite.

Martin

That's a good test. I can't reproduce it there -- I have to do a proper long press for the channel change "key" menu to appear. This makes me think that something is acting differently when communicating with the backend *only* when the Now Playing menu is present.

I checked CPU usage in Task Manager for the NextPVRServer.exe process, and it stays about 10% higher whenever the Now Playing menu is showing. And it jumps *another* 10% or so right after an arrow press while within the Now Playing menu.

Maybe sub can think of something? If it has to do with the Now Playing menu being more CPU intensive and interfering with timing accuracy, then I thought we might compare to nlite, but I don't think there's an equivalent timing logic for commands that nlite depends on, because it simply doesn't have long presses to calculate (correct me if I'm wrong).

Another simple test on the Roku side is to do a short press up or down, and make sure that the Now Playing menu appears rather than a channel change. If it ever causes the channel to change, then you know it was a mistaken long press. I don't believe I've ever had a channel change happen like this, which backs up the idea that the problem only involves Now Playing.

[mvallevand]

The long press timing starts when the key is pressed but the request to NextPVR only happens after the key is released. What I expect is happening as I have repeatedly explained is that you aren't waiting for the screen updates from NextPVR to complete, maybe 2 seconds is not enough. It is also possible that the rendering flag managed by the server is being set too often or not cleared. These extra screens refreshes could be interfering with the timing.

Martin

[BrettB]

The long press timing starts when the key is pressed but the request to NextPVR only happens after the key is released.  What I expect is happening as I have repeatedly explained is that you aren't waiting for the screen updates from NextPVR to complete, maybe 2 seconds is not enough. It is also possible that the rendering flag managed by the server is being set too often or not cleared.  These extra screens refreshes could be interfering with the timing.

Martin

Yes, I was thinking that it sounds similar to the short-press/long-press problem we had a while back when the screensaver on the Roku was kicking in and then timer on the client was getting out of sync. Not a problem with the 500ms timing cutoff, but rather a problem with the "calculating" for the 500ms cutoff on that particular screen. Especially since mmortal03's testing with just the Ok button for the OSD showed the short-press/long-press determination was working fine other places.

And the CPU spikes on the server during the Now Playing display may indicate that something "unusual" (or just intensive) is going on. Maybe the OSD screens are taking significantly longer to be generated by the server and sent to the Roku to be displayed. And an updated screen just happens to come in between the time when mmortal03 presses the button and when they release it--messing up your timer.

Mmortal03: Are you using the 720 resolution and "regular" (not "high") quality for your client? If not, maybe try that and see if the lower quality screens get generated (and sent and displayed) more quickly.