Forum Replies Created
-
Posts
-
Dear dd0044, this specific game seems to have a problem causing this specific issue.
It can still be a problem with NoMachine, of course, but it is absolutely advisable to first try the patch and then verify if it’s actually so.
We strongly invite you to do your best to install the game’s patch, possibly with the help of the game’s publisher, otherwise it will be difficult for us to investigate the problem without a well-specific starting point.
It’s a bug. There is a specific executable, nxdock, that is not signed. We investigated this and it seems that the bug was introduced in version 6.0.62, when we lastly upgraded the Mac build environment. We’ll fix it in the next release. Just to make things clear, the Mac and Windows packages are fully signed, as signed are all the libraries and all the executables (except those that, by mistake, got out of the procedure). We’ll fix this shortly and update the post-production unit tests.
Hi Bruce,
we’re not able to reproduce this behaviour in our labs at the moment. We are preparing a debug package to investigate on what’s going on on your Mac, if you’re willing to test it.
Unfortunately NoMachine insists on using QuickSync rather than VAAPI and the former is notoriously difficult to get working without applying a lot of hacks whereas the latter covers multiple GPU types and should “just work”.
Just to say that we started this in 2014. At that time VAAPI was not as mature and it didn’t even support the encoding side.
But now, finally, VAAPI starts to yield some results, and it is widely supported. Also considering the huge mess distributions make with Intel drivers, Intel Media SDK and the tweaking necessary to make QuickSync work, we are finally readying the VAAPI implementation.
Hi Bruce,
we will check deeply in our labs with the last macOS version. In the meanwhile, are you able to say maybe if this issue was introduced by the latest macOS update?
That FR only refers to H.264 hardware encoding on server side not yet available when using the X11 vector graphics mode. H.264 software encoding is always included in all licensed products (Workstation included), without any need for a specific license. As for the decoding side, software encoding is available in all licensed products and wherever hardware decoding is supported (that practically includes all Windows and Mac clients). If you are connecting from Windows, H.264 should be available.
At this point, I would try to disable hardware decoding on the affected client (https://www.nomachine.com/DT10O00157#5.7.).
Hi,
can you confirm you’re really using VP8 and not H.264? Please note that H.264 would be used by default where available. You can find this information in the Display settings panel in the session menu. I suspect you might be using a hardware encoder and there is some problem with video drivers.
Session logs could be useful to sort this out. See https://www.nomachine.com/AR10K00697 and https://www.nomachine.com/DT10O00163#2 for server and client side logs, respectively.
Hi,
you can connect to the server, right click on the existing session and select ‘Terminate session’ from the context menu. Alternatively, you can use the nxserver command line interface (sudo /usr/NX/bin/nxserver –terminate [<sessionid> | <display> | <username>]).
However such behaviour is certainly unexpected and, if possible, we would like to see the logs for further investigation. You can find info on how to gather logs here: https://www.nomachine.com/AR10K00697. You can attach them here or send to forum[at]nomachine[dot]com.
Hi Shu,
at the moment you have to look for this info in the logs. Session logs are located (by default) inside directories starting with the ‘C-‘ prefix in the ‘/usr/NX/var/log/node’ location. More info on how to retrieve the logs in https://www.nomachine.com/AR10K00697. If GPU is used for encoding, you will see in the ‘session’ file something like:
Info: Using H.264 hardware encoder.
Note that in future versions of NoMachine this info will also be available in the client GUI.
Hi,
I would start with checking logs. Please gather server side logs as described in https://www.nomachine.com/AR10K00697 and client side logs as decribed in https://www.nomachine.com/DT10O00163#2. You can attach them here or send to forum[at]nomachine[dot]com. Please also check CPU usage on client and server.
Hi David,
that is really strange indeed. I would start with trying to disable hardware decoding (check “Disable client side hardware decoding” in Display settings in the session menu). It would be great if you could gather server side logs as described in https://www.nomachine.com/AR10K00697 and client side logs as decribed in https://www.nomachine.com/DT10O00163#2. You can attach them here or send to forum[at]nomachine[dot]com.
Hi David,
as for the missing text in the error message, I can try to guess that it is about “can’t start command”. If you are using a custom command, are you sure that you’re writing it correctly or that it is in the PATH or even installed?
Given also the missing fonts, it seems like you don’t have a complete graphical environment installation on the server. Is that a possibility?
Notwithstanding the above, are there some reasons why one should favor the virtual session’s protocol? If there aren’t any, I will just stick to the physical session’s protocol.
It depends strictly on the desktop environment and used applications. X11 vector graphics mode is incomparable better at compressing traditional X traffic, but modern desktops and applications make more and more use of graphical effects and multimedia content. If physical session’s protocol works better for you, you should definitely use it. You can find more info here:
https://www.nomachine.com/AR01M00832
For this purpose, I installed the enterprise desktop evaluation but do I need to re-install the clients after I bought the fully licensed version of the terminal server?
You don’t have to reinstall clients. But be aware that the evaluation version doesn’t provide the library for H.264 software encoding. If your graphics card is not capable of H.264 hardware encoding, then you could not experience the best possible performance.
Hi Will,
nice to hear you found a solution. In fact this is not something that could be fixed on NoMachine side 😉
Hi Lars,
most data in virtual desktop is coming from images (#72 and #243 in the stats file), while other drawing operations don’t seem to contribute in a significant way, which is quite unexpected from a “lightweight” desktop. Physical desktop sessions can perform better in this specific case because used protocol is specifically optimized for multimedia content. Of course you can use the same protocol also in virtual desktop sessions, by simply unchecking the ‘Use X11 vector graphics mode in virtual sessions’ option in Server preferences -> Performance tab.
Alternatively, you can try to disable the Composite extension in virtual desktop sessions. This could cause the Xfce desktop to fallback to a rendering backend that, I hope, will make less use of bitmaps. To try that, add the following line to the ‘/usr/NX/etc/node.cfg’ file:
DisplayServerExtraOptions “-extension Composite”
A final note about compression ratio: the 1.260:1 ratio you report only includes X11 protocol compression but without considering images compression, which is the biggest part here. The correct overall value that includes also image compression is reported here:
overall: 709795968 bytes (693160 KB) in, 10296814 bytes (10055 KB) out.
That is a compression ratio of about 69:1. Not bad. Problem is that the desktop produced as many as 3000 images in only 100 seconds…