Forum Replies Created
-
Posts
-
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?
Hi,
how are you trying to connect? I.e are you starting the connection manually or are you trying to connect to a LAN-based machine (mDNS). Are you connecting through WAN? What is the exact error message you are seeing when trying to connect? A screenshot is useful in this case.
We are not able to reproduce this. Is the display scaling enabled on Fedora? What is the output of the following commands, executed in a terminal on Fedora?
xrdb -query | grep dpi xdpyinfo | grep dotsWhat is the dongle model?
Please also show us the output of this command:
find /sys/devices -name edid -exec sh -c ‘echo “{}”; sudo cat {} | hexdump -C; echo “Missing EDID.”‘ \;
Please also try the first solution indicated in the following article:
Hi, what you are aiming to achieve is totally possible. Unfortunately, we have a couple of Trouble Reports open which might be your case.
Name of webcam devices is incorrect on client side
https://kb.nomachine.com/TR04U10846Multi-forwarding does not work on Mac when one of the devices is USB 3.0 pendrive
https://kb.nomachine.com/TR03S10152Hi, we just released 9.3. Could you update first and try to reproduce the problem? If you do, we’ll need to see the logs to be able to understand better.
To do that go to the target machine, in Settings > Server > Security , set the logs to debug level (you have to scroll down in the Security panel), restart nxserver, reproduce the problem and then “Take logs”. Share that entire file that you save. For full instructions, please see here: https://kb.nomachine.com/DT08U00298#1.
The system logs from journalctl would be useful as well. You can attach the files here, or send direct to forum[at]nomachine[dot]com. Thanks!
Jesse, we confirm that your are experiencing the same bug as reported here: https://kb.nomachine.com/TR11W11619
The next maintenance will include the fix, so watch out for the 9.3 release.
Can you also send us the client side logs whilst your connected to the remote desktop? Start the session, open the session menu (Ctrl-Alt-0) > Connection info. Save the file. You can submit it here or send to forum[at]nomachine[dot]com. Please use the title of this topic if you choose the latter option. Thanks!