fra81

[fra81]

Hi.

When the highest Display quality is set for the session, NoMachine is already cofigured to target the best quality possible.
Changing encoder presets would not affect quality, but only the ratio between encoding time (CPU usage, but also responsiveness) and video frames size (bitrate).

[fra81]

Hi @danny,

good to hear 🙂

[fra81]

Hi @saips,

it’s not all clear to me yet: you make a fresh system installation, then upgrade it and get the issue? Everything on the same machine? And what is the Xorg version in the fresh installation?

Also I see that you have an external keyboard and mouse. Can you check if you still reproduce the issue after unplugging them?

[fra81]

Hi,

indeed screen resolution will affect both CPU usage (but we already concluded that CPU is not an issue for you) and network bandwidth usage. What you say seems to confirm further that network should be the culprit here.

[fra81]

@saips

Can you show the output of ‘xinput’ command?

And please tell your Xorg version. Did you upgraded it recently?

• This reply was modified 6 years, 9 months ago by fra81.

[fra81]

This looks like a different issue, and it is apparently a known bug in the modesetting driver:

https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1487954

https://bbs.archlinux.org/viewtopic.php?id=225736

[fra81]

Hi,

when connecting to the physical display, available resolutions are only the ones provided by the graphics card, the same you can see with xrandr. Very likely you are connecting to a virtual session with VNC. NoMachine supports virtual desktop sessions in the NoMachine Workstation product. You can download the evaluation version if you want to check it.

[fra81]

Hi,

sorry for the delay. I really thought I had already answered!

As one may expect, in the logs I see that NoMachine on your hardware is really capable to produce 60 frames per second, or vey close to that (the second number is fps):

R 17.7/56.4
R 17.4/57.5
R 17.5/57.1
R 17.8/56.2
R 17.3/57.8

In particular, I see that around 57 frames per second are produced steadily at least for some time, until congestion (or a significative increase of network latency) is detected on the network:

42417 42970 11:26:53 522.772 DisplayServer/DisplayServer: Received congestion message with level 9.

At that point, as expected, the server decreases the frame rate.

All in all, I really think the reason is to be find in the network conditions, and not in any hardware or algorythmic issue, that seem to be excluded when looking at the logs.

[fra81]

Hi!

Sure, the plan is to add support for H.265 (HEVC) wherever it is supported by the hardware.

[fra81]

Hi!

Please check if a core file was dumped (usually in the user’s home directory). If you find it, use the instructions here to get a backtrace: https://www.nomachine.com/AR09L00810.

In any case, logs from the server could be useful. Please locate and compress the log directory as explained here: https://www.nomachine.com/AR09L00810.

You can attach the files here or send to forum[at]nomachine[dot]com.

[fra81]

Hi,

we couldn’t reproduce this in a quick test in our labs.

Does the key combination cycle through the Mac windows now? Or it does nothing at all?

Are you able to say at what point it stopped working? After a client or server OS update? After a NoMachine update?

[fra81]

Hello,

for sure your hardware should be able to stream 60 fps without problems! What is your client side hardware and OS? And would you exclude bandwidth problems? For example, does it get any better if you lower the Display quality in the Display settings menu?

Additionally you could send us the logs, so we can search for any hints. For the server side: https://www.nomachine.com/AR10K00697. For client side: https://www.nomachine.com/DT10O00163#2. You can send them to forum[at]nomachine[dot]com.

[fra81]

Hi,

I see in the logs that the Wayland display manager is enabled on your system.

We are actively working on Wayland support. You can be notified when it will be released by applying in the relevant Feature Request:

https://www.nomachine.com/FR10N03221

In the same link, you can find a possible workaround.

[fra81]

Hi fred1,

we’ve never seen anything similar. Indeed log files look zeroed when the freeze occurs. Maybe you could run a sanity check on your hard disk, just to be sure.

Please provide the following information:

1. Gather content of “C:\Windows\Minidump” directory.

2. Export Event Viewer logs:

– Open Control Panel -> System and Security -> Administrative Tools -> Event Viewer

– To export events, select the type of logs you want to export, click on Action menu and pick Save All Events As.

We’re interested in ‘Windows Logs/System’, ‘Windows Logs/Application’ and ‘Application and Services Logs/Hardware Events’ logs.

[fra81]

There is something strange. I see two X server processes running, and one is in failsafe mode.

I would suggest you to reset everything:

systemctl stop lightdm
killall Xorg
killall -9 Xorg
systemctl start lightdm

/usr/NX/bin/nxserver –restart

Or reboot the machine… 🙂

[Author]

Posts