Hi @Nonlin ,
Nope never did , asked everybody I know , nobody in the community had any idea. Apparently it’s happening to ATI cards only I read. Are you using ATI card?
@Rhynehall,
I don’t believe it has a specific solution. It dissappeared on my when I switch PC. It’s card related to me. Are you using ATI? It’s ONLY happening with network for me.
If I found a way to reproduce I’ll submit a separate bug report. Do you have any extra info on it?
I get exactly the same problem here, I run a server & client.
All is going good, after have play some secs or mins it start to freeze randomly with the long ticks message.
I can wait the freeze and continue to play, sometimes it seen to go ok and I can play a longtime.
When I run only one instance of my project I get 120 fps or over.
When I run two instance with the multiplayer it running at around 60 70 fps.
I have try many configuration about the PIE mode but nothing really change.
I don’t have get the chance to test my project over the internet or on lan with multiple computers.
I have only test my project in the same computer.
I use unreal engine 4.18.1 with a nvidia 1060 gtx
You can see here in this video at 1:34secs and at 4:21secs and at 10:23 secs…
Some time the freeze is more long it never exactly same.
Apologies as I’ve missed out the reply. Thank you for your respond.
Q: How many clients are you running? Does this occur when running one or two clients as well or only with more than that?
only when 2 or more…
Q: Which OSS are you working with?
4.15.1 Binary version
Q: Do you see any settings in your DefaultEngine.ini related to timeout, such as AsyncTimeout or P2PConnectionTimeout that you could potentially increase?
I have this under OnlineSystemSteam but I doubt it’s applicable in Editor
P2PConnectionTimeout=90, I will try increasing them. I also have “InitialConnectTimeout=120.0” under [/Script/OnlineSubsystemUtils.IpNetDriver] , what settings do you propose I increase and how much?
Was this ever resolved or figured out? I’m seeing the same thing in the Shooter Game in editor so far only.
Lots of
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 8.12, Realtime: 8.12. IpNetDriver_13
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 15.03, Realtime: 15.03. IpNetDriver_12
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 15.03, Realtime: 15.03. IpNetDriver_13
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 7.21, Realtime: 7.21. IpNetDriver_12
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 7.21, Realtime: 7.21. IpNetDriver_13
Hello,
The warning itself is fairly explanatory - the time between frames is really long (8 ~ 15 seconds in the cases you’ve pointed out).
Unfortunately, there could be a number of reasons for this:
-
If you’re running multiple instances of the Game / Editor, only the one in the foreground will have focus. This may include PIE sessions (although, it may not). When a instance of the Game or Editor is not in focus the OS (i.e. Windows) has the ability to, and almost always will, reduce the amount of CPU time given to that instance. This alone could legitimately cause the tick times between frames to drop to only a few times a second. In some cases, it may even be multiple seconds between frames.
-
Similarly, if you have other potentially intense software running on your PC at the same time (video capture, virus scanners, other computationally or graphically intense software, etc.) this could cause some issues (although I wouldn’t expect it to cause several seconds worth of hitching, unless it was a high priority process).
-
If you’re trying to do a lot of heavy lifting on a single PC that can’t handle it, resource contention may also be at play. With that in mind, what are the Specs of the PC you are using.
-
When Sean had asked about the OSS, he meant the Online Subsystem. Unfortunately, Binary 4.15.1 doesn’t really tell us what you’re using, as the OSS refers to specific platforms (Steam, Oculus, PS4, etc.) I’m going to guess you’re likely using the Null OSS (the unconfigured default), but please correct me if I’m wrong.
What I’d recommend is using the Stats system to determine where these hitches or delays are coming from.
What I’d start with is stat dumphitches to see if there’s any repeated offender. If that doesn’t make things clear, try waiting until your game instance is running very poorly and do a stat startfile, wait for a few seconds, and then do a stat stopfile. This will generate a stat capture which can be viewed in the Profiler tool and you can dig into what may be causing the issues.
As Sean has said, this very likely is not a bug in the engine itself. We do extensive regression testing before releases. While this process is not perfect and things can slip through, egregious issues like this are always grounds for Hotfixes, so if this was something found internally or by any of our licensees it would have been fixed.
That, given how easily you can repro it, I’m more inclined to believe it has something to do with your specific setup.
I already asked, but I figured I’d mention again so it’s not lost in a sea of text. Can you please provide the Specs of your machine, including your GPU, CPU, RAM, Operating System, etc.
Apparently the game freezes ( on both
clients ) together with the editor as
many seconds as it says hence it’s
impossible to debug anything when this
happens.
Even if the game freezes, you could still use stat dumphitches to get a report. You’d just need to make sure that was running before the hitch. E.G., you could start the game instances, immediately enable stat dumphitches, and then wait for a freeze.
Thanks,
Jon N.
After further investigation, it appears that this is not a bug. The reason for this is that when the client is running at low FPS it wont have any room to replicate because the actor replication is done in the game thread.
This is just a warning and should be safe to ignore unless it causes issues with actual functionality.
I think I have find from where the problem come in my project.
Thanks about all the profiling informations.
I’m pretty new with unreal, and really noob with the network stuff.
At the begin I have learn some methods to implement the multiplayer from youtube video.
After this I have start to rebuild my solo game to a multiplayer game.
To control the characters animation and rotation and more, All need to come replicated.
To do this I need to update all my replicated variables from the character tick… because the animation bp don’t replicate if i’m not wrong.
Because i’m new and from what I have learn at the begin… I have badly implement this tick part.
At the begin I have use a custom event for the server replications and one custom event for the remote client. This both custom event called on my character tick cause my lag problem and is my noob error 
All my characters animation appear to updating good anyway with my error but I don’t need this both custom event, Because my variable is all replicated. I only need to check authority and add all my anim and rotation data just after this. Now all seen to work like a charm and I can run 4 instances without lag or freeze.
Sorry about my english again, and many thanks for all informations in this post thread.
This seems to be an ongoing problem that only happens on some machines and some builds of UE4 but not others. (I do not think this should be marked as resolved. but i also agree these are the types of issues that are hard to address as they are hard to reproduce consistently).
My OS is win10pro64 build 16299.125) …
I do not get the issue on UE4.15.3
But I do get the issue on UE4.18.2
Here’s the steps I did to recreate the issue…
Create a brand new empty blueprint project, then set number of players to 2 and press play (everything works fine in this case with just 2.)
If I set numbers of players to 3 and press play the windows spawn but the editor (server) and both client windows lock up for 30 seconds and I see these messages in the log…
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 0.01, Realtime: 30.15. IpNetDriver_7
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 30.19, Realtime: 30.34. IpNetDriver_5
I’ve had someone else try on their machine machine and they had no problems on 4.18.2. So It seems this is something that only happens on certain machines (perhaps a bug in certain network drivers?)
The key points after reading everything above and what i’ve seen are:
- It doesn’t happen to everyone but it does seem to be affecting several people.
- For the people it affects the lockup happens when we go over 2 PIE instances (three players without dedicated, two players with dedicated server option)
- It’s a combination of UE4 version and something else (buggy network driver?) so it’s hard to reproduce.
- However even on my machine everything works fine in UE 4.15.3 but UE 4.18.2 locks up for 30 seconds. So if it is something like a buggy network driver UE4.15.3 is dealing with it better.
- Update: The lockup doesn’t happen on the first play attempt after launching the editor .exe with the project. But it happens every play attempt after.
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