fra81

[fra81]

Hi,

thanks for the feedback and for the last head up. We think we know the reason and we will be addressing that too.

[fra81]

Thanks for the update.

The issue with the “ghost mouse” is known, it can happen under some circumstances and it will be fixed probably in the next update. The performance problem is not, so I wonder if this can also be related to the drivers. You may try to disable the ‘Use acceleration for display processing’ option in the Server preferences, Performance tab on the machine where you connect to.

If in the meanwhile you would like to send the logs, I’d be glad to take a look.

[fra81]

Let me clarify: the position where application windows are disaplayed doesn’t depend on the NoMachine software, but it is possible that, if NoMachine resizes the remote physical desktop to a lower resolution than the one you use when being physically in front of it, some of the applications remember the previous position and are moved off screen after the resize (this anyway looks like a bug in the window manager that should prevent that). Assuming this is the case, you can try to choose a larger resolution for the remote dekstop (you can find a Resolution slider in the session menu panel), if available.

Does the paid version use a different way of connecting?

NoMachine products from the Terminal Server family (from Workstation on) allows to create multiple virtual desktops, that are independent from the physical desktop of the server and have no constrain about possible resolutions (any screen size is possible). This also means that multiple users can use their own remote desktop independently.

[fra81]

Hi,

there is one known issue in version 6.11.2 that can cause a white screen:

https://www.nomachine.com/TR06R09772

But to confirm whether it is the same issue or a different unknown one, we would need to see the logs.

[fra81]

Hi Sam,

are you using the free version of NoMachine (and so you are connecting to the physical display of the server)?

In that case, are you maybe resizing the remote screen when connecting? Note that this can also occur automatically if you have the ‘Resize remote screen’ view mode enabled or ‘Match the client resolution upon connecting’ checked. I would try to avoid any resize and see if that helps.

[fra81]

Hi Gatos,

the images that you sent couldn’t be attached. Please send them to forum[at]nomachine[dot]com.

Also logs could be useful (see https://www.nomachine.com/AR10K00697 for server side logs and https://www.nomachine.com/DT10O00163#2 for the client).

[fra81]

Hi,

would you mind to reproduce again and send us the logs (https://www.nomachine.com/DT10O00163#2)?

[fra81]

Hi russelaugust,

if you are using the latest NoMachine version (6.11.2) on the client, you could be reproducing this known issue:

https://www.nomachine.com/TR06R09772

[fra81]

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.

[fra81]

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).

[fra81]

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.

[fra81]

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.

[fra81]

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.

[fra81]

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).

[fra81]

Hi, I’m glad to hear that your issue is fixed!

[Author]

Posts