Strange Mouse Lag/Stutter While Key Pressed

[Emar]

Please fill in this template when posting!
XMBC Version:

Code: Select all

2.20.5, 2.21 Beta, as well as older versions

Installed or Portable version:

Code: Select all

Installed

Windows Version:

Code: Select all

10 22H2 19045.6159

Mouse Information (brand/model):

Code: Select all

Razer Basilisk V3 Wired

Relevant Computer Information (CPU, RAM etc):

Code: Select all

R9 5950X, 64 GB DDR4, Gigabyte X570S motherboard

Did the problem occur after an upgrade of XMBC? (If so, from what version?):

Code: Select all

No

Did the problem occur after a Windows update/upgrade? (If so, from what version?):

Code: Select all

Most probably, but no idea when

How long have you used XMBC?:

Code: Select all

More than 5 years I think

What language and keyboard layout do you use in Windows?:

Code: Select all

English US primarily

Clear description of the problem - try and include as much information as possible, including what button and mappings you are having problems with (if applicable).:

I usually keep my system running for weeks at a time (as long as possible really so that I don't interrupt downloads/tasks/renders etc.) but a month or so ago I began noticing that the longer the system is running, the key repeat becomes stuttery, sluggish. i.e. Keep a key pressed, and it becomes jittery and the mouse begins stuttering when moving it. I noticed it during a 3D modelling sessions where I had CTRL pressed when selecting multiple things. I thought it might be just that but it happens with any key really.

I closed everything running that I thought might be the culprit, but no difference. But when I closed X-Mouse, things felt fast again and the mouse doesn't stutter while a key is held down. If I disable XMB while it's running, this does not work. It only works when XMB is fully closed. Even changing CPU priority didn't make a difference.

It's really strange, I can't fathom it. I made no changes to anything except update Windows (10) to whatever patches there are. I am a slow updater as well.

In a similar thread (viewtopic.php?t=4953), I saw the recommendation to try the beta, so just a while ago I updated to the latest beta and I'm not sure I notice much of a difference, except for one: disabling XMB seems to act like closing it. Whereas on the latest stable releases, disabling made no difference and I have to exit the whole program, or restart.

The fact that restarting the computer fixes it for a while, means there is definitely some Windows update that happened at some time in the past couple of months or so, which is not playing nice with how XMB works. That's my best guess and not sure what else to do.

[phil]

Oh no not another one!...
Interestingly in the thread you linked, the problem seems to go away after switching to the latest beta (at least, I have heard no more of this)...
Also see here:

Code: Select all

https://forums.highrez.co.uk/viewtopic.php?t=4966&sid=13d96dfc013cb48440775210784177a4

In that case (still unresolved) it seems that some recent Windows(?) update has caused problems, but I haven't really got anywhere with this yet. Its not happening to me (at least not obviously) yet. My Win10 desktop at work, I also rarely shut down so I'd expect to be seeing something there - it is put to sleep over night but not actually shut down until I need to update it (which I have to do once a month - we have to be up to date in that environment)).

