Forum Replies Created
-
Posts
-
Here, what’s important to consider is not necessarily how NoMachine performs when capturing and encoding the display, but rather the performance of the Gnome desktop with and without GPU encoding. You might find that Gnome performs substantially better with GPU. There are many variables to take into consideration and you need to test it on your own system in your own environment. You might find that a “lighter” desktop such as XFCE or Mate fits your use case better.
Hi, please take a look at the following article:
How to connect to Windows with NoMachine and an empty password
https://kb.nomachine.com/AR05L00802You have two options. Configure your account to use a password, which is strongly recommended, or configure your Windows OS to open the appropriate policy to allow remote access without a password.
Please disable HW encoding on the server side. Go to Server settings > Performance > make sure the box “Use hardware encoding” is not ticked. Does that help?
There are logs missing from the server side from user’s homedir/.nx. Additionally, you are using 8.11. It would be useful to update to 8.12 and get fresh logs with debug enabled. Make sure you zip up the entire .nx from the NoMachine Windows host you’re connecting to. You can extract them using the instructions here: https://kb.nomachine.com/DT07S00243.
Edit 10/10/24 – no new logs were received. We suggest to update to the latest 8.14 and if you continue to have issues, open a new topic with the full logs attached.
Are you using the default packages of MX Linux or did you apply all the updates?
Logs would be useful. Everything was fine and suddenly it wasn’t suggests that maybe some update broke something, maybe some drivers. To get NoMachine logs from the MX Linux installation, enable debug, reproduce the slowness and then zip up the logs. 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!
This seems to be related to your Linux host being headless, ie. without a monitor. You probably don’t have a monitor plugged in so, you should stop sddm and restart nxserver.
sudo services sddm stop sudo /etc/NX/nxserver --restartThen NoMachine will create its own virtual display. To avoid sddm restarting itself after a future reboot, disable it completely
sudo systemctl disable sddmInformation about headless hosts is available here: https://kb.nomachine.com/AR03P00973
Just to let you know we received the logs and will come back to you once developers have finished their analysis.
No, there isn’t right now, but we will add the possibility to configure one in the GUI. Thanks for the suggestion 🙂
Very strange. The slowness is what we would typically associate with not having a monitor attached. And XFCE is generally a well-supported desktop environment and is less resource-intensive (it also adapts well to headless machines). Also strange is that you said it was working well and then all of a sudden, sessions became slow.
Can you confirm, please, that you did indeed disable the HW encoding option the MX Linux host? Do that, restart the server, and then connect again, open the menu > Display > Change settings and take a screen.
As you can see, resource usage is very low and when interfacing directly with the machine it is entirely normal and snappy.
Just to make sure I understand, is local activity on the machine normal also when a NoMachine connection is active?
What happens if you connect from the MX linux as a client to one of your other NoMachine hosts?
NoMachine server requires admin permissions to be able to edit the settings. Check that you have admin rights for the username that you are logged in with. Go in to Users and Groups in your Mac settings and select the username/account that you are logged in with. Can you see a toggle button which is enabled next to “Allow this user to administer this computer”?
We’ve been able to reproduce unusual behaviour with KDE 6.1 as well, but not the exact same problem as yours. We will keep the investigation open for the time being and wait for KDE 6.2 to come out so that we can check against that.
Edit: KDE 6.2 was released, fixing https://bugs.kde.org/show_bug.cgi?id=489113
I have checked system resources and they are very low in use, I have run speed tests and I am getting normal speeds on this machine.
What do system resources actually show when you have a NoMachine session connected to the MX Linux host? What applications do you have running there when you connect? Can you try rebooting, opening no applications, and then connecting with nomachine? Leave the session open and observe what happens.
When I first installed MX Linux on this machine, I installed NoMachine the same way I usually do, and everything was fine for about two weeks.
So NoMachine was working. Do you remember updating anything or altering anything in the configuration before the slowness started?
Is the MX Linux host headless? If it is, does attaching a monitor make any difference? (see the following article for how to use NoMachine with headless hosts https://kb.nomachine.com/AR03P00973).
Disabling HW encoding on the server may help. It’s worth trying. To disable it, go to the server settings on the MX Linux host > Performance > untick the box for “User hardware encoding”.
The log is still showing that you have hardware decoding enabled. Set hardware accelerated decoding to “disabled” in .nx/config/player.cfg.
Pasting the instructions here from the article which I linked previously to be performed on the device you are connecting from.
1. First exit the Player by going to the !M icon in the system tray and selecting “Quit NoMachine player”.
2. Edit the player.cfg file in the user’s home.
This file is:
$HOME/.nx/config/player.cfg on Linux and macOS and %USERPROFILE%\.nx\config\player.cfg on Windows.3. Edit the “Enable hardware accelerated decoding” key and set the appropriate value to:
disabled (HW decoding is completely disabled)
For example:
<option key=”Enable hardware accelerated decoding” value=”disabled” />
Can you send those logs directly to forum[at]nomachine[dot]com? Please use the title of this topic as the subject of your email. Thanks.
From what you write it seems you can connect to some Astra hosts successfully but not others. This could indicate a problem on the side you are connecting from, not on the server Linux side. The error log shows intel-vaapi-driver-related errors. You can try disabling hardware decoding on the devices where the session window is closing. You can do this by following the instructions here:
https://kb.nomachine.com/AR07U01202