Forum Replies Created
-
AuthorPosts
-
April 22, 2020 at 13:58 in reply to: Recommended settings for fast local LAN connections only #26960
fra81
ModeratorIs ‘Fit to window’ disabled in the Display panel of the session menu?
And can you send a screenshot?
fra81
ModeratorHi,
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.
April 15, 2020 at 11:13 in reply to: Recommended settings for fast local LAN connections only #26749fra81
ModeratorHi,
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
ModeratorHi,
you could try to install proprietary drivers if you don’t have them installed already, or vice-versa.
fra81
ModeratorHi,
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/FR06O03429April 6, 2020 at 09:39 in reply to: Blurry screen when connecting from Macbook pro (2015)to Ubuntu 18.04 #26544fra81
ModeratorHi,
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
ModeratorHi,
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
ModeratorHi,
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
ModeratorThere are no steps for Mac and Linux at the moment, but I will update you soon 😉
fra81
ModeratorYes, it would, provided you make sure you reproduce the issue also on the Windows 10 VM before applying the instructions.
fra81
ModeratorFor 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
ModeratorFirst 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?
April 1, 2020 at 11:53 in reply to: Clipboard in “View Only” Virtual Desktop copied from shadowing session #26419fra81
ModeratorHi,
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
ModeratorHi,
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
ModeratorHi,
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.
-
AuthorPosts