fra81

[fra81]

Hi,

you could try to install proprietary drivers if you don’t have them installed already, or vice-versa.

[fra81]

Hi,

glad to hear 🙂

The patch will be in one of the next releases, not sure if in the next one already. Anyway you can track the issue here:

https://www.nomachine.com/TR04R09608

As for H.265, it is in our plans and you can track it in the following Feature Requests:

https://www.nomachine.com/FR06O03428
https://www.nomachine.com/FR06O03429

 

[fra81]

Hi,

I see you have ‘Fit to window’ mode enabled (the small icon furthest to the left of the quick action icons that you can see at the bottom of the screenshot you have sent). Please try to disable it and see if it helps.

[fra81]

Hi,

please try to disable UDP on all connecting clients. To do so, select the connection and choose Edit (or right-click on the connection icon), then click Advanced and uncheck ‘Use UDP communication for multimedia data’.

[fra81]

Hi,

indeed this looks more like a problem with retrieving the screen content from video memory than a encoding/decoding issue. Is the server machine headless or is it a VM?

[fra81]

There are no steps for Mac and Linux at the moment, but I will update you soon 😉

[fra81]

Yes, it would, provided you make sure you reproduce the issue also on the Windows 10 VM before applying the instructions.

[fra81]

For sure it depends on the hardware encoder being enabled on the server side (it can’t be reproduced with software encoding), but we suspect that also the specific decoder in use could help to trigger the issue.

Are you connecting from a Windows client? I this case, would you try the following?

1. Re-enable hardware encoding on server.

2. Then download dlls from:

https://ffmpeg.zeranoe.com/builds/win32/shared/ffmpeg-4.2.2-win32-shared.zip

(or alternatively go to https://ffmpeg.zeranoe.com/builds/ then select 4.2.2 + windows 32 + shared and download build).

3. Go to Nomachine installation directory on client machine (e.g. C:\Program Files (x86)\NoMachine\bin) and rename libav.dll to libav.dll.backup (or similar).

4. Extract ffmpeg-4.2.2-win32-shared.zip and copy these files:

avcodec-58.dll, avutil-56.dll, swresample-3.dll

to Nomachine installation directory.

5. Run the NoMachine player and try to reproduce the issue.

[fra81]

First of all, thanks for letting us know the version and for the links. More investigations are needed to clarify all aspects.

To be sure, according to you is H264 more efficient than VP8 ?

Yes, H.264 will be more efficient regardless hardware or software encoding is used.

Are we agree this issue is coming from the server side ?

For sure it depends on the hardware encoder being enabled on the server side (it can’t be reproduced with software encoding), but we suspect that also the specific decoder in use could help to trigger the issue. If you have the possibility to test from a Windows client, we would like to send you further instructions. Would you help with that?

[fra81]

Hi,

I think you make a good point about disabling clipboard in ViewOnly mode. However you can already avoid that by setting ‘server’ or ‘none’ in the EnableClipboard key.

# client: The content copied on the client can be pasted inside the
#         NX session.
#
# server: The content copied inside the NX session can be pasted
#         on the client.
#
# both:   The copy&paste operations are allowed between both the
#         client and the NX session and vice versa.
#
# none:   The copy&paste operations between the client and the NX
#         session are never allowed.

[fra81]

Hi,

indeed we received several reports about artifacts with hardware encoding in the last few days and it looks like a problem in Nvidia drivers. Investigation is ongoing to find out if any tweak is possible to avoid to trigger this issue. In the meanwhile you can disable hardware encoding by adding this line to the ‘/usr/NX/etc/node.cfg’ file:

EnableHardwareEncoding 0

Please also tell us about your drivers version.

[fra81]

Hi,

you can also try XF86_ClearGrab to terminate the application that owns the grab, or XF86LogGrabInfo to dump info about the application. Output from XF86LogGrabInfo will appear in the ‘/usr/NX/var/log/node/C-<hostname>-<display_number>-<session_id>/session’ file.

[fra81]

I’m glad your issue is fixed 🙂

[fra81]

Hi,

please try to edit the /usr/NX/etc/node.cfg file on the server machine by adding the following line:

EnableHardwareEncoding 0

Then restart the NoMachine service:

/usr/NX/bin/nxserver --restart

[fra81]

Hi,

as far as I understand there should be no problem with available network bandiwidth, but in the statistics I see that network latency is quite high. This could be another cause for reducing the throughput. Please try to edit the ‘C:\Program Files (x86)\NoMachine\etc\node.cfg file on the server machine as explained in this FR:

https://www.nomachine.com/FR03O03364

Then start a new connection and see if it helps.

[Author]

Posts