Forum Replies Created
-
Posts
-
Hi Mehmet,
you can try to disable hardware encoding instead of disabling H.264 altogether. To do that, uncomment and disable the EnableHardwareEncoding key in the ‘C:\Program Files (x86)\NoMachine\etc\node.cfg’ file, then restart NoMachine server:
EnableHardwareEncoding 0
Please also send logs for further investigation, as explained in https://www.nomachine.com/AR10K00697.
Hi,
thanks for letting us know that the product is working well.
About the noticed “motion sickness”, let me point out that, from a technical standpoint, any “lack of synchronization” is unlikely due to the way NoMachine handles the mouse movements. Mouse movements, in fact, are handled locally and displayed immediately, as they happen, on the client side. In other words, what you see moving on screen, is the local cursor and not the remote one. On the other hand, it’s true, that to see the response of the graphical environment (for example an icon becoming highlighted after a mouse click) the mouse event must reach the remote server, the graphical output encoded, sent and displayed by the client, so that the response can be actually “delayed”, depending on the network latency or the speed of the involved machines. Unfortunately there is very little we can do to avoid this. To better check the latency that exists between the mouse movement and the speed of the server to reflect the change, you can enable showing the remote cursor as it is processed by the server. You can find this option in the Input preferences panel. Such option is turned off in the default settings.
Hi,
this is not possible at the moment. Part of the reasons are technical: the only consistent way to implement blanking across all platforms is by turning off video output completely, thus it is not possible to show a prompt on the physical screen, especially one that would not be seen also on the connecting client. Note that you can regain control over the machine at any time by connecting from any other computer or device at your disposal, including mobile devices, thanks to NoMachine client for iOS and Android.
With the last update, H.264 encoder is now available by default in all NoMachine products, free ones included, so it is not possible to exclude that some new problem could be found when hardware encoding or decoding is in use with specific graphics cards or drivers, since, as you can imagine, it is not possible to test every possible combination of hardware, drivers and configurations in our labs.
Can you confirm you had tried to check the ‘Disable client side hardware decoding’ box?
And could you send us the session logs so we can investigate further? You can gather server side logs as explained in https://www.nomachine.com/AR10K00697 and client side logs as in https://www.nomachine.com/DT10O00163#2. You can send the files to forum[at]nomachine[dot]com.
Also a screenshot showing the issue could be useful.
Hi.
Strange. There is no such “error” in the NoMachine code and I honestly don’t understand how it could have been generated and make the session fail.
Could you take a screenshot of that error?
Please also provide more info on the operating system and the NoMachine product installed.
Hi,
I assume you have a Retina display on your Macbook and so it could depend on the scaling settings of the display. Could you attach a screenshot of your Display system preferences?
Hi,
isn’t just disabling ‘Fit to window’ doing what you want? If that’s not the case, could you explain further what behaviour you would like to achieve?
Yes, indeed.
In general, when streaming a Windows desktop, RDP has access to the internal OS graphics primitives. But this doesn’t occur when streaming the NoMachine session, whose content is a Linux screen that is rendered remotely.
RDP is not able to stream this type of content as efficiently, so it’s not a NoMachine problem. This is a performance issue that must be solved in RDP.
Yes, getting the dongle should be the easiest solution to have GPU acceleration, but probably you are good to go with the llvmpipe solution, so I’d suggest to wait for your user 😉
Hi,
I think this Feature Request describes what you need:
https://www.nomachine.com/FR12K02799
Check the box to be notified when implemented 😉
Hi,
the fact the X server starts up doesn’t mean necessarily that rendering actually happens when no montitor is connected to the GPU. You could try one of those dongles that simulate a monitor. Try to search for “headless hdmi dongle”.
Or you could give one more try with the NoMachine’s virtual display server. In this regard, the following article should be more appropriate to address your issue:
Hi,
this is not expected in general, but consider that when you disconnect without logging out, desktop environement and applications continue running, doing their stuff and possibly making requests to the X server (which is built in the nxnode process in this case).
If you feel the CPU usage is not justified anyway, you can try to gather more info on what is happening with the following commands:
# strace -f -p <pid>
# top -b -n 1 -H -p <pid>
Where <pid> is the process ID of the nxnode process which is consuming CPU. You can send the outputs of those commands to forum[at]nomachine[dot]com. Please send along also server side logs gathered as explained in https://www.nomachine.com/AR10K00697.
However, for NoMachine got a new error: “NvEncode: ERROR! Error is 15, ‘Invalid version’.”
This will be fixed in the upcoming software update. It is a compatibility problem with most recent drivers (and the Trouble Report you mentions is indeed related). However this error should not prevent sessions from working correctly.
I was unable to get NoMachine to start my desktop environment. I tried adding unix-xsession-default to AvailableSessionTypes in node.cfg and server.cfg, and also setting DefaultDesktopCommand to “/usr/bin/dbus-launch –exit-with-session /usr/bin/mate-session”, but mate-session couldn’t connect to DBus.
It should work out of the box. Please check this article for some common issues with the desktop environment:
It could be a problem with slow access to video memory. We happened to observe such behaviour in the past on headless machines, but it could also depend on the drivers. Please attach the output of glxinfo.
You can also test what would happen if you use the virtual framebuffer provided by NoMachine instead of the “physical” output. In order to try that you have to turn off the graphical environment on the server (‘sudo systemctl stop gdm‘ or ‘sudo systemctl stop lightdm‘ or any other command which is suitable for the display manager in use) and then restart the NoMachine service (‘sudo /usr/NX/bin/nxserver –restart‘). So NoMachine will create a virtual framebuffer which you can connect to and test performance.