Forum Replies Created
-
Posts
-
We reproduced the issue in our labs. A fix will be probably released in the next software update.
You can track it here:
https://www.nomachine.com/TR09O08042
Thanks for reporting 😉
Hi Thor,
what you say about other window managers being affected seems to point to video drivers. Without getting into details on how difficult is the cooperation between applications doing direct rendering, window managers, X.org and video drivers, I can say that this is not the first time we observe this kind of problems, as video drivers are better designed to push images to the video device rather than to pull them back into main memory. NoMachine in the current implementation doesn’t do anything special, as it uses core X.org functions to get screen images. So what appears to be broken here is a very basic functionality, as we can see with the simple xwd utility.
What you suggest is indeed a possibility. One that we evaluated in the past, I have to say. But I think that now we have a much better chance. We are already working at an alternative implementation that doesn’t rely on X.org, but that will work at the level of the grapchics card. This will help in supporting the new Wayland display manager, but it will also benefit X.org-based environments.
You may want to track this Feature Request to know when that will be released:
Sorry, it looks like there was a formatting problem. It should be ‘- -restart’ (without the space). But to make it easy, you can just reboot the machine.
Should you still be unable to connect after restart (or reboot), please send us the logs for further investigations (https://www.nomachine.com/DT07M00098). You can send them to forum[at]nomachine[dot]com.
As for performance, let’s see how it will be after the configuration change is applied, but it has to be noted that 200ms is quite a long ping time.
Can you try to issue a ‘ping’ command from the Windows host to the Mac and tell us the result?
Is the Mac host a headless machine (Mac Mini with no monitor attached)?
Finally, please try to edit the ‘/Applications/NoMachine.app/Contents/Frameworks/etc/node.cfg’ file. Add there this line:
DisplayServerExtraOptions “-nostreamgrab”
That will enable an alternative screen capture method. After applying the change, you will have to restart the server:
sudo /Applications/NoMachine.app/Contents/Frameworks/bin/nxserver –restart
You’re welcome!
I’d just like to add that NoMachine can leverage the GPU acceleration in order to reduce drastically the CPU usage in most situations. Unfortunately the actual GPU support level inside virtual machines not always is as required.
Hi Val,
I would start with checking the basics in order to narrow things down. How is the CPU usage on both client and server side, and how does the bad case compare to the good case? Did you try already to verify the bandwidth and latency actually available between the sites? Do the different sites use the same desktop environment (xfce 4.8 on CentOS 6) and applications?
Hi MalcomS,
that could mean that 3D acceleration is not available in the virtual machine, and so the most advanced screen capture mechanisms cannot be used by NoMachine. You can try to assign more CPU resources to your virtual machine. For example, if you assigned only one CPU, that is usually not enough. You may also try to enable 3D acceleration for the guest, but from my experience results are not always as expected and they strongly depend on the system.
If necessary, and you still want to send logs for further inspection, here are instructions: https://www.nomachine.com/DT07M00098. You can send them to forum[at]nomachine[dot]com.
Hi!
If you want to keep using the X11 vector graphics mode, you can change the codec used for compression of images to a lossless one. On the server, edit the ‘/usr/NX/etc/node.cfg’ file by adding the following line:
ProxyExtraOptions pack=16m-png
or, if you have enough bandwidth:
ProxyExtraOptions pack=rgb
Hi f,
unfortunately the logs you sent are not enough to understand what is going on. Please gather a complete set of server and client side logs as explained here: https://www.nomachine.com/DT07M00098. Don’t forget to set the SessionLogClean configuration key and to select the ‘Don’t delete log files on exit’ checkbox in the player’s settings (Privacy tab).
Hi Thor,
we reproduced this issue in our labs, but unfortunately it can’t be solved in NoMachine software. We observed the same problem when dumping the screen with ‘xwd’ X utility. It looks like that images pulled from video memory by the X server can appear corrupted independently from the method or application used. I can’t say if this is a bug in compiz, X.org or the video drivers.
Please try to disable hardware ‘acceleration for display processing’ (on the server):
We’ve reproduced this issue in our labs, thank you for reporting. While we are working on a solution, you can work around it by disabling hardware acceleration for display processing: https://www.nomachine.com/AR02L00782.
Thanks for sending the logs. Unfortunately they are not enough to determine what is the problem, since debug logs are disabled. Please follow the instructions of this paragraph: https://www.nomachine.com/DT07M00098#1.
Hi,
.xsession-errors shows the problem:
openConnection: connect: No such file or directory
cannot connect to brltty at :0
upstart: Failed to spawn upstart-udev-bridge main process: unable to execute: No such file or directory
upstart: unity-gtk-module main process (1889) terminated with status 127
upstart: dbus pre-start process (1891) terminated with status 127This issue is known:
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1537610
You could try the workaround reported here:
https://askubuntu.com/questions/763735/ubuntu-16-04-blank-screen-at-bootup/871156#871156