Britgirl

[Britgirl]

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.

[Britgirl]

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!

[Britgirl]

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 --restart

Then NoMachine will create its own virtual display. To avoid sddm restarting itself after a future reboot, disable it completely

sudo systemctl disable sddm

Information about headless hosts is available here: https://kb.nomachine.com/AR03P00973

[Britgirl]

Just to let you know we received the logs and will come back to you once developers have finished their analysis.

[Britgirl]

No, there isn’t right now, but we will add the possibility to configure one in the GUI. Thanks for the suggestion 🙂

[Britgirl]

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?

[Britgirl]

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”?

[Britgirl]

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

[Britgirl]

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”.

[Britgirl]

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” />

[Britgirl]

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.

[Britgirl]

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

 

[Britgirl]

Hi,

NoMachine is designed to work out-of-the-box on headless machines, nevertheless, in some cases users can experience a black screen when connecting to the remote host. This can be triggered by multiple factors, such as the GPU model, the graphic card driver or the program which uses the GPU for rendering.

I’m afraid we can’t do anything to fix this, but you could try using a different capture method by adding this line in node.cfg on the server side:

DisplayServerExtraOptions “-nodxgigrab”

and restart the server afterwards (go to Settings -> Server -> Server status -> Restart server). If that doesn’t help, the only option is keep the screen connected when using NoMachine.

[Britgirl]

As you know, the X server display is a communication port used by X applications. Since it is a basic information for an X server, we used it also as an ID for our display servers. Also, it is of course unique since two display servers can’t use the same port, and this is the reason why they’re different. The base port for our servers start by default to 1001 and is increased depending on running displays, free ports, etc. You can change that value through configuration files, if you prefer.

Please note that, when running in mirror mode, our display server doesn’t accept connections on its port, so setting the DISPLAY variable to our display server ID value is useless. On the other side, by changing the correct connection port to your X applications, they’ll fail to connect to your physical display server and open their windows.

[Britgirl]

Hi,

if you want a 1:1 experience (connecting to the physical display) you should have the exact monitor arrangement and resolutions on both sides (client and server) and run it in fullscreen mode.

[Author]

Posts