Forum Replies Created
-
Posts
-
Are you connecting to a physical display or are you running a virtual KDE session? Or maybe are you starting a single application in a custom session and the taskbar you are talking about is the one on your local machine?
Can you specify the local and the remote OS versions?
We are not aware of any similar problem. We are now checking what can be the possible causes.
Thanks for reporting.
Hi,
xrestop output was just intended to rule out an abnormal allocation of resources, but I have nothing specific in mind (pixmaps would be best candidate to look at though).
While waiting for you to upgrade we will run more tests on that platform.
Hello,
this seems different from original reports (where CPU usage was high for both Xorg and nxnode processes).
Is it Xorg’s CPU usage always high? Or only when you are connected through NoMachine to that machine? Or when you disconnect the session?
Hi dhy,
first of all I would suggest to upgrade to the most recent version (4.2.27).
If you will still experience the same, can you please specify the version of the remote OS and the desktop manager (Gnome, KDE…)?
Also the output from the ‘xrestop’ command run inside the session could be useful.
Hi,
sorry for the delay in getting back to you.
Logs were examined and we couldn’t find anything wrong. In the meanwhile version 4.2.27 has been released. Can you check the new one?
Many more tests have been run in the time being on that platform without any problem and honestly I can’t imagine how NoMachine could disrupt the system keyboard and mouse. Are you sure this issue is triggered by NoMachine and it is not reproducible when working on the physical machine? Can it be originated maybe by a system update?
Hi,
that is not supported in the current version, but it is in our plans.
Related Feature Request is: https://www.nomachine.com/FR12K02799.
We cannot reproduce the described behaviour in our labs with current version (4.2.27).
Is upgrading a option for you?
In case you will still experience this issue, please collect logs as explained in https://www.nomachine.com/AR07K00677 and send them to forum[at]nomachine[dot]com.
Hello.
As for the first issue, we managed to reproduce it in our labs and we’re working on a fix.
To investigate further the second problem we would need log files. You can gather them as explained in https://www.nomachine.com/AR07K00677 and send them to forum[at]nomachine[dot]com.
About the third issue, that setting should be saved in a cookie. Do you have cookies enabled on your browser?
Hi mo-seph,
this is strange. Since your feedback, we started another run of tests, but all the reports we got so far seem to confirm the problem is fixed.
For further investigations, would you mind sending server side logs as explained here: https://www.nomachine.com/AR07K00677.
You can send them to forum[at]nomachine[dot]com.
Please collect log files as explained here: https://www.nomachine.com/AR07K00677.
You can send them to forum[at]nomachine[dot]com.
Hi,
we weren’t able to reproduce this issue in our labs so far. Can you please send us the “.xsession-error” file located in the home directory of the user owning the desktop?
Also a full set of logs could be useful. You can gather them following the guidelines in this article: https://www.nomachine.com/AR07K00677.
You can send files to forum[at]nomachine[dot]com.
Can you please also explain what you mean exactly with “remote pc freeze, but only Gnome Shell”. Other applications continue to work?