Forum Replies Created
-
Posts
-
Hi Holger,
what NoMachine product are you using? Can I assume that you are running a Virtual Desktop session?
In that case, you may try to disable the ‘X11 vector graphics mode’ on the server, via the Performance tab in the ‘Server preferences’ UI or by changing the AgentX11VectorGraphics key in ‘/usr/NX/etc/node.cfg’. That mode is specifically optimized for multimedia content.
In any case, I would check if H.264 encoding is being used. You can check that in the session menu of your NoMachine Player, at the botton of ‘Display settings’ menu.
Hi Ve0,
did you try to verify the network bandwidth actually available, and latency as I suggested above?
I see that the editor modified also my marks, but I think you got the point 🙂
Alternatively, libraries can be copied to the proper folder by hand.
I’m going to answer in any case, as this might be useful for someone else.
$ ./configure –disable-cli –enable-shared –disable-avs –disable-swscale –disable-lavf –disable-ffms –disable-gpac –libdir=”C:\Program Files (x86)\NoMachine\bin”
I don’t know if you just copied and pasted here the actual command. In that case, the reason could be the use of quotation marks ”” instead of “”. Or you can try with apostrophes ‘ ‘.
So, if I understand, the non-working case is with NoMachine player running on the Windows 7 guest, connecting to NoMachine server running on the Windows Server 2016 (virtualized) host.
The fact NVENC encoder is available or not shouldn’t have any effect on the blank screen, but maybe there is some problem with the passed-through GPU. Please try to open the NoMachine Server preferences menu on the Windows Server host (server side of the connection), go to Performance tab, and uncheck ‘Use acceleration for display processing’.
In any case, you can send us the logs for further investigations as eplained in https://www.nomachine.com/DT07M00098. You can send to forum[at]nomachine[dot]com.
Hi,
if there is a very limited bandwidth, I wouldn’t touch the settings at point 1 and 2, but rather let NoMachine do its job at controlling congestion. In fact checking those boxes will limit the ability of congestion control algorythms to adapt to detected network conditions by adjusting image quality dinamically. Those settings won’t change the final quality, they only affect the progression and the speed how the target quality is reached.
In your case, I think that the best option is to act on the Quality slider only to find the best balance between quality and responsiveness, assuming that the lack of responsiveness is only, or mostly, due to limited bandwidth. Maybe it’s worth checking the network latency too (round trip time), if you didn’t do already (VPN could play a role here). You can do that also from NoMachine user interface (‘Take the statistics’), or with the ‘ping’ command.
A last note about Capture2.png: that blurriness around edges of coloured images is due to the chroma subsampling introduced by the encoder. NoMachine has algorithms to correct such color shift (https://www.nomachine.com/FR03M02907), but those are enabled only for quality level 5 or above (from the middle of the Quality slider to the right).
Well spotted!
The intention was to say:
Setting a higher value for the ‘latency’ option means that NoMachine will not attempt to reduce the throughput to minimize response time as long as the latter is below the indicated value.
I corrected the FR accordingly. Thanks for reporting!
Is there any other way to modify the quality in addition to the display setting window?
No other way besides checking ‘Disable multi-pass display encoding’ to disable “progressive encoding”. But this will consume much more bandwidth.
1) Some screenshots, or even better a video, would be great.
2) Yes, definitely it is possible that achieved quality is not exactly the same with the hardware encoder, but at the moment I’m not able to say how much a Pascal card would improve things. Maybe you can try to compensate by increasing display quality in the Display settings panel?
Hi Gareth,
are you using the NoMachine free product and connecting to the physical display? And what version?
What is the desktop environment on the server (GNOME, KDE, …)?
Is that a headless server? What graphics card and drivers?
Hello,
you may want to take a look at the recently updated:
https://www.nomachine.com/FR03M02905
Hardware encoding with QuickSync is now supported out of the box on Windows, while on Linux further configurations are needed, as explained in the referenced article.
I’m not sure I understand what you mean with “artifacts problem”. Are you referring to some known problem of the nVidia encoder? Or a problem with NoMachine? A screenshot of those artifacts could help to clear things out.
Hi Will,
we verified the problem in our labs and opened the following Trouble Report to track it:
https://www.nomachine.com/TR09O08043
Thanks for reporting.
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.