Forum Replies Created
-
Posts
-
Hi russelaugust,
if you are using the latest NoMachine version (6.11.2) on the client, you could be reproducing this known issue:
Hi,
when connecting to the MacBook, you are attaching to its physical display, so on the client client you can only see the monitors that are physically available on the server. RDP on Windows can create a virtual desktop (not the physical one) with its virtual monitors.
Hi,
VirtualGL wouldn’t help in your case, as it is intended for virtual desktop sessions that are supported in the NoMachine Terminal Server product family. If you can find a core file or a crash report from those segfaults, it would be very useful to gather a backtrace from them (see https://www.nomachine.com/AR09L00810). Also logs can be useful (see https://www.nomachine.com/AR10K00697).
Hi,
this doesn’t depend on the NoMachine software. Available resolutions are those made available by the system (depending on the graphics card, the drivers and whether a monitor is attached). If you don’t have the possibility to attach a monitor to the server, you can try to use a HDMI dummy plug.
Hello,
yes, the quality slider affects directly the bitrate and thus the bandwidth consumption (but if you have for example a 100 Mbps network, you could go already with quality 9). Since responsiveness can also depend on other variables (e.g. network latency), I’d suggest to test the different quality values in your environment.
Hi,
hardware decoding is always enabled by default on Mac. If you send the logs, we can check what is actually used. You can find instructions in https://www.nomachine.com/DT10O00163#2 and then you can send them to forum[at]nomachine[dot]com. I would also check CPU usage on both the client and the server during those freezes.
Hi all,
the issue was reproduced in our labs and it is tracked here:
https://www.nomachine.com/TR06R09772
The fix will be made available in the next software update. You can also select to be notified when the Trouble Report is closed.
At the moment, as a workaround, I suggest to use the H.264 codec (which is anyway the recommended option).
I’m glad to hear that your issue is fixed. Of course it is always recommended to upgrade to the latest version in case any problem is found.
The latest version is what caused the problem.
Do you mean latest 6.11.2 or any version before that?
If the issue is present with version 6.11.2, would you try to reproduce again and send us the logs for debugging? You can find instructions in https://www.nomachine.com/AR10K00697 (for server side logs) and https://www.nomachine.com/DT10O00163#2 (client side). You can send everything to forum[at]nomachine[dot]com.
Is the remote computer “headless” (i.e. has no monitor attached)? Or, in case it is a laptop, is the lid closed?
In case, can you try to attach a monitor, or leave the lid open, and check again?
Hi,
is the server a Windows machine in your case? What version? Is it maybe a headless machine (no monitor attached), or has it the lid closed (in case it is a laptop)?
Would you mind sending server side logs from a problematic case, as explained in https://www.nomachine.com/AR10K00697?
Hi Zenith,
the fact that you don’t see glitches on the TV doesn’t rule out a problem with drivers. Rendering (pushing) to the GPU may work correctly, but pulling the screen content back from the video memory may not. Unfortunately this is not something that NoMachine can control.
It looks like libnvidia-encode.so can’t be loaded. The possible cause is that /usr/lib/x86_64-linux-gnu/nvidia/current/ is not in the library search path. You could try to create a symlink to that library:
sudo ln -s /usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-encode.so /usr/lib/x86_64-linux-gnu/libnvidia-encode.soIf that won’t work, please try to check permissions for that library and other libraries linked to this one (you can find such linked libraries with the ‘ldd libnvidia-encode.so’ command).