Forum Replies Created
Thanks for the logs. I can see there is a couple of issues that are fixed in NoMachine version 7, even though it’s not completely clear if they are related to the problem you are experiencing. So please upgrade also the server side to version 7 (you are using there version 6.13.1). If the problem is still reproducible, it would be great to have a new set of logs (client + server), so that we can rule out what is not related.February 19, 2021 at 20:30 in reply to: Black screen on accessing NoMachine Enterprise Desktop version #32058
unfortunately I still can’t see the relevant logs, the ‘.nx’ directory in the home of user ‘nxuser’, on the Linux machine.
In the meanwhile, to narrow things down, you could try to disable hardware decoding (see https://www.nomachine.com/DT10R00167&dn=menu%20panel#5.7).
CPU and memory usage are very low, so this really seems like a network problem. You can try to test this by using the ‘ping’ command towards the server during the slow down, or by transferring a file from the server to the client with any other tool. You can also try to gather NoMachine session statistics (run the menu panel within the session by Ctrl+Alt+0 or click on the page peel, click on Connection, then click on ‘Take the statistics’).February 15, 2021 at 10:08 in reply to: White screen and codec unknown after connecting to another workstation #31975
You seem to be experiencing this issue, already solved:
Therefore I suggest you to upgrade NoMachine to at least the last version 6, that is 6.13.1.
this problem doesn’t depend on NoMachine. When the machine is headless, the GPU is not working normally and some apps may fail to render correctly. If you can’t attach a monitor, you can try to use a dummy display adapter (HDMI dummy plug). In the forum post you mention, the problem was solved by updating the graphics card’s drivers.February 8, 2021 at 20:19 in reply to: White screen and codec unknown after connecting to another workstation #31840
please gather server side logs from wks 1 as explained in https://www.nomachine.com/AR10K00697, and client side logs from wks 2 as explained in https://www.nomachine.com/DT10O00163#2. You can send everything to forum[at]nomachine[dot]com. As a quick test, you can try to disable hardware encoding on the server:
1) Edit the node configuration file, /usr/NX/etc/node.cfg
2) Uncomment and disable the EnableHardwareEncoding key:
I’m sure you guys are tech savvy enough to tune it suitable for the real-time nature of NoMachine.
that was exactly the problem. A proof of concept was implemented and tested in our labs, but unfortunately the VideoToolbox encoder can’t work in fully real-time mode. It needs to buffer at least two frames before producing an encoded frame in output. This one-frame delay is not acceptable in a real-time application like NoMachine, where minimizing the latency has the maximum importance. And our tests showed that clearly.
That said, if this limitation is removed in future, NoMachine will be ready to leverage hardware encoding on Mac.
Can you attach also the user’s home/.nx directory from the server? Here are detailed instructions, if needed.
I think you get a point and such option would be useful indeed. We opened a Feature Request to track it:
Thanks for your useful feedback!
what you describe is the intended behaviour. On dragging operations NoMachine hides the local cursor and shows the remote cursor instead, so that the cursor sticks to the object that is being dragged. This avoids the effect of the local cursor moving “forward”. At the moment there is no option to disable this behaviour.
the flickering is very likely a problem of the video drivers when working headless. You can verify that by leaving the monitor attached when connecting through NoMachine.
In order to get either Gnome or Cinnamon to work I have to turn off gdm.
this means that the problem Cinnamon is having is related to the drivers (and graphics card) when running headless and excludes a NoMachine issue. When turning off gdm, NoMachine creates it own virtual display and Cinnamon is run into it, so that it doesn’t depend on the actual graphics card anymore. You may check for alternative drivers or keep gdm disabled or try to plug a dummy HDMI adapter into the server.
is there a monitor attached to the board? If not, can you try to attach a monitor and see if the issue persists?
I think this Feature Request is what you are looking for:
You can select to be notified when it is implemented.