Forum Replies Created
-
Posts
-
In the past a delay was observed due to the initialization of the hardware decoder with specific graphics cards on windows. So one thing to try is disabling the hardware decoding by changing the following key to ‘false’:
<option key=”Enable hardware accelerated decoding” value=”true” />
The configuration key is in the ‘C:/Users/<username>/.nx/player.cfg’ file. If you are using NoMachine 5, the same setting can be changed via the ‘Disable client side hardware decoding’ checkbox in the Display settings GUI.
Should the problem persist, we would need your logs for further investigations. You can gather them as explained in https://www.nomachine.com/DT07M00098 and send them to forum[at]nomachine[dot]com.
Hello Eric,
this actually looks like a problem with your drivers. What NoMachine does is querying the screen content few times per second. This is not a high work load and the X servers normally handles it without any problem on the widest range of systems we tested.
Can you provide more info on your graphics card and the drivers? Is it possible to upgrade the drivers?
Hi Sean,
are you connecting with the same user that owns the remote desktop? That option disallows connections from different users unless the desktop owner explicitly accepts them. But if you authenticated to the server using the same credentials as the desktop owner, no further confirmation is required.
So what you ideally need is the NoMachine Network service above mentioned. It will be perfect for users who either don’t know their IP or are not able to configure their router for whatever reason.
NoMachine Anywhere is in its final stages of development as part of the version 5 roadmap.
Can you also tell us if you are using the SSH or the NX protocol? If you are connecting with SSH, one possible reason is a timeout in the DNS reverse lookup. In that case a solution is adding the following in the ‘sshd_config’ file on the server:
UseDNS no
Yes, that can be done. NoMachine automatically maps the port on the router and shows the IP address to connect to. Here you can find a step by step with screenshots (see the Using NoMachine for remote access to a computer over the internet section).
More details on how the port mapping works can be found in this article: https://www.nomachine.com/AR11L00827.
Note that all this will work even more smoothly when we will release the NoMachine Network Service (or NoMachine Anywhere, we are still debating what name is the best). With this service the user will not have to care about anything.
Hi,
this article may help you: https://www.nomachine.com/AR09L00814.
We reproduced the issue in our labs. Here is the relevant Trouble Report:
https://www.nomachine.com/TR10M06126
As a workaround, installing pulseaudio should do the trick.
Thanks for the report!
Unfortunately that is not possible with the NoMachine free version, since it only allows to share the physical desktop. In other words, it is not possible to show a login dialog to the local user and, at the same time, the desktop to the remote user.
What you would need is the Workstation for Linux. That way you can run a virtual Linux desktop session, so 1 ) no one will be able to see what you are doing and 2) you won’t need to blank the screen and worry about not having remembered to disconnect from the physical desktop.
Hi milosh,
that issue is known and it is tracked in this Trouble Report: https://www.nomachine.com/TR10M06095. The fix will be included in the next update.
To answer ‘krislo’ and ‘loginatnine’:
thank you for the xinput output. It looks like the same problem of TR10M06101 and we confirm it will be fixed in the next update.
Regarding:
b) If I need to take back control of my PC without tracking down the client that is connected and disconnecting it, I can’t.
Not allowing to gain contol over the machine locally while the remote user is connected was intended as it seemed the safest choice. To unlock the screen in the scenario you describe, the user can connect with NoMachine from a different localtion and terminate the first connection. Alternatively the user could connect with SSH and do that from command line (‘/usr/NX/bin/nxserver –disconnect’ switch on linux, see ‘–help’ for further info, or ‘/usr/NX/bin/nxserver –restart’) or even switch to TTY locally with Ctrl+Alt+F* shortcuts, provided he has the required privileges for disconnecting the session or restarting the server.
About the bug reported by ‘domwell25’, we will check it and fix ASAP. Thanks for reporting!
Hi Eddie,
we will be checking. Can you tell us about the version of Slackware and of your browser? Does it occur with a different browser, if you have any other installed?
Hi noetus,
unfortunately the problem is not clear to me. Can you please let us know:
1) Windows 8.1 is on client or server side? What platform is on the other side?
2) Dual monitor is on client or server side (or both)?
3) Is it the NoMachine player GUI that doesn’t receive clicks or the remote desktop?
4) When you say that you can’t log in, you mean that you can’t log in from the client to the remote session, or that the remote system is in the login screen and you can’t log in to the desktop?
5) What is the display manager application you are talking about?
Hi krislo,
it is likely the same problem, but for a confirmation please send us the ‘xinput’ output from the server machine.
Thank you for the info!
We reproduced this issue with a wireless device and found the problem.
Here is the Trouble Report for tracking the issue: https://www.nomachine.com/TR10M06101. It will be fixed in the next update.