Input System Freezes and Stops Registering Input

Hi,

I'm having a problem with the new input system. In my game, the input gets read every update through InputAction.ReadValue, and everything works fine. But after about 20 seconds of playing, the inputs stop registering for around 10 seconds before registering again and everything works as normal.

When the input stops registering, it freezes, the ReadValue returns the same value over and over, regardless of whatever I'm actually pressing on the keyboard. I'm 95% sure that this is a problem with the Input System, as the delay happens after all of the loading and other lag-inducing processes happen inside my game.

I've tried looking at the Input Debugger, but it also doesn't show any new input while I experience the freezes.

Hopefully someone else has a similar experience or a possible solution, I've been tearing my hair out over this!

 

I have this too. Mine freezes for some 5 seconds. It seems that it only freezes once in the entire session.

[whydotheforumsnothavestrikethroughsgoddamit]Problem is: I updated to 2019.3 and to a new version of the Input System package at the same time, and I can't be bothered to downgrade either to test.[/strike] Ah, screw it, I'll try downgrading the package.

 

I was using 2019.1.14f1 and 1.0.0-preview.5. I updated to 2019.3.10f1 and 1.0.0-preview.7 and started having this issue. I downgraded to 1.0.0-preview.5 in 2019.3.10f1 and continued having this issue. I can only conclude that the bug was introduced in the native backend in 2019.2 or 2019.3.

 

Strike that too. After actually restarting the Editor between package version changes, the issue magically went away. This is more inconsistent than whether my coroutine will decide to inexplicably stop halfway through.

 

@SpiccyMayonnaise and @Ramobo, have you been seeing the issue *only* in the editor and in combination with package upgrades or also in players?

But the devices were still there?

My first suspicion was that the domain reload between package upgrades went sideways and that the system lost its data in the process. ATM the domain reload logic in the input system is not equipped to also handle version changes. So if the serialized data from before the domain reload is from an old version and there is a new version that expects different data, the system is likely to just lose its devices and then not do much of anything anymore.

 

As I said, the issue just magically went away after I messed with the package versions trying to find which one introduced the bug. I did restart the editor a few times ever since the bug started, but before this test, so that probably didn't have anything to do with it.

It happened in the editor and I didn't export any builds while the bug was occurring, so I don't know whether it happens in builds.

Now that I think about it, I do have domain and scene reload disabled. Is the Input System fully compatible with this?

 

OK, so I have just upgraded to the 1.0.0 release of the Input System package, and the problem appears to have gone away. Note that I had to restart Unity as well.

Yes, I could see my mouse and keyboard in the list, but there was no input coming through.

Anyways, the problem seems to have just fixed itself, perhaps the new release made it go away. I'll update this thread if the problem comes back.

 

Ok cool, thanks.

Officially, no. We have a work item in the list to explicitly add support. Several users have reported it working already but that'd be more accidental than intentional at this point.

 

Bad news.

The problem cropped up again, however it went away immediately after restarting the editor.
It was not upgrading the package version that fixed it earlier, rather it was me restarting my editor after upgrading.

Not sure what causes it to happen in the first place, but if I just have to restart the editor every couple of days, I can deal with it.

 

we are experiencing something similar too, just 5 seconds of freezing randomly, not on all the PCs, just some of our colleagues. We use 2020.1 and rewired.

PS.: it's just the mouse to freeze, the keyboard input is fine

 

Hi I have been receiving this bug for months now. I thought the latest update would fix this but the problem is still there.
It works for few seconds after play, freezes for a few seconds, then works again after that. The thing is the mouse in the input debugger also wont get any update during the freeze.

 

Update since I forgot about this: Our problem was caused by the native layer of Rewired. Once switched to Unity input, the freeze disappeared.

 

There a no known issues with Rewired and mouse input. It has been unchanged for years.

This problem sounds suspiciously similar to this one which I tracked down to a change in the Unity editor causing it:
https://guavaman.com/projects/rewir...#windows-editor-keyboard-keys-stuck-raw-input

The old Unity input system and the new one work differently with regard to mouse input. The new one uses Raw Input, the old one used a different API as far as I was able to tell based on my testing which would not be susceptible to this issue.

There's nothing Rewired is doing that could directly cause this.

 

