Forum Replies Created
-
Posts
-
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.
Can you start the player from a terminal instead like this?
/usr/NX/bin/nxplayer --activegrabBtw, Check what’s configured in your nxs file because this setting will override your global setting (configured in Player). You can check what’s in the .nxs file by locating it in the directory defined in the ‘Connections and recordings’ field from the Settings -> Player -> Folders panel of the User Interface.
What is the OS on the nxplayer side?
Did you try a reboot on the openSUSE side? Is the issue just the Alt F4 key or other Alt+ combinations? Are other keys affected?Please describe the steps you take to reproduce the behaviour.
Hi, the logs don’t report any errors. It’s better to send us the entire .nx folder from the server side with debug enabled first, before reproducing the problem again. Please follow the instructions here and re-submit, https://kb.nomachine.com/DT07S00243. Thanks.