Forum Replies Created
-
Posts
-
It would also be useful to know more about:
OS and version on the side you are connecting from (client)
OS and version of the side you are connecting to (server)Thanks.
On the machine you are connecting to, please disable hardware encoding in NoMachine. You do this by going into Server settings > Performance > unticking the box in ‘Use hardware encoding’ (https://kb.nomachine.com/DT07S00237#2.7). Then connect again.
Could something have changed on the Windows machine, server side? The player logs you submitted show the server is not reachable. Please check that everything is still set up as it was when it was working. You can use this guide to make sure that all the steps have been followed https://kb.nomachine.com/AR04S01122.
If that does not help, we will need logs from the Windows server. Enable debug and extract them using the instructions here: https://kb.nomachine.com/DT07S00243. Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
The logs don’t reveal anything useful to understand the slow performance.
Please update to the latest version and then also try tweaking the quality slider and resolution sliders to see whether performance improves. See the following document for more about those:
https://kb.nomachine.com/DT09T00266 (Fig 16)
You should definitely watch out for NoMachine 9, coming soon. A tool that only applies to NoMachine I don’t think exists 🙂 You could take a look at alt-tab-macos.netlify.app, though please note that we have not tested this and can’t guarantee that it will give the desired results.
Apologies for not updating you. The logs show that the player didn’t receive anything on the port where it reads the multicast UDP messages (to know the servers available in LAN). And we’ve previously confirmed that NoMachine is broadcasting correctly on the Macbook server. So something is happening in the middle, and in the middle there is either the network or a firewall which we have no control over.
Did you already try:
disabling the FW completely on your Ubuntu machine?
checking whether the Macbook Pro (2017) machine can see the Ubuntu host and the other Macbook?
checking whether the other Macbook can see the Ubuntu machine and the Macbook Pro (2017) ?Maybe you altered a system preference? Is this the only key combination that is not behaving?
In the upcoming v9 we will be adding an option to swap Control and Command modifiers on the remote desktop. This new option in the NoMachine User Interface is intended to allow users to swap Control and Command modifiers, so that users connecting from macOS to Windows/Linux (or vice-versa) can comfortably continue to use their local shortcuts also inside the NoMachine session (Copy/Paste/Select all/Undo/Print/Search). When this option is not enabled, instead, the user has to use the remote modifier for applying keyboard shortcuts inside the NoMachine session.
In the meantime, you could check for a third-party tool that lets you change the Command+Tab to Alt+tab shortcuts. There are a few free options on the market.
You could be encountering an already known issue,
Only a part of the desktop is rendered on 4k monitors scaled at 150%
https://www.nomachine.com/TR11T10690Is there a scaling factor applied in the display settings of the server OS? The logs would help us to confirm that. You followed the instructions correctly, maybe try gathering the logs from outside the virtual environment?
From a terminal you can also try running
tar -zcf nomachineLog.tar.gz /usr/NX/var/logand share with us nomachineLog.tar.gz.Hi, we currently have a Trouble Report open on Bookworm for which the workaround is disable Wayland.
https://www.nomachine.com/TR10U11031.
However, we’d like to make sure it’s the same issue. Before you try disabling Wayland, could you enable debug and gather some logs from the RPi device? For instructions on how to enable debug and gather the logs, please check the instructions here: https://kb.nomachine.com/DT07S00243. Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
Hi, we have been investigating in the meantime (since you submitted the nxegl log) and we have a potential patch for the issue that you were encountering. If you are interested in testing a patched package, let us know 🙂
We’ve noticed from your dump that the wkscli DLL which is crashing when it accesses your WSL mount point is version 10.0.19041. You could evaluate updating your Windows machine to something more recent, since the latest Win10 is 10.0.19045.
Hi, we currently have a Trouble Report open on Bookworm for which the workaround is disable Wayland.
https://www.nomachine.com/TR10U11031.
However, our own tests have shown that it happens even when an HDMI screen is attached. So if possible, we would like to debug your device further. Before you try disabling Wayland, could you enable debug and gather some logs? We would need logs from a session to the Raspberry device as headless (no HDMI plugged), and then logs from a session with the screen attached, so one set of logs for each session. For instructions on how to enable debug and gather the logs, please check the instructions here: https://kb.nomachine.com/DT07S00243. Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
After a full analysis, we know the client fails to open because a system library raises an exception that causes the process to immediately close. When starting the machine in safe mode, the player has no problems so it means something loaded on the system (and not loaded in safe mode) is triggering the wkscli.dll exception.
While the dump is useful to understand, more or less, when the problem occurs, we didn’t find clear reasons to explain the issue in detail and offer an analysis about the exception, and about how it affects NoMachine.
The only hint we can give is to debug WSL (Windows Subsystem for Linux) and wkscli that is creating a pipe giving problems. Specifically, the exception seems to occur after the following error:
CreateFile: \\wsl.localhost\PIPE\wkssvc Result: BAD NETWORK NAME
The pipe is legit and usually created for the IPC over SMB calls, so maybe the problem is caused by a buggy library or Linux subsystem. Disabling WSL should be a way to stop creating the wsl.localhost mount point and verify if the player starts correctly.