100% agree with everything you say. Mine disappeared after changing PC.
There is one thing you might want to look into. There’s an option somewhere in the engine that instructs the Unreal instance to use less processors when not ‘focused’, you may want to try to de-activate the options and see if it makes any difference?
@Frozenfire do you have an oculus rift (or perhaps a Vive) connected to the computer that had the issue?
I attached a debugger and broke when UE4 locks up and I see it’s waiting on a thread to finish and found there’s a lot of Oculus calls in the stack. I disconnected my Oculus rift and the issue went away. So it seems there needs to be some check or something.
Hopefully this will give the Epic devs a way to reproduce the issue consistently.
@tmek thank you for reaching out.
I’m glad I’m hearing some people in the community who are facing this and solved them. However I am not an oculus user. I do have the driver installed.
What you’ve pointed out does not appear to be a bug.
The Render Thread and Game Thread work in parallel, but in lock step. That is, we process frame by frame. We do this to prevent cases where one thread is working faster than the other and wasting resources. If the game thread hasn’t processed a new frame’s data, the render thread can’t do anything because there won’t be updates. If the render thread hasn’t finished with the last frame, the game thread won’t continue because the data we just processed could be lost.
When work is distributed evenly, this isn’t much of a problem. The system can move along at a fast rate because things are being processed in parallel.
Things can become a little weird when using an HMD (Head Mounted Display).
There are specific characterstics needed for HMDs to prevent motion sickness. One of these things is fixed framerate. Most systems try to run at a locked 90 FPS (or 45 FPS with things like Oculus’ SpaceWarp). Because of this, the engine will try to lock it’s rendering to the rate the HMD can handle to avoid unnecessary work.
Unlike standard display devices which will typically be persistently enabled while in development, many HMDs have sensors that track when the device is put on and taken off.
If you haven’t explicitly told the engine not to rely on VR / HMDs, then once it detects that an HMD is in use it will try and lock rendering to the frame rate of the HMD. Because the Render Thread is waiting for the display, the game thread is also sitting idle (which could then cause the warnings).
In this case, removing the headset removes this bottle neck. Another approach would be to disable VR settings through the Engine:
Thanks,
Jon N.
I have to confirm: disconnecting HDMI for Oculus resolved the issue.
Hi, I wanted to share here my experience with that issue.
I am on 4.18.3 and I encountered this same message on my log
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 30.23, Realtime: 30.18. IpNetDriver_1
When I first open the project and start the preview (in my case VR) it runs perfectly. I open a level in a glimpse. But on furthur attemps i am starting to have the freezing issue long timelapse and the message above.
Every time I restart the project, it works fine again.
So it’s like that IpNetDriver that doesn’t like to iterate more than once…(I mean it works fine only when it’s IpNetDriver_0)
Sorry I ve not seen that it was what tmek resumed in the point 5 of his post of Dec 30 '17 at 5:57 PM.
I am facing the exact same problem. Did you find a solution yet, other than disabling the rift? I am currently developing a multiplayer vr game for my masters thesis so i need the oculus rift + sessions.
Faced the same problem at 4.19. The thing that helped me is to disable MasterEQ in the setting.
For testing time in the project config DefaultEngine.ini I added:
[/script/engine.audiosettings]
bDisableMasterEQ=True
Hope it will help someone!
Removing Oculus HDMI helped me. Thanks