Forum Replies Created
-
Posts
-
Sorry Timo, I missed your last question. The fix will not be a “quirk”. We are currently working on adding full support for virtual desktops for Wayland.
Not being able to resize in this case is not caused by NoMachine. NoMachine shows you the available resolutions which are those supported by the graphics cards and the remote OS.
Hi, are you able to send us the full set of logs from the Mac machine so we can check them? You can extract them using the instructions here: https://kb.nomachine.com/DT08U00298#1.1 and setting the log level to 9 (Debug) and restart the server. Reproduce the problem as per your steps, then take the logs. Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
Hi, are you able to send us the full set of logs from the Windows machine so we can check them? You can extract them using the instructions here: https://kb.nomachine.com/DT08U00298#1.1 and setting the log level to 9 (Debug) and restart the server. Reproduce the problem, then take the logs. Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
Hi, thanks for the client side logs. Can you send us the logs from the server as well? You can get them through the UI on the Rocky server: Settings > Server > Security > Take logs, reproduce the problem first and then click Take logs.
Hi, just so it’s clear for us, if you take out Zerotier completely, are you able to connect from PCs 2 and 3 to PC 4 at all? We’ll check out ZT again in any case.
In the meantime, what you could try is, in the server.cfg file, to set the IP address which has to be broadcast by uncommenting the following key:
#
# Specify the network interface where the NX service will be bound.
# Populate the field with an IP address or a domain name.
#
#NXdListenAddress “”Restart the nxserver after making the changes.
Logs show that the older libnxegl is being loaded. Did you reboot after updating? Logging out and logging back in on the physical desktop can work as well, but a reboot can fix it.
If after rebooting you still get the white screen, we’ll need new logs.
Good to know it’s working. We got the logs, but the agent logs were missing. If it happens again, send us new logs. First, set ‘SessionLogClean 0’ in /usr/NX/etc/node.cfg to avoid they are automatically cleaned up.
Can you tell us if it was the reboot that worked, or did you have to set “
--eglcapture no“? It would also be useful to know, for our internal investigation, which apps were problematic. Thanks.Hi, can you send us the logs from the server machine? Set the log level to debug, restart the server, reproduce the problem, then gather the logs. Please follow the instructions here: https://kb.nomachine.com/DT08U00298#1.1. Send them to forum[at]nomachine[dot]com using the title of this topic as the subject of your email. Thanks!
Hi, after updating to 9.3, did you reboot the server machine? If not, try that. If rebooting does not help, please run the command
sudo /usr/NX/bin/nxserver --eglcapture no, then logout and log back in from the system, or reboot. Does that help?Hi,
Is there a way to force NoMachine to use pure VA-API (via libva) instead of going through the “libmfx” wrapper?
Unfortunately, no, although there is good news. We are currently working on support for the VA-API encoder. This will be made available in the one of our releases next year.
Can I manually limit the quality_level (Target Usage) in node.cfg to prevent this assertion failure?
No, but NoMachine does not use this buffer. It’s worth noting that MFX/VPL Intel HW encoders are mostly made for iHD drivers, not i965.
If I disable NoMachine’s internal “libmfx.so”, it defaults to software encoding. Is there any workaround to make it recognize the “i965” VA-API backend directly?
Are you asking how to changing to i965 from iHD? Please check the article in our knowledge base which contains everything you need to know about Intel HW encoding and currently supported API, http://www.nomachine.com/AR09O00938, but there’s also the LIBVA_DRIVER_NAME environment variable where you can set whatever driver you want to be loaded. You can try that.
Hi, our initial tests show that using the compositor or the EGL method does not work whilst the DRM screen capture method does. Please enable it by editing /usr/NX/etc/node.cfg and setting the WaylandModes key by removing the pre-pending # from the key name
WaylandModes drm. You can also try to use GPU non-proprietary drivers. In some cases DRM can fail when AMD drivers are used.Hi, the disabling of HW encoding and HW acceleration should be done on the target host as a first attempt to debug the issue. If that didn’t change anything, it’s possible that the problem is actually on the client side, on the OS you are connecting from. In fact you mention that you can connect from other clients without problems. It is just the one Ubuntu 24.04 client is problematic.
Try disabling hardware decoding on the client side player menu while in session: Menu > Display settings > Modify> ”Disable client side hardware decoding”. Does this help?