Disabling XMBC and re-enabling it removes the mouse hook and re-installs it - so that should *always* fix it unless its not related to the mouse hook (but that's the only thing that could impact the mouse movement/clicking itself).

One thing to keep an eye on, in task manager (for instance)... Make sure XMBC's memory usage is not ever increasing. Best way to do this, on the process details page/tab just monitor the memory column for XMBC. Also its a good idea to turn on the "handles" column in there too - as that's something thing else that could "leak" over time - it should not but both memory leaks and handle leaks could be a significant problem (if it is happening). There certainly should be no reason for that in the release version 2.20.5 - it hasn't changed for >2 years, so if its suddenly broken, that suggests a Windows update or another piece of software is conflicting/causing problems - and that's a particularly difficult one for me to diagnose, especially if I can make it happen here!

Once it get to the point it is freezing/stuttering or whatever the symptom is, turning on debug logging and letting that collect some data for a few minutes, while exercising the mouse, showing the symptom, *may* help show what's going on internally, and focus the problem... But its possible that this wont really help all that much - but it's a good starting point I'd think.

[Emar]

Thanks Phil. Yeah for now it's still happening a bit, so I guess I have to wait around 10 or so days before I can see a significant change as that's around the time it takes for the issue to become noticeably bad.

Which memory should I track? Currently:
Working memory - 6364 KB
Private working memory - 3544 KB

When I checked Handles yesterday, it was around 460ish or 470ish. I used Scroll Lock to toggle XMB and since then, till now, it's remained at 451.

I wasn't tracking memory so no idea if the current values are what they should be, or if they increased/decreased.

One thing in Windows I notice is that it obviously becomes sluggish over time before you restart it. Probably due to swap/pagefile stuff. But I was chiefly investigating this over the past couple of years due to NVidia GPU shenanigans. Their drivers have been a colossal pain over the past 2 years or so, playing very badly with existing GOOD hardware (displays). The drivers of the past 2 years have begun this nasty habit of creating a weird delay everytime the display turns off and on (from inactivity, like 5-10 mins after). Only solution I found so far is to delete the resolutions saved in the display profiles with some specialised software (found the tutorial here: reddit[dot]com/r/nvidia/comments/198is3r/update_lg_monitors_causing_stuttering_fix/). Long story short, this is another example of some dumb stuff either on GPU or Windows side messing with good stable tools like XMB. I wonder if you could figure out what they've changed in the past few months that maybe hopefully you could work around during some refactoring.

Before I discovered that it was XMB disabling that "fixed" it, I had already tried deleting/reinstalling the mice and keyboard drivers but that made no difference either unfortunately.

What I do notice is that the stuttering gets slightly worse the longer a key is held, so I wonder if it's some kind of buffer that is getting slowed down but even then, why would it hit the mouse so hard? It's so strange, such interrupts shouldn't pose an issue to processors of today.

[phil]

To be honest, II completely missed the bit about it happening while the key i being held - didn't read the title properly.
That is interesting... XMBC does have a keyboard hook too, in order to capture layer modifier keys and the likes. It does nothing with them unless it is a layer modifier key, but maybe there is something in there that's going wrong.

Debug logging might provide some insight there too I guess (although I don't think it logs much - wouldn't want to be accused of key logging lol!).
Do you use layer modifier keys? Does it make any difference if you disable them (if enabled).
I'll have to have another scan through the code when I get a moment...

As for the memory, track both, working memory should be good enough though... Neither should increase much more than those levels - if there is an every going increase that does not come back down (I'd expect it to increase when opening the setup window and then it to fall when closing the setup window for instance!) it could be a sign of a memory leak, which over time could be a problem, but generally XMBC is pretty low on RAM and Ive been quite careful to avoid leaking resources generally. Same goes for the handles 450 is about what I'm seeing here so I'd say that's normal... if it goes up significantly without subsequently reducing that could be a sign of a problem.

[Emar]

Yup, not using layers and never used them.

Oh btw, I just remembered, I completely forgot to mention this. There are some apps, that, if they are in focus, the stuttering DOESN'T happen.

Only one I can reliably say is unaffected is old win32 apps such as Device Manager or Disk Management and the like.

What I also noticed is that Disk Management for example if I keep a key pressed (I'm usually using CTRL) and move the mouse around in the list of drives, the list will flash, as if it's refreshing (I mean I guess that's always happening, the master update() function or whatever) but it doesn't happen if I release the key. That also makes sense of course but obviously, I can only report this happening in the context of this issue, as I'd never have noticed before if it is normal or not. Either way, at least I can say that these win32 apps don't have the mouse stuttering under keypress but I mentioned the noticeable refresh in case you can glean any insight.

[Emar]

Hey Phil, I've sent you a screen recording in a private message, please do have a look!

[Emar]

Hi Phil, any chance you got to look at the video and this issue? It's still happening on the latest beta (updated today).

There was a brief moment where I updated my GPU (nvidia) driver and the issue was gone and would not come back, so I thought it had to do with that older driver and was happy. Until I restarted and we're back to the same issue.

Till now the only way to stop this is to close XMBC entirely.

Is there any lighter version I can try (with the modern efficient code if it was refactored over time)? E.g. I don't need the layers, never used that feature and don't plan to.

Some extraneous info: I tried HotKeyP but that seems unbelievably difficult to use so I gave up on that. It also seemed real janky, so couldn't get things to be as reliable. I tried MouseButtonsMapper from the Windows Store, but it, too, had this lag. However it was much less. I guess because it's a much simpler program. Either way, perhaps this gives some insight into the underlying mechanisms. At present my system has an ~11 day uptime, and as I've written before, this lag is not there on a fresh start; it comes about as the uptime increases. But I don't recall it at all from several years back otherwise I'd have made a thread back then. But older versions of XMBC have the same issue, so I dunno what Windows changed that's not playing well with this program.

Something I also noticed during tests is if I have 2 programs running, say X and Y. X does not have any profile, so no mouse remaps should apply to it (e.g. notepad). Y does have an UNDO that it will receive from Mouse button 4.

If X and Y are both running, with X in the foreground and Y in the background, and I press Mouse 4 on X, nothing happens as expected. But if I move my mouse to the background WITHOUT CLICKING, i.e. X is still in focus and Y is still inactive, then press Mouse 4 (for UNDO), then something interesting happens:

Y does not receive this input. Makes sense since Mouse 4 is not like the scrollwheel, or like LMB/RMB which change focus.
But X is suddenly receiving this UNDO command and is responding to it. If I bring the mouse back within the borders of app X, the UNDO no longer works.

Thought you might find this 'bug' interesting.

[phil]

I haven't had a chance to look in detail at it. Ive not had much time for XMBC at all recently and when I have had time, its been on fixing some issues I already had on the list.

Ive just had a quick look at it now, and its not obvious what is going on from that. I do see a few stutters I guess. Is there any high CPU loading going on (it might be useful to have task manager open on the performance tab (with "Show logical cpus" enable) to see if there are any CPU usage spikes happening at the same time the lag happens.. Or possibly even disk activity?

Its not something I have particularly noticed on my systems (some of which I keep running for some time (although do make use of sleep mode over night for example).

What I do see, if I am holding a key down whilst moving the mouse, XMBC does take 1% more CPU (1 instead of 0, or 2 instead of 1) so maybe there is something in that - but on my 9950x3d I'm not seeing any obvious lag (I will have to try it on some of my lesser machines!)

Regarding the later (X/Y) bit, if you have "Enable profile activation on mouse move" then that is expected behavior, as it will activate the profile for Y just by moving the mouse over it (not clicking it to gain focus of Y). So any button mappings for profile Y will become active.

You can turn that off - its the first option on the general settings tab. You can also turn it off per profile in the profile's options ("disable profile switching on mouse move for this profile")

[phil]

One thing to try - does it make a difference to the lag if "Enable profile activation on mouse move" is turned off?
Because with that enabled, as you move the mouse, its having to do some work every time it moves to determine if the profile under the cursor is different...

How many profiles do you have (the more there are, the slower it will be in theory). Might be worth sending me a copy of your settings in a PM too.. so I can see (some profiles can be worse than others, particularly if you have any that are restricted to specific window using window title matching, or window region matching).

[phil]

Can you see if it is any better in 2.21 Beta 56?
I did some performance profiling in the mouse movement handler and found a few issues and hopefully gains. So it should be even more efficient now, and maybe that will help.