Forum Replies Created
-
Posts
-
Hi, we aren’t aware of similar issues on Windows 11. Are you able to send us the server-side logs from the Windows machine, so we can check them? You can extract them using the instructions here: https://kb.nomachine.com/DT07S00243.
Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
OneVPL is now the replacement to MediaSDK.
Indeed. In fact support for OneVPL will be added in the next update (coming soon).
Electrosaur, write to us using Contact Us in the footer, select General Enquiries, tell us what package type you need, and we’ll send you the link.
Gerard, you already opened the topic which is handling the audio issue, so we’ll continue with that in your other thread.
Can you tell us what configuration you have in order to get 30 bit per pixel? We can verify it first in our labs.
We’re checking the Quick Sync error. With regards to audio, can you tell us the distribution and version, display manager/desktop environment?
The logs show that the issue is actually a different one. This https://www.nomachine.com/TR03U10784. Support for 10 bits channels is planned, most likely in one of the minor releases of the v9 tree.
Hi, thanks for the submitting the logs. The agent logs were missing unfortunately (which we need), but in the server logs we can see the following errors:
7901 259 2024-03-23 04:06:03 608.263 Socket: ERROR! Can’t execute the sysctl request.
7901 259 2024-03-23 04:06:03 620.942 Socket: ERROR! Error is 12 ‘Cannot allocate memory’.What we don’t know if this is due to system memory being exhausted or whether you have a per-user limit, but it’s something you need to check. Then, please gather the logs (
--enableall as per the instructions) making sure not to remove the agent logs.Take a look at the article here “The password scrambling algorithm in NX Client”, https://kb.nomachine.com/AR01C00125
If it’s a headless Linux host you are connecting to, please follow the tips in the article here https://kb.nomachine.com/AR03P00973, specifically 1) Use a X virtual framebuffer.
Better would be to disable the display manager permanently, then the DM won’t start after reboot. This is the command
to disable and stop the DM:sudo systemctl disable --now[enter here display manager]
sudo /etc/NX/nxserver --restart(just once, after reboot all will be fine)Now when you connect, you should be able to start your session correctly.
If that doesn’t help, please submit the following information:
– NoMachine product and version on local and remote machine (free version, Workstation, etc).
– Whether the problem arises connecting to a physical or a virtual display.
– Remote and local Windows/Mac/Linux version (Windows XP/7/8, OS X 10.x, Ubuntu xyz, Mint x.y, etc.).
– Desktop version (GNOME. KDE, whatever) you are connecting to.
When you connect, are you seeing a black screen with a moving cursor, or are you seeing the desktop’s content which is frozen (except for the cursor). Is there a specific application running?
At the moment, in its current version, NoMachine considers the monitors as one big screen. What you need is for NoMachine to capture and encode each monitor as a separate video stream. Such a feature is planned and work has started, although we are unable to provide a target version.
The logs confirm the problems we already know about. About the version, I was referring to 535 official NVIDIA drivers. Thanks for the pointing out that Ubuntu’s own 535 doesn’t fix the problem.
It’s likely you have the same problem on all the machines from which you are pulling the monitor out of. And it’s not related to NoMachine, but the system. Rather than just pull the HDMI out, disable the Xserver correctly first and then detach the monitor. It’s option 3 in the article you mentioned (for headless Linux), the section “Use a X virtual framebuffer” which explains how to stop the display manager.
First check what display manager you have in a terminal: ps aux|grep dm
Then stop it. When you stop the display manager, you are stopping it forcibly until the machine gets rebooted. It’s not permanent. It will start up again at next reboot. An important point here to note is that when you stop any DM, NoMachine cannot know that someone stopped it because the system does not send such information to NoMachine. That’s why NoMachine (the nxserver) must be restarted.
Better would be to disable the display manager permanently, then the DM won’t start after reboot. This is the command
to disable and stop the DM:sudo systemctl disable --now[enter here display manager]
sudo /etc/NX/nxserver --restart(just once, after reboot all will be fine)Now when you connect, you should be able to start your session correctly.
For Windows, as explained here: https://kb.nomachine.com/AR05S01124 NoMachine is made to work out-of-the-box, but a black screen may occur in some cases. So in your case closing the lid effectively means NoMachine can’t find any GPU running there and you’re seeing a black screen. Either you keep the lid open or you attach a dongle.
We do considerable testing on headless mini PCs 😉
I suggest you look at the article dedicated to headless Linux https://kb.nomachine.com/AR03P00973
In our tests everything works as expected. What we need from you:
1) server side logs whilst producing the
I think logs from server side would be needed. Reproduce the problem and when you do reproduce, don’t disconnect. Just tar the .nx folder on the Lubuntu server side and send to us. Plus the player logs from that session on the connecting client side. How to do that is explained in the following document.
You can extract them using the instructions here: https://kb.nomachine.com/DT07S00243
Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email.
Then, the output of this command:
ps -ef |grep -E "X|dm|lxqt"Thanks.