fra81

[fra81]

Hi manzaiya,

sorry for the delay. I’m not sure this is the same as the known issue, given that you aren’t using a scaled display. Can you reproduce the issue right now or you downgraded the NoMachine server version in the meanwhile? If you can reproduce, would you send us the logs as explained in https://kb.nomachine.com/AR07K00677? You can send them to forum[at]nomachine[dot]com, by referencing this topic. Then please try to disable hardware decoding on the client (Open the session menu -> Display settings -> Advanced options) and hardware encoding on the server (Server settings -> Performance).

[fra81]

Hi Doug, I examined your logs (sorry for the delay). It seems that something is delaying the startup of the session until a timeout is reached, but unfortunately it isn’t clear what exactly. Did you maybe set up the forward of some device through the session? In that case, please try to connect with a newly created connection file. And would you exclude network problems?

[fra81]

The Mac is an M1 Mini

What model year?

it seems like my hardware and OS should support hardware H264

Yes, it does. The problem is that the hardware encoder doesn’t provide all the capabilities NoMachine relies upon.

That having been said, certain things are still very poorly rendered

Have you tried to increase the display quality in the Display settings panel of the session menu? You can also try to click on the ‘Disable client side post-processing’, in the advanced options.

would a complete re-install still be recommended

Yes, I would do that, just to be sure.

[fra81]

Hi nxmac, sorry for the delay. We identified 3 issues in your logs, not all dependent on NoMachine, that explain your observations. The first one is that the library used for software H.264 encoding is missing in your NoMachine installation, probably due to a problem occurred during the upgrade. We suggest to uninstall NoMachine completely on the Mac and reinstall it from scratch. The second issue is that the hardware H.264 encoder on the Mac lacks the capabilities needed for encoding by NoMachine. This doesn’t depend on NoMachine but it would be interesting to know the exact model of your Mac and the macOS version. These 2 issues prevented H.264 from being used at all and the VP8 encoder was used as a fallback, resulting in lower quality images. The third issue is a bug in the code responsible for falling back from H.264 encoding failures and it was causing the blanked screen issue. This will be fixed in the next NoMachine update.  

[fra81]

Hi Rey,

sorry for the delay. What you describe shouldn’t happen normally as NoMachine already suppresses unwanted repeated keys. To investigate further your specific case we would need more info about your setup, in particular we would need to confirm if the server is using X or Wayland. If it’s more convenient for you, we could get such info from the logs. If you are willing to provide them, please follow the instructions in https://kb.nomachine.com/AR07K00677 and send them to forum[at]nomachine[dot]com, by referencing this topic.

[fra81]

Hi Piter, sorry for the the late reply.

Isn’t the problem related to the drop of vdpau-va-driver by Debian?

Yes, it seems so. Anyway this isn’t something that can be fixed in the NoMachine software.

[fra81]

Hi,

the “non-working” case occurs when NoMachine detects that there is already a X session running on the systems and it attaches to it. The fact this X session has a limited set of resolutions doesn’t depend on NoMachine.

The “working case” is when NoMachine doesn’t detect a X server already running on the system and creates its own virtual display. The fact a X server is running or not also doesn’t depend on NoMachine.

However you can work around this problem by stopping the display manager and so avoiding a X session is created in all cases. To do so, you can follow the instructions at point 3 of this article:

https://kb.nomachine.com/AR03P00973

[fra81]

Hi,

can you show us the output of these two commands?

for DEVICE in /dev/dri/* ; do echo "*** Trying $DEVICE ***" && LIBVA_DRIVER_NAME=nvidia vainfo --display drm --device $DEVICE ; done

lsmod

[fra81]

Hi,

recent Windows versions have an optimization that disables rendering when the monitor is turned off, and this doesn’t depend on NoMachine. You can try to add the following option to the ‘C:\Program Files\NoMachine\etc\node.cfg’ file, even though I’m not sure it will work if the monitor is turned off by the power button:

DisplayServerExtraOptions "-displayrequired 1"

You may also try to change the screen capture method in NoMachine by specifying the following option (the two options can also be concatenated):

DisplayServerExtraOptions "-nodxgigrab"

[fra81]

Please try to installe the ‘vdpau-va-driver’ package and tell us if it helps.

[fra81]

Hi nxmac,

to confirm the issue you are reporting is the same that was reproduced in our labs, please answer the questions below.

Does the temporary workaround suggested by Britgirl work also in your case?

And can you try to press Capslock twice when the issue occurs? Does this also help?

[fra81]

Hi Piter,

logs show that DRM initialization fails, maybe due to some missing package. Please show us the output of this command:

dpkg -l | grep -i "libva\|vaapi\|vdpau"

[fra81]

Hi iv,

please try to run this command on the server machine and tell us if it reports any error:

sudo /etc/NX/nxserver --eglcapture yes

Then restart the display manager and the NoMachine server to make changes effective:

sudo systemctl restart display-manager
sudo /etc/NX/nxserver --restart

Let us know if that solves the problem.

[fra81]

Thank you for the report! It seems that what you were seeing is the expected behaviour. By default NoMachine uses progressive refinement of the image quality (what is called ‘multi-pass encoding’ in the option) in order to achieve the minimum response time. Alternatively to disabling those options, you may try to increase the display quality. This will make the progressive refinement quicker.

[fra81]

Hi,

would it be possible for you to show us a video of the behaviour you are seeing? In the meanwhile, you may try these options in the session menu, Display settings, Advanced:

– Disable network-adaptive display quality

– Disable multi-pass display encoding

[Author]

Posts