fra81

[fra81]

New NoMachine version 6.10.12 has been released (fixing https://www.nomachine.com/TR04R09608). Please update and check if the issue is still present.

[fra81]

Hi,

you may try these options in the session menu panel (https://www.nomachine.com/DT10O00156&dn=menu%20panel#5.7):

– choose to ‘Request a specific frame rate’ and select 60 fps

– click to ‘Disable frame buffering on decoding’

 

[fra81]

Hi Walter,

sorry for delay. At the moment we know that only Nvidia driver versions 4xx are affected and only with some video card models, versions 3xx are not. But it’s still not clear what is triggering the issue. Investigation is ongoing. At the present stage, it looks like NoMachine can cause this behaviour only indirectly and there is no evidence of a problem in our software.

[fra81]

Is ‘Fit to window’ disabled in the Display panel of the session menu?

And can you send a screenshot?

[fra81]

Hi,

those errors mean that it is not possible to allocate shared memory on your system, probably because it is exhausted. To confirm, please run the following commands in a terminal on the Mac at work and send us the output (you can attach here or send to forum[at]nomachine[dot]com):

sudo sysctl -a | grep shm

sudo ipcs -ma

Quickest way to get rid of leftover shared memory segments is to restart the machine.

[fra81]

Hi,

NoMachine automatically adapts to network conditions, so I wouldn’t change many of the default options. In particular I’d leave H.264 as it could leverage hardware encoding and decoding.  In the Display settings panel I’d change display quality to max, choose to request 60 frame per second and select ‘Disable frame buffering on decoding’ along with ‘Disable client side image post-processing’. You may also want to disable UDP by clicking to Edit the connection and selecting Advanced settings.

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

[Author]

Posts