fra81

[fra81]

This is a really strange issue. Could this Trouble Report possibly apply to your case?

https://www.nomachine.com/TR06P08609

[fra81]

Hi,

could this Trouble Report apply to your case (i.e., are you sharing a USB device between client and server by NoMachine services)?

https://www.nomachine.com/TR06P08609

And yes, logs could be useful. Please find instructions for the server side in https://www.nomachine.com/AR10K00697 and for the client in https://www.nomachine.com/DT10O00163#2. You can send files to forum[at]nomachine[dot]com.

[fra81]

Logs are pretty clean. Are you sure it’s not something with your network setup. Are you using a VPN service between the client and the server maybe? Could that be the culprit?

I would also try to disable UDP (Edit connection -> Advanced -> uncheck ‘Use UDP communication for multimedia data’).

Also, please check CPU usage during the “freeze”.

[fra81]

Hi Babok,

can you tell us more about the hardware you have on the server and about the desktop environment (GNOME, KDE…) in use? Besides lowering the screen resolution, you could try to use a lightweight desktop environment, if that’s not the case already (see https://www.nomachine.com/AR07K00676).

Sometimes had to relaunch the server NoMachine because I couldn’t connect to. I read this bug has been reported before, any news on macOS problem occurring on monitors supporting wide color gamut?

Can you tell us more about this problem? If you are referring to https://www.nomachine.com/TR10P08920, that should be fixed in version 6.8.

[fra81]

Hi Ross,

please gather server and client side logs, as explained in https://www.nomachine.com/AR10K00697 and https://www.nomachine.com/DT10O00163#2.3. You can send them to forum[at]nomachine[dot]com.

Also session statistics could be useful:
– open the Connection panel in the NoMachine Menu Panel (see https://www.nomachine.com/DT07M00087#9);
– click on ‘Take the statistics’ once to reset counters and discard the result;
– reproduce the issue (for example type in the terminal and wait for the result);
– click on ‘Take the statistics’ one more time and send us the resulting file.

[fra81]

Hi,

please collect server-side logs from the Windows 8.1 computer and show us. You can send them to forum[at]nomachine[dot]com.

Are you connecting to the login screen of your Windows 8.1 computer?

[fra81]

Hi davide445,

it’s hard to provide any exact figure without a specific investigation. I can confirm that latency generally is in the order of few milliseconds, but as you can imagine it can depend on many factors, like the hardware, the availability of a hardware decoder, the frame resolution, etc. I think the best way is trying it out…

[fra81]

Hi,

I wasn’t able to reproduce your problem. Could you send a screenshot of the scaling options from the display settings of both your client and server Macs?

[fra81]

Hi,

aren’t fonts progressively refined? Or do they stay blurred? In the last case, please send a screenshot showing the problem.

In the meanwhile, you can try to check the ‘Disable multi-pass display encoding’ option in the Display settings.

[fra81]

Thanks for the logs. Please check if any of the these helps:

1) turn off UDP (Edit connection -> Advanced -> uncheck ‘Use UDP communication for multimedia data’);

2) uncomment and set the EncoderMode key (in /Applications/NoMachine.app/Contents/Frameworks/etc/node.cfg) to the following:

EncoderMode bitrate

(then restart the server)

[fra81]

I exit i3 and went back into a tty. From there I made sure that the nxserver was running. But from my smartphone while I do see my laptop when I try to connect to it it tells me “Error is 113: No route to host”.

It’s not clear to me what you did exactly. To make sure you effectively stopped the display manager, please run this command and tell the output:

systemctl status display-manager

Anyway “No route to host” is strange, it seems like the IP address is wrong. Are you inserting it manually?

In the logs you sent previously, I see that the resolution of physical display on the server is 3840×3040. Are there multiple monitors or is it only one with such a high resolution? Can you try to use only one monitor in the first case, or lower the screen resolution in the second, and check how this impacts performance?

[fra81]

Hi kvic,

it seems the ‘lossless refinement’ feature is not being used. Can you send send server (https://www.nomachine.com/AR10K00697) and client (https://www.nomachine.com/DT10O00163#2.2) logs so we can take a further look? You can send them to forum[at]nomachine[dot]com.

[fra81]

Hi,

it looks like an issue with hardware encoding. I see version on server side is quite old (5.1.54). Updating to the last version should solve your problem.

[fra81]

Hi,

H.264 is not used because the Android client currently lacks support for decoding it. This will be added in one of the next updates. Also hardware decoding will be added:

https://www.nomachine.com/FR12M02991

Still, this doesn’t seem to be enough to justify what you see, so please tell us more:

– What is the desktop environment (GNOME, KDE…) in use on the Arch server? Could you try a different one, possibly a lightweight one like Mate or Xfce?

– Can you try to connect from a different client (any Windows, Mac, Linux machine)?

– Are there other processes besides nxnode on top of the htop output? Would you attach a screenshot of that output here?

– Would you try to turn off the graphical output of the server, as explained in https://www.nomachine.com/AR03P00973, and check performance? In this case, without an X server running, NoMachine will run its own built-in X server, so we would be able to exclude another possible source of problems.

[fra81]

So please try this:

cd /usr/lib/x86_64-linux-gnu/
sudo ln -s libva.so.2 libva.so
sudo ln -s libva-drm.so.2 libva-drm.so
sudo ln -s libva-x11.so.2 libva-x11.so

[Author]

Posts