Forum Replies Created
-
Posts
-
Hi, and welcome to the forums 🙂
you can try to disable NoMachine HW decoding on the “problematic” laptop. To do that, follow the instructions here: https://kb.nomachine.com/AR07U01202, choosing to completely disable (point 3). I’ll write them here to keep the info in this thread.
– Exit the Player (right click the !M icon in the system tray and click “Exit the player”)
– Locate the player.cfg, on Windows the path is typically %USERPROFILE%\.nx\config\player.cfg.
– Open in notepad (rename the original cfg to not lose it) and find the “Enable hardware accelerated decoding” key and set it to ‘Disabled’ like this<option key="Enable hardware accelerated decoding" value="disabled" />
– Save and close.
– Re-open NoMachine.
– Try and connect again.
– What happens? If you get the same problem, then we would need to see the logs from both client and server sides.For the server side, so the MiniPC side, please follow the instructions here for Windows, https://kb.nomachine.com/DT07S00243?s#2. Instead, for logs from the affected laptop, tick the box “Don’t delete log files on exit checkbox” in Player settings: Open the main window from the UI -> Settings -> Player -> Security panel, before starting the session to reproduce the problem. Then find the .nx folder in your user’s home, and zip it up. The .nx folder is hidden. To find it, write the following in the address bar or the file browser: %USERPROFILE%\.nx. As an alternative, you may navigate through the computer folders till the user’s home and insert .nx in the navigation toolbar to reach this hidden folder. The path can be similar to: C:/Users/nomachine/.nx.
Send everything to forum[at]nomachine[dot]com.
Hi,
Glad to know it’s now working, but we can keep this topic open for a while in case you need to report back.
After installing all the latest updates to Fedora 39, this also broke and seemed to fail in the same way.
This could be related to this TR https://kb.nomachine.com/TR04V11131 but it’s hard to say without seeing logs from that server as well.
CRCinAU, please see: https://forum.nomachine.com/topic/fedora-40-nomachine-not-working#post-48737
Hi,
your issue could be related to this Trouble Report: https://kb.nomachine.com/TR05V11141.
If you send us the logs from the server side (follow the instructions here) we can verify them. Follow the instructions here and either submit here as a zip or send directly to forum[at]nomachine[dot]com.
https://kb.nomachine.com/DT07S00243.This sounds like a problem with the macOS installation and/or the AWS instance. If the problem was with NoMachine, it is unlikely that you would be able to access other applications from the dock during the remote desktop session. You should look for apple crash reports for Safari, see this link for instructions: https://support.apple.com/en-il/guide/console/cnsl664be99a/mac
Please see my response to another topic about the macOS beta Sequoia release,
https://forum.nomachine.com/topic/macos-sequoia-issues#post-48635. For the time-being we’ve registered your report and we’ll be checking that this is not occurring when Sequoia comes out of beta. Thanks for submitting.
Is it just Safari in the session which is freezing (so you can interact with the remote desktop and/or other applications whilst it’s frozen) or is it the whole session window which is freezing (so after Safari freezes, it’s not possible to interact with anything else in the session window)?
This sounds similar to an issue for which a fix is planned in the upcoming maintenance 8.12. Take a look at the Trouble Report here, https://kb.nomachine.com/TR11S10411, and try the workaround.
Please check permissions on the macOS system.
System Settings > Privacy > Accessibility and then “+” and add NoMachine. If it’s already there, remove and add it again (see this article for more information https://kb.nomachine.com/AR11Q01061).
We’ve not been able to reproduce your issue with or without a keyboard attached to the RPi device.
Those logs you attached are from 2020 and they indicate a NoMachine 6.9 on Windows (player side by the looks of it). Make sure that this version is updated to the latest 8.11. Which Windows version is it exactly? Then on the Raspberry, which is on the server side also make sure that the NoMachine software is updated to the latest 8.11.
Then, we will need fresh logs of a new session once you have follow the instructions here, and the logs must be from both sides.
https://kb.nomachine.com/DT07S00243.Also, which specific Raspbian version? (please note this has since been superseded with Raspberry Pi OS).
We have a Trouble Report open for this issue which you can monitor using this link: https://www.nomachine.com/TR05V11150. A fix will be released in the next maintenance, NoMachine 8.12.
Hi, thanks for your feedback. We’ll look for ways to improve that behaviour for all displays and user habits because we understand that it can be annoying.
It was tested before I created this issue. It does not have any effect.
I see, I didn’t see you mention that earlier. Anyway, we are still unable to reproduce the problem with grabbing the keyboard on Plasme 6. But we did find a bug report on the KDE bugzilla. It seems very like your issue.
https://bugs.kde.org/show_bug.cgi?id=489113
For now, we suggest to downgrade to the environment that you said is working for you and wait for KDE to release a fix.