Forum Replies Created
-
Posts
-
We’re analyzing the information you provided to us, so thank you, and now it’s a question of replicating the environment and reproducing the exact same errors. We’ll update the topic as soon as we can.
Yes it did, but my fault for not noticing that the document I indicated was not up-to-date. All v8 documents are aligned now.
Those commands are for running virtual desktop sessions which are available in all Terminal Server products. What you need to do is
By default, on Linux:
/usr/NX/bin/nxplayer --session <path to .nxs file>For more details check out this article https://kb.nomachine.com/AR04O00923. You may also be interested in this document which highlights what you can configure in your connection file: https://kb.nomachine.com/DT07S00240
The output didn’t proffer any useful hints unfortunately.
Completely disable hardware decoding on the client if you already didn’t do so by following the instructions here:
https://kb.nomachine.com/AR07U01202Attach gdb so we can get the dump of threads of the client not updating the screen:
$ sudo gdb -p <pid of the client process>
$ set height 0
$ set logging file /tmp/backtrace.txt
$ set logging on
$ threads apply all bt full
$ quitAlso, when the connection freezes, is the client still responsive? ie. Can you open the menu and interact with it? While the window appears to be frozen, is the CPU usage of the client process normal?
Decoding is disabled in the Player.cfg on the client side, the device that you are connecting from. There is an article you can check for the steps to follow:
How to disable hardware decoding on the client side
https://kb.nomachine.com/AR07U01202Apologies, the correct key is
EnableClientCredentialsStoring none. I realised my mistake when checking the server.cfg file. The key is present in your version. Just set it to none.Are you still getting the same error when running iHD_drv_video.so from /usr?
QuickSync/QuickSync: WARNING! Failed to set display handle. Error is -17: Device operation failure.Hi, this is a known issue and the fix will be in the next update.
Message “SELinux is preventing systemd from ioctl access on the file /usr/lib/systemd/system/nxserver.service” is issued on RHEL 9.3
https://kb.nomachine.com/TR02V11080In version 8 it is configured on the server side using the EnableCredentialsStoring key in the server.cfg. Also present in the free version.
The key to not store the credentials is set in the server.cfg on the server, not the player.cfg. Remove the key from the player.cfg, if you’ve added it, which is not required. Then try again. Restart the nxserver. If you are still being requested for the credentials, tell us
Client OS and version
Server OS and versionAlso submit the player.cfg and server/node cfg and we can check them. Send them to forum[at]nomachine[dot]com.
The output you pasted show that ihd is still being loaded from /opt/intel/mediasdk/lib64/iHD_drv_video.so. Try restarting nxserver again. Knowing its proxmox can make a difference yes. What’s the exact distro and display manager your replicating?
When you say client which machine are you referring to? The device you are connecting from or the device you are connecting to? Please tell us the version of NoMachine you are using on the client (where you start the connection) and the NoMachine server you are connecting to. I assumed you had installed v8 on both machines. If you are using a legacy version of NoMachine (prior to version 8), it’s better to submit your question to the team via the website. The forums are always dedicated to the latest version.
Right now the only way to have multiple monitors in a virtual desktop session is to connect from a client machine that has multiple monitors. It’s rather a unique use case, but we can evaluate whether to add the possibility to create virtual desktops with an arbitrary number of virtual monitors or not 🙂
There is a difference in what is printed in the earlier logs and what is printed in the example procedure (#post-47716).
Logs show:
libva info: VA-API version 1.19.0
libva info: Trying to open /opt/intel/mediasdk/lib64/iHD_drv_video.soYour example:
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.soIt’s a different libva version and also a different filepath for the iHD driver.
You should check that you don’t have mixed libva libraries. For example, if you’re using Debian/Ubuntu, from a shell run dpkg -l libva*. What’s the output?
Next, make sure you’re using the iHD driver that is being used in your example, which is
/usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so. A quick way to do that is to rename iHD_drv_video.so which is in/opt/intel/mediasdk/lib64/to something else, for example:cd /opt/intel/mediasdk/lib64/ mv iHD_drv_video.so iHD_drv_video.so.originaland restart NoMachine. Does that help?