fra81

[fra81]

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!

[fra81]

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?

[fra81]

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?

[fra81]

Hi krislo,

it is likely the same problem, but for a confirmation please send us the ‘xinput’ output from the server machine.

[fra81]

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.

[fra81]

What you descibe may happen if NoMachine is not able to get the current screen resolution from the system. In the past various glitches have been observed on headless Mac machines, not entirely due to NoMachine, so I would check if a reboot or a restart of NoMachine services solve the problem.

We’ve tried to reproduce this issue in our labs, without success. If you are willing to help us with investigations, please contact us at forum[at]nomachine[dot]comand we will be glad to send you a debug library.

[fra81]

Hi iceback,

that spinner means that something is preventing the client side from receiving any data from the server. At present we are not aware of any other condition for it to show up than a real network outage. If this is not the case, please gather logs as exaplained in https://www.nomachine.com/DT04M00076 and send them to forum[at]nomachine[dot]com for further investigations.

[fra81]

Hi Makkia,

when you say the graphics card “knows” 1650×1050 resolution, do you mean that such resolution is available if you open the system resolution settings on your Windows machine?

Does the RDC client connect to the physical desktop of your Windows machine, or does it connect to a virtual desktop (which is possible with Professional Windows versions)?

Regarding the two checkboxes, “Match the client resolution upon connecting” will make the remote desktop resize to the biggest resolution, among available ones, that would fit in your client monitor. This is done every time you connect to the remote desktop.
“Use custom resolution” will make the remote desktop immediately resize to the given resolution or to the nearest one.

[fra81]

We did not reproduce this issue in our labs on Ubuntu 12.04 with MATE. Can you tell us your exact Ubuntu version?

Please also send us the output of the ‘xinput’ command run on the server machine.

[fra81]

Hi TeutonJon,

we reproduced this issue in our lab and opened a Trouble Report: https://www.nomachine.com/TR10M06072.

Thank you for reporting!

[fra81]

Hi Lantizia,

thank you for this report, we are going to check it in the same environment. The expected behaviour is that user input is blocked. This is certainly a bug, since the tens of Linux distributions we tested it on don’t have this problem.

[fra81]

Hi Hoijima,

your problem is known and will be fixed in the next update. Here is the related Trouble Report: https://www.nomachine.com/TR08M05893. Please check the suggested workaround.

[fra81]

Please provide more info on your environment:

– NoMachine product and version on local and remote machine (free version, Workstation, etc).

– Whether the problem arises connecting to a physical or a virtual display, or to a custom session.

– Remote and local Windows/Mac/Linux version (Windows XP/7/8, OS X 10.x, Ubuntu xyz, Mint x.y, etc.).

[fra81]

Hi iceback,

don’t forget that what you have in upload also matters. I would check the real bandwidth on both directions. Most important is the direction where graphical output flows.

[fra81]

Scaling the display to fit your window is already possible in version 4. Please open the menu panel and find the ‘Fit to window’ icon in the Display settings. That is also available in the quick action icons at the bottom of the menu panel.

[Author]

Posts