Britgirl

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

[Britgirl]

Take a look at this web page which gives instructions on how to add a directory to PATH in Linux https://linuxize.com/post/how-to-add-directory-to-path-in-linux. For example,

for only one account:

export PATH="/usr/NX/bin:$PATH" >> ~/.bashrc

for global (need to be done as root):

export PATH="/usr/NX/bin:$PATH" >> /etc/bash.bashrc

You could use aliases (edit the same files based on whether you want to set globally or locally, and add these lines):

alias nxserver=’/etc/NX/nxserver’
alias sudonxserver=’sudo /etc/NX/nxserver’

alias nxplayer=’/usr/NX/bin/nxplayer’

 

 

 

[Britgirl]

Hi, there isn’t a native package for Windows ARM. However, the NoMachine for Windows package available can install and work on Windows ARM architecture, although services that require drivers such as printing and disks (server side) and USB (both sides) will not be available. Let us know how it goes.

[Britgirl]

Hi, definitely not. Can you send us the logs from both sides? Follow the instructions here to enable debug on the server side (the Win computer you are connecting to). There are instructions also for the Win computer you are connecting from.

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]

Can you provide more details about what you’d like to achieve?

[Britgirl]

Just a quick update on this. We are currently evaluating whether to make this possible and how it can be achieved, possibly with a key in the connection file.

[Author]

Posts