Also ran into this issue. Same deal as what others have said; input stops registering for a few seconds in the editor after about ~20 seconds of hitting play. Everything works fine after those few seconds. Only resolution seems to be restarting the editor, but it then crops up again later.

 

I had the same issue as mentioned here. Problem seems to be solved with most recent update 2020.20f1 and Input System 1.0.1.

Edit: the problem has not been solved. I guess restarting the editor did the trick as some others mention, but only for a little while.

 

I am not sure I have been clear, but just in case: We are still using rewired, we didn't replace it. We just stopped using the direct hardware layer and enabled the unity input option within rewired itself. Sorry, I don't remember right now the correct names of the options. Just a check solved the problem, if it's not in the native layer of rewired, I have no clue where it can be. Just a reminder that the problem was happening with specific hardware configurations.

 

I understood that. Disabling Rewired's native input is essentially crippling the whole system because native input provides so much functionality that is not available through UnityEngine.Input. I never consider disabling native input a viable solution to problems. It's akin to an emergency shutoff switch, but should not be used under 99% of circumstances in my view.

What I was trying to explain to you is that Rewired itself is probably not doing anything to cause it. It's the confluence of Rewired native API calls to Windows and the Unity's and/or the Unity editor's. This has been the root cause of many problems in many different ways. It's not something Rewired is doing, but what Rewired is doing is being affected by what Unity is doing. Here's another example I ran into.

Rewired's native XInput implementation implements a separate output thread for handing vibrations so the main render thread is never affected by slow responses from XInput when sending a vibration. It was reported to me that some game was having a 3-4 second period of frame-rate crashing lag on the main thread when sending vibrations in rapid succession with a specific device and then forcibly removing the battery to disconnect the device (or the battery just dies). I knew I had already spent countless hours refining and honing the XInput implementation to avoid all possible main thread delays due to vibration as this issue came up years ago when the Xbox One devices were released. They behaved worse than Xbox 360 devices, requiring the multi-threaded approach to prevent issues. Well, I was seeing the same old frame-capping behavior when sending vibrations again even though I had already implemented multi-threaded input and output. I debugged down at every level to find out what was possibly causing this lag as it made no sense that it would be stalling the main thread. There was zero code in Rewired that was accessing XInput from the main thread. Then I realized -- UNITY also makes calls to XInput. Based on my testing, they make calls to XInput from the main render thread. That was what was causing the 3-4 second stall. Not Rewired, not Unity, but the combination of making Set Vibration calls through Rewired on a separate thread while Unity makes calls to get input from the device on the main thread. The device was gone from XInput, yet it still reported it present and was accepting SetVibration calls with no error, but with a long thread stall on each call. Rewired's calls didn't affect the frame rate because it was making them on a separate thread, but then Unity makes calls to get input from XInput on the main thread, and those calls also lagged out while the device was in this limbo state, stalling out the render thread. So, no, this was not a problem with Rewired. It was an artifact that Unity runs at the same time as Rewired. Low-level API issues may bubble up through both systems.

The example I sent you in the link about Raw Input keyboard lag is another very similar situation. This has come up enough times in enough different forms that it's now become my first suspicion to issues like the one you are reporting, especially when they seemingly pop up out of nowhere when nothing has changed but the version of Unity you are using.

 

OK I am not sure how similar the example you posted is. I am sorry in case you got this too, but the frame rate was not affected at all as well as the CPU load. It was just the mouse to freeze otherwise everything else worked fine (including keyboard input)

 

I wasn't intending that example to explain your exact problem, only to be a point of reference to see how something Unity does with a native API may result in some side effect that makes it look like Rewired is causing a problem. The keyboard lag example with Raw Input is much closer to what you are describing.

Is this happening in the Unity Editor only or in game builds? I have no way to reproduce it so I have no way of debugging this new Unity version-related problem.

 

it's very hard to repro as we had difficulties to repro on different machines using the same mouse as well, but at least you need to have that specific mouse model (Mad Catz RAT 8+). If I remember correctly it was happening in the editor as well as on the client.

 

I understand. Thanks for the info. Judging by the fact that it affects both Rewired and the new input system which also uses Raw Input as noted in this thread, I'm going to guess it's a general problem with that mouse or certain other mice and / or drivers, possibly due to some Windows update as I've never had reports like this before. That's a very common occurrence -- for Windows updates to introduce issues into perfectly legal Windows API usage.

 

