Forum Replies Created
November 17, 2020 at 12:43 in reply to: 5 seconds lag when running Kubuntu with built in window server #30412
From what you both say, this looks like a problem with the video drivers rathen than with NoMachine. In one case I see this was fixed by plugging a HDMI, in the other case by rebooting and it is confirmed further by the fact that there is no delay when using the display server provided by NoMachine. In fact some drivers/cards can be fast at rendering but much slower when images have to be pulled back from the GPU. I would try to check for newer versions of proprietary or OSS drivers.
Unfortunately relevant logs are missing. Please select the ‘Don’t delete log files on exit’ checkbox as per instructions. Alternatively, you can gather logs before closing the player window, and even better if you could gather again also the server side logs (while the session is still running), so that we will have matching client-server logs. Thanks for cooperation!
we don’t reproduce this issue in our labs. Can you make an example of an effected application?
For a test, please enable the ‘Show remote cursor pointer’ option in the menu panel (https://www.nomachine.com/DT10O00156&dn=menu%20panel#3). Is the remote cursor image rendered correctly?
do you mean that you weren’t getting a black screen before the reboot? Is the server a headless machine?
Server side logs look clean. Can you send also client side logs? Instructions in https://www.nomachine.com/DT10O00163#2.
NoMachine will always use the same GPU used by Windows to render the desktop. To use the Nvidia GPU you should configure the system to do so. Similarly, NoMachine will offer the same resolutions made available by Windows (depending on the graphics card and drivers). In case the Windows machine you connect to is headless, that could be a reason why the set of resolutions is limited.
please try to add the following key in the /Applications/NoMachine.app/Contents/Frameworks/etc/node.cfg file on the server machine:
DisplayServerExtraOptions "-oldeventapi 1"
Restart NoMachine and see if anything changes.
I assume the Mac with the 2 monitors is on the server side. Can you show a screenshot of the Display settings panel of the session menu (the one you can see here: https://www.nomachine.com/DT10O00158&dn=menu%20panel#5.7)?
sorry for the delay. Did you also try to enable VirtualGL as suggested in one of the articles? More information about it here: https://www.nomachine.com/AR05P00982.
It must be something on the system blocking the port binding, most likely the firewall.October 12, 2020 at 11:50 in reply to: Disable encryption/compression when using SSH tunnel #29897
there is no option to disable encryption. Also compression can’t be disabled completely, but I’d strongly recommend to use NX compression anyway, as it is aware of the type of content trasported and thus it is much more efficient (and effective) than a general purpose compressor.
this is really strange even on a headless server. Please gather server side logs as explained in https://www.nomachine.com/AR10K00697. You can send them to forum[at]nomachine[dot]com.
the display service on the server can’t start up because it cannot find any free TCP port in the given range. This range can be modified to avoid conflicts with other applications as explained at point 6 of the following article:
However the fact that all those ports are unavailable is abnormal and it should be checked if there is an application that is misbehaving. You can see yourself what are the busy ports in the nxserver.log file:
2020-09-28 11:40:57 903.811 29296 NXNODE TCP port '7002' is used by another application. 2020-09-28 11:40:57 905.853 29296 NXNODE TCP port '7003' is used by another application. [...] 2020-09-28 11:40:58 376.810 29296 NXNODE TCP port '12200' is used by another application.
To check what application is keeping those ports busy you may try one of these methods:
Just to be sure that it is not related to a Cinnamon issue, can you tell us if restarting the NoMachine server only (without rebooting the machine) is enough to fix the problem? Also logs could be useful to understand better what is happening (https://www.nomachine.com/DT10O00163#1). You can send them to forum[at]nomachine[dot]com.