Forum Replies Created
-
Posts
-
Have you enabled “Resize remote screen” in the Display settings tab?
This setting will make your remote screen have the same resolution as your player’s window.
Please note that not any resolution will be allowed by your video driver if you are connecting to a physical desktop.
On the contrary, any resolution is allowed if you are running a virtual desktop.
Did you enable the lightweight mode as explained here?
It looks like a known problem.
Can you please try the attached library:
1) Open NoMachine Service program, click on “Sever running” and then on “Exit” to shutdown the NoMachine server.
2) Rename the original libnxdimi.dll file in your “C:\Program Files\NoMachine\bin” directory and substitute with the attached one.
3) Open NoMachine Service program again and restart the server.
Does the /usr/NX/bin/nxplayer.bin executable exist?
Can you try these commands:
# ls -la /usr/NX
# ls -la /usr/NX/bin
# ls -la /usr/NX/lib
The old behaviour can be restored by editing the server.cfg file.
Edit /usr/NX/etc/server.cfg by adding this line:
ConnectPolicy automigrate=0
Yes, it looks like the graphics card stops working when detaching the monitor.
You can take a look at this article for a way to workaround this problem.
This “mirror” effect is due to the fact that you are connecting from the client to the server running on the same machine. If with version 3.5 you didn’t get this effect it was because you were running a virtual desktop. This functionality is available in the Workstation 4 which is one of the products of the enterprise range. You can get it here in evaluation: https://www.nomachine.com/download/linux&id=13
This functionality is not supported in NoMachine for Windows in version 4.0.369.
On Linux it works in the same way server 3.x worked, from any client OS.
We are not able to reproduce this behaviour.
Can you send us the client and server logs? Submit to issues[at]nomachine.com referencing the topic title in your subject.
Logs can be extracted using the instructions here:
Update2:
good news, it seems. The latest version of the USB module that is ready but was held in testing doesn’t show this behavior. If you are so kind to contact the support, we’ll send you the sources you can compile (just run “make”) and put in the correct place to test.
Update:
we tried on multiple Fedora 19 and Ubuntu 13.10 machines and we reproduced the problem on one of them. The description you gave matches 100%. The source of the problem is in the USB kernel module. Unloading it fixes the CPU problem.
Edit /usr/NX/etc/node.cfg and set EnableUSBSharing key to “none”. Restart the server with /usr/NX/bin/nxserver –restart. Please confirm that the workaround works.
I’ve noted last versions of Nomachine (maybe the 4.36x series) put a kworker process to high CPU utilization, making almost unusable the remote physical desktop
For the moment for this release, there have been no changes that may affect CPU usage for quite a while, so I don’t think it’s directly related to changes to the NoMachine software. It seems more connected to a change to the Linux system. This kworker processes are started by the kernel for various reasons, for example to handle I/O or interrupts, except that there is no new I/O or interrupt compared to the software released 1 or 2 months ago.
Please send the output of the top command taken while somebody is connected to the physical desktop and while the NoMachine system is idle. Take the same output using top -H (this will show the threads one by one). Include the exact version of the Linux kernel you are using (so we can possibly try to reproduce it), the exact version of the NoMachine software and, if possible, the logs on the server (check here how to get them: https://www.nomachine.com/AR07K00677). If there is any thread entering a loop eating CPU it should be easy to find out which one it is from top and the logs.
See? It was easy. I get the same with the Belgian keyboard. I opened a TR:
https://www.nomachine.com/TR12K04110
You can track it and see when it’s resolved.
Hello
Just tried on Ubuntu 12.04 in Unity from Windows 7 and worked perfectly fine. Can you tell me more about your environment?
Please specify the keyboard layout in use on client and on server and also:
– Whether the problem arises connecting to a physical or a virtual display.
– Remote and local Windows/Mac/Linux version (Windows XP/7/8, OS X 10.x, Ubuntu xyz, Mint x.y, etc.).
– If on Linux, desktop version (GNOME. KDE, whatever) on client and on server.