that's what I suspected as well, but a lack of people complaining about it with other games, made me investigate the rewired settings (the mouse drivers were up to date).

I did find this review for a 6+ mouse on Amazon that was exactly what we had though:

The positives mostly end there I'm afraid. If you are a Windows user, you'll probably find you will have issues with this due to driver conflicts. I have yet to find out what driver is conflicting, but what I can say is that on essentially every Windows machine I have, this mouse works for about 20 minutes before it seems to freeze - you will not be able to use it for about 5 seconds, then it will reconnect.

 

@sebas77 If you do want to disable native input, be sure you only disable Native Mouse Handling under the Windows section of the Settings page. This will fall back on UnityEngine.Input's mouse input, but it won't disable any of the other native code for joysticks.

 

Hi I am currently facing the same issue, in unity version 2020.2.4f1 only when using the keyboard. As said previously the problem occurs once per execution and using the Input Debug I can confirm that no keys are being registered in these 5/6 seconds. Since I use the input system for a car controller, this is some game-breaking bug making me reconsider the old but stable input system :/

 

As far as I am aware (and I've been using Unity's new Input System for a while now), this bug does not happen in builds. So really it's more of an in-editor annoyance, rather than anything to actually be worried about.

I can tell you this, though:
- The freeze only happens once per play mode execution.
- The freeze length is proportional to how long the unity editor has been open. (I.E. if you leave Unity running overnight the freeze will be very long).

Thus, as long as you make it a rule of thumb to close down the Unity Editor whenever you aren't using it — this bug really isn't all that much of a problem!

 

If this happens only in the editor and not builds, it does indeed sound very, very similar to the editor Raw Input bug I mentioned in a post above. It fits perfectly with the symptoms. I first saw this new bug appear in 2019.3.8. Newer versions of the Unity editor seem to be stalling delivery of the Raw Input events from the Windows message queue under some unknown circumstances. Older versions of the Unity editor never had this problem. Your description of the stall being proportional to how long the editor has been open is very similar to the original symptom of the stall being related to how long a key was pressed before being released causing the stall on release to last an equivalent amount of time. Sounds to me like change that caused the original symptoms I saw in 2019.3.8 was modified in some way over time to result in these new, but similar symptoms.

 

Just writing here to confirm similar behavior in the latest alpha (2021.2.0a10.1508). Using the new input system, I can see in the input debug window events flowing in as I punch the keyboard immediately after entering Play Mode. However, a few seconds in, the inputs cease to occur. Nothing is visible even in input debug window. Then, after few more seconds, everything starts rolling again.

 

Any update on this that anyone is aware of?

 

I am also experiencing this issue with Unity 2021.1.4f1 and Input System 1.0.2. Input is detected when entering play mode and about 5 seconds later it stops detecting input for around 10 seconds and then works back again.

I am also experiencing issues with android builds where input is detected normally but at some times it detects when a touch has started and then doesn't detect the touch cancel.

 

Same here.

 

Might be unrelated, but I'm getting different freezing issues in the following situations:
1. Running the application on a Samsung Galaxy S10 or S20
2. Pressing the back button on a Google Pixel

Both these cause the Input System to not register any inputs.

Edit: Unity 2020.3.0f1, InputSystem 1.0.2

 

I've been having this problem since we've switched our project over to the new input system a few months ago. Currently using Unity 2020.1.14f1 and Input System 1.0.2.

I will say it impacts both my mouse and keyboard input. Not sure if it matters, but I have a Corsair mouse and keyboard that use their iCUE software.

 

I'm getting this too, as is another dev on our project. Often wastes 30 seconds when trying to test stuff, which often happens many times a day. A few seconds may not seem a big deal but it can add up to hours per week depending on what you're doing.

@Rene-Damm, is Unity paying attention to this?

Seems to impact keyboard input, but not gamepad - at least for me.

I posted my own thread on it a few weeks ago.

 

Oh, one thing I've noticed is that when the new InputSystem locks up, a couple of actions I have hooked up to old Input class stuff still work fine.

 

I also have this issue. Really annoying.

Any buttons pressed are no longer discovered both on my mouse and my keyboard
(but moving the movement of the mouse is still discovered).

Interesting... I also have a Corsair RGB Harpoon mouse but not with the iCUE software installed.

 

@Rene-Damm Please help us

 

This happened to me every single time I hit Play yesterday. I was hooking up and testing UI flow, so I had to do that a lot. I didn't have a gamepad available, but even if I did I also needed to test keyboard input, too.

@Rene-Damm, is the InputSystem still a thing you're working on?

 

Huh, nobody here has mentioned making a bug report, so I'm going to go do that.

 

@angrypenguin Do you also have a Corsair mouse and/or keyboard?

 

No, I don't.

 

I've been getting responses to my bug report, though no luck with having them actually identify the issue so far.

I had already sent them a repro project, but the upload failed. They certainly don't make that process easy!

They've asked for more info, so I've suggested for the second time that they get in this thread where others are also reporting it.

 

More info, and some Unity responses from this year, over in this thread. Also a request for repro projects, if you've got 'em.

 

Thanks for linking that thread as well.

Sadly I cannot share my repo and it doesn't happen on my partner's machine. Something I recently noticed was that click input still works through the editor panes. What I mean by that is that in our game, you click where you want the player to go, but when the issue is going on, the inputs are ignored however if I click in certain areas of the unity editor (see screenshots below for example) the click does get registered in-game and my player will walk in that direction. This doesn't fix the issue though I still have to wait some time. Also, this makes the game loose focus and so it only works on the first click

 

I guess unity just doesnt care, how to avoid this.. Just dont use the new input system maybe?

Edit: It stopped happening to me, but I will mention I restarted unity, restarting always works, and keeps the problem away for awhile. It might have something to do with me logging out and logging back into other windows users, letting the PC sleep.

 

The Input System team does care, they just have a lot on their plate. Rene-Damm has looked into this issue multiple times in the past and just recently he is looking into this issue again.

And remember — this bug is an Editor issue and in no way effects the built project. I would hardly call that a deal breaker for whether or not to use the new Input System.

 

That's not true, I've been having this issue in final builds. All of my "button" type inputs work, but "passthrough" types are only sending a message for their initial state. Restarting Unity does nothing since this happens to me in actual builds, but restarting my computer fixes the issue. I also have made sure I have zero game controllers or auxiliary gamepads plugged in, and Unity's input system is set to only keyboard and mouse anyway.

I've tried refactoring my player input controller multiple times, but the results are always varying because sometimes "passthrough" inputs (WASD) will send continuous information, and other times it will only send a flicker for a single frame about every 15-20 seconds. I'd consider that to be fairly broken.

I'm able to use WASD in other games, and able to use other buttons like M or P to toggle GUI elements but I can't for the life of me figure out why the Input System randomly decides to ignore continuous input messages. I made sure to enable the action in OnEnable and subscribe to them, catching the context callback and still no information or feedback about what is going on. The fact that it will randomly work for a single frame reassures me that there is nothing wrong with the code, and the fact that I've play tested countless hours with no issues and this started happening while working on a completely separate independent system (grass shaders).

Until I can find a solution that doesn't require me shutting down my entire work environment and loosing my mental footing for what I'm working on, this is absolutely a deal breaker.

Edit: I should mention that I've seen the post about time drift and while it does sound like that is the cause of my issue, that still leaves me in as place where my only solution is restarting my system until Unity decide it's a big enough issue for them

 

Okay.

Hmm...
To me, this actually sounds like a different issue than the one this thread (or the thread you and I referenced) is about.

You might want to make your own thread about this particular issue and see if you can get the Unity Team's attention. I'm sure they'd love to take a look at it!

 

Have you submitted a bug report? The best way to get Unity's team attention if you actually tell and demonstrate them that you have an issue. Especially since you suspect that it is not something already acknowledged here.

 

No.
I have not submitted a bug report as I have not yet experienced @caliberbeats bug and do not know how to reproduce @caliberbeats bug in order to make a bug report. However, if I run into it I will attempt to report it.

I do not have an issue.

I suspect that this is a new bug because the description of @caliberbeats bug does not match the symptoms of the bug described here in this thread.

This is why I recommended that @caliberbeats should start a new thread dedicated to this bug (preferably with a bug report or repro, of course. However I should have made that advice explicit).

 

Sorry, I was dumb, I didn't indicate exactly that I only used your quote as an emphasis on getting attention. I mainly tried to ask @caliberbeats.