Forum Replies Created
-
Posts
-
What you can look for in the logs is this indicator:
ERROR! Bitrate is equal or below 0.
VCE: WARNING! Failed to set parameters.instead of these:
VCE: WARNING! Failed to init device.
VCE: WARNING! Failed to create encoder.Just a note about VP8 decoding/encoding.
Prior to the more recent update (8.7.1 for Android/iOS) the NoMachine app for iOS and Android used VP8 as the default decoding method. With 8.7.1 it is now H.264 on mobile as well(see here for more details https://kb.nomachine.com/SU07U00248).
As for the HW encoding on the Ubuntu side, there is a bit of a mess with the drivers you have installed. Is it possible for you to revert back to the drivers version you had around June 23, because logs indicate that was the time when the encoder went through initial stages of initialization (so drivers were not actually failing). Then, on the server side, in the node.cfg file set the EncoderMode key to ‘bitrate’. Then try connecting.
We’ve now opened a Trouble Report for this issue. You can monitor its status here: https://kb.nomachine.com/TR08U10980
Hi, you can try disabling UDP as a workaround:
– go the Player -> Machines panel
– enter ‘edit’ of the connection
– go to the Configuration panel
– Uncheck option ‘Use UDP communication for multimedia data’Does this help?
This is fixed in version 8.8, https://kb.nomachine.com/SU07U00247.
TR07U10939 – Sudden termination of Xorg after certain events sequence
Link to TR: https://kb.nomachine.com/TR07U10939
We’re working on supporting Wayland, natively without XWayland, but it’s not a priority at the moment, so don’t expect this very soon. By the way, the client runs on top of X, and as such it needs the compositor to support the keyboard grabbing on top of XWayland in order to work correctly. If this is not the case, then our keyboard grabbing can’t work.
NoMachine is designed to work out-of-the-box on Linux headless machines. It can detect when the X server is not running and so runs its own virtual display.
This is duplicate of https://forum.nomachine.com/topic/windows-10-client-to-linux-nx-server-no-printers-2.
If I understand correctly, what you need to do is set the “lock the physical screen on disconnect”. This is useful in conjunction with screen-blanking.
When the screen blanking feature is activated, the remote screen is blanked, and the remote keyboard and mouse are locked whilst the user is connected by NoMachine. I.e. operations made on the physical screen by the NoMachine user are not shown and the local user cannot interact with the desktop until the NoMachine user logs-out.
As soon as the session is disconnected, the remote screen is unblanked, mouse and keyboard are released. To avoid this, it’s possible to activate the automatic lock of the screen, even if the user didn’t lock the screen before disconnecting by NoMachine.
See here more details:
https://www.nomachine.com/protecting-the-host-screen-during-a-remote-control-session
and
How to enable screen blanking and the automatic lock of the screen
https://kb.nomachine.com/AR07M00851Please follow the steps that Tor wrote here and report back.
Windows client freeze and cannot restart without reboot (continued)
At the moment it’s not possible, but in Network (see our introductory page here https://www.nomachine.com/network) there are going to be a big number of different “tricks” to always be able to connect, so router hole-punching and so on, and among them also these “inverse connections”, so that you can “switch direction”.
Please run in a terminal on the machine where you installed NoMachine Terminal Server:
sudo /etc/NX/nxserver --version sudo /etc/NX/nxnode --versionHi, thanks for reaching out to us 🙂
The key to understanding your issue is the input peripherals connected to the Mac (by the way, nice workaround!). Since you don’t need to activate the Player window to work on Mac, NoMachine is not deactivating your energy saving parameters. Try this: when the NoMachine Player is in fullscreen and before using the Mac, click in the Player window to activate it (i.e to give it focus)
Can you try disabling hardware decoding on the Fedora side, please?
First exit the Player on the machine you are connecting from by right clicking on the !M icon in the sytem tray and clicking Exit Player.
Edit %USERPROFILE%\.nx\config\player.cfg and set:
<option key=”Enable hardware accelerated decoding” value=”false” />
Then create a new session and check if you still have the white screen.
If you do, set that key to:
<option key=”Enable hardware accelerated decoding” value=”disabled” />
and create a new session.
The first setting disables the use of HW decoding but the codec library is still loaded, while the second settings
disables completely the HW decoding and cannot be set via UI.Let us know the result. If it works, it would be useful to know some hardware details so we can investigate internally. Which is the client side computer model, the graphics adapter name and the driver version?