Forum Replies Created
-
Posts
-
I’m willing to try that idea, but I don’t think I could use it as a long-term solution. One of the reasons I wanted to switch back to !M from X2go (the main reason is security!) was so that I could keep the same session up at all times. I lock it at home, go to work and connect to the same session from the office.
Do I understand the idea of that knowlegebase article correctly?
Hard to say, I’m not exactly clear on what is meant by using “a USB device is connected inside the NoMachine session”. Also, the fact that the keyboard and mouse make that ticket’s symptoms go away for a while is not the same as what I’m seeing. I do have a USB keyboard, mouse, Plantronics headset, and Imprivata badge reader at the Windows client, but none of those are exported to the remote computer. I don’t think it matters what’s on the remote Linux computer, but there I have a USB keyboard, mouse, and a MIDI controller.
Hi, I was able to test disabling UDP today, and unfortunately did not see any change in behavior. I will continue to test with UDP disabled, but it doesn’t look promising. Any other thoughts? Other logging I can capture?
I’ve narrowed it down to one specific action that always gets rid of the 5 second response lag problem.
My standard procedure was to connect with the Resize remote screen disabled in the client, and then I was maximizing the client window (not selecting Fullscreen mode). All of this kept whatever screen sizing was already on the server as is.
What I’ve discovered is that as soon as I do anything that causes the the server screen sizing to adjust, it seems to “connect” the client and server screens in some special way and eliminates the 5 second response lag.
So, now I am keeping Resize remote screen enabled on the client all the time, and as long as there is some kind of screen size synchronization between the client and the server, there is no 5 second response lag. Without knowing more about the inner workings of the protocol I can’t explain why this works, but it does.
I was able to eliminate the problem by toggling the Resize Remote Screen setting a couple of times, and it’s possible that toggling the Fullscreen setting was involved as well. I’ve captured the same logs and session statistics (sent in another email) now that there is not the 5 second lag, hoping that this will help identify the exact cause. I will continue to test! -Ross
Log and session statistics files just sent, thanks for looking at this with me.
Interestingly, there was a brief time yesterday afternoon when the 5 second lag went away, so I’m hopeful that means there is a way to resolve this. I kept the session open for a couple of hours and unlocked the screensaver periodically to work on it. One of the times I unlocked the screensaver, the session did not have the lag! I was able to freely click around, run commands, use the mouse wheel to scroll, all without significant lag. The next time I unlocked the screensaver, though, it was back to the 5 second lag for each input. Same for rest of yesterday and this morning.
One final piece of information, on the reverse connection, with my home Ubuntu workstation as client and my work Win10 workstation as server, there was no lag.