Forum / NoMachine for Linux / Session HW encoding stopped working after NoMachine server upgrade from 7 to 8
- This topic has 9 replies, 4 voices, and was last updated 2 years ago by Britgirl.
-
AuthorPosts
-
October 13, 2022 at 10:28 #40728HynekParticipant
After installing latest NoMachine server (version 8) HW encoding stopped working. Connected clients show SW encoding only.
The server info:
Kernel: 5.15.0-48-generic x86_64 bits: 64 compiler: gcc v: 11.2.0 Desktop: Cinnamon 5.4.12
CPU: AMD Ryzen 5 5600G with Radeon Graphics
GPU: CPU IntegratedI inspected syslog and the logs fetched by the client, but I didn’t find anything relevant there.
Thanks for help!
October 13, 2022 at 17:04 #40745BritgirlKeymasterWe are not aware of a similar issue. Is this on Ubuntu or something else?
Can you submit a screenshot where the client shows SW encoding?
Can you send us the logs of the server? Please see the following document for instructions and submit them here or send to forum[at]nomachine[dot]com, making sure to use the topic’s title as the subject of your email. Thanks!
October 13, 2022 at 18:37 #40747opticbluParticipantSame thing happened to me on an AMD GPU, tried on Ubuntu 22.04 and OpenSUSE Tumbleweed for good measure
My terminal server at home has an RX550 and after the upgrade from 7 to 8, hardware encoding is broken
Does anyone have an RPM x86-64 link to a 7 series build?
October 14, 2022 at 07:23 #40752BritgirlKeymasterCan you submit a screenshot where the client shows SW encoding in the session?
Can you send us the logs of the server? Please see the following document for instructions and submit them here or send to forum[at]nomachine[dot]com, making sure to use the topic’s title as the subject of your email. Thanks!
https://kb.nomachine.com/DT07S00243
October 14, 2022 at 11:32 #40753HynekParticipantFor me the situation is a bit more variable.
When I connect from CPU i7-6820HQ GPU NVIDIA GeForce 940MX Windows 10 client version 7.10.2 I get HW en/decoding on both ends. When I connect from CPU Ryzen 5 5600G GPU integrated Windows 11 client version 8.1.2. I get SW en/decoding on both ends.
When I connect from CPU Ryzen 5 5600G GPU integrated (the same client machine as above) Linux Mint 21 client version 8.1.2. I get SW encoding on the server and HW decoding on the client.All the above cases are with server 8.1.2 and the same server system. The server logs sent to the email address.
October 15, 2022 at 11:34 #40760epiphany123ParticipantHi guys, I can confirm I’m experiencing the same behaviour as OP and @opticblu above on Ubuntu 22.04 jammy, kernel 5.15.0-50 with NoMachine server & clients 8.2.1 in Wayland.
the host is Intel Core i5-4460 & AMD CAICOS (DRM 2.50.0 / 5.15.0-50-generic, LLVM 13.0.1) and the clients are numerous.
I’ve tested this from (and to) Arch, from Windows 7/10 and Android devices, and it’s always SW encoding / HW decoding for the linux host machine, which results in poor performance and increased CPU usage. It was working splendidly for years with your version 7 on Ubuntu 20.04, 21.04, 21.10 and 22.04 as well, until the update to v8.
There are two other issues I’m aware of, that came with your v8 release. https://forums.nomachine.com/topic/white-screen-after-first-connect-since-v8 which I noticed from the get-go and can also confirm, but that’s really low impact.
However, what is highly impacting my work, is that you’ve changed the way you pick mouse position in Wayland, directly from udev which conflicts with other virtual input devices, blocking access to the remote desktop’s input, when the same is running an automation task. To test this, run a simple mouse click event while loop on the host, with ydotool, and attempt to get mouse movements/control on the NoMachine client side. Your Linux devs will know what I’m talking about.
I am seconding @opticblu’s request above. Can we have the old server version 7 (latest release before 8)?? Because quite frankly, I don’t have the time to engage into log submission, bug tracking, etc. for the software encoding issue (which I suspect is global for anyone using the host in Linux, or Wayland at least), since you’re not going to change your core logic and the way you utilise mouse/kbd input, which is the real problem for me. I currently have to run crons and kill-switches on session start, just to regain control of the host machine’s input.
Your Android app is unparalleled when it comes to ease of access and keyboard functionality, and with Wayland support, you’ve been paramount to a whole section of the Linux comunity. We’re not going anywhere, we just want to use the old v7 server.
October 17, 2022 at 12:52 #40784BritgirlKeymasteryou’ve changed the way you pick mouse position in Wayland, directly from udev which conflicts with other virtual input devices, blocking access to the remote desktop’s input, when the same is running an automation task…attempt to get mouse movements/control on the NoMachine client side.
What you describe is a new feature giving keyboard and input events from the local user logged-in to the remote computer priority over input generated by the user connected via NoMachine.
It is mainly intended to add a further security level to desktop sharing, so that the input (mouse and keyboard) of
the remote user connected by NoMachine will be effective only after the local user doesn’t produce any input for a certain period. When the NoMachine user gains control over keyboard and mouse, the local user can stop him/her at any moment by simply moving the mouse or typing something.To disable this behaviour, you can set this in node.cfg:
DisplayServerExtraOptions "-eventdelay 0"
Your Android app is unparalleled when it comes to ease of access and keyboard functionality, and with Wayland support, you’ve been paramount to a whole section of the Linux comunity. We’re not going anywhere, we just want to use the old v7 server.
That’s good to know 🙂 You can try contacting the web team via the website to see if they can share a link to the earlier version. But first we would appreciate knowing if the -eventdelay setting improves things for you with regard to the mouse position issue you mentioned.
Regarding the SW/HW/white screen issues described in the thread, we are still investigating.
October 17, 2022 at 15:38 #40787epiphany123ParticipantHi @Britgirl, thank you for your prompt reply! That’s helpful and it works to an extent, but it still relies on an open socket in order to take over control. Adding sleep arguments in the script works, but if you stop moving the cursor, the socket gets occupied again by the bot/automation script, and you have to wait for the next sleep/opportunity to take over precedence. The “-eventdelay 0” argument works great for actual hardware input, where the same is not coming from a virtual uinput in udev and can coexist in Wayland. Anyway, I won’t nitpick as this is possibly something that <1% of everyone using your software, will ever notice. I’m very interested whether running the last v7 server will work, and if it will, for how long, with the newer clients (Android & dekstop)? Are there any incompatibilities that I must be aware of, or any crashes that this may cause, because stability is of course what’s most important for me. I’ve noticed the rare core dumps and frozen sessions with the old v7 server in Wayland, which may be attributed to the then working HA. Is this something you’ve worked on/fixed in the newer version?
Whom should I approach for a .DEB package of NoMachine 7.10.2.800 (or whichever is the latest v7 server version)? Will stopping automatic updates work, as I see they currently install automatically, as the option gets re-enabled after reboot even if you try to opt out (possibly due to a configuration/UI bug)?
October 28, 2022 at 16:38 #41040opticbluParticipantAny developments on the AMD GPU encoder issue? Thanks
October 31, 2022 at 16:02 #41126BritgirlKeymasterHi, here is an update.
Logs that were submitted showed that HW encoding was not in use with v8, but there were also logs for v7 and in those we also saw the HW encoding was not in use 🙂
Nothing has changed between versions how HW vs SW encoding is handled. They only think we can think of is that the “Info” that is printed in the GUI about the codec was improved (i.e made clearer) in version 8, and so it’s possible that when you were using v7, you thought HW encoding was being used when in actual fact it wasn’t.
Given that we cannot reproduce the issue, the only way to check that you were using HW encoding in a v7 session is for you to send us fresh logs. We’ll then check them. So to receive earlier v7 packages can you drop us an email to forum[at]nomachine[com] specifying which package you want (deb, rpm or targz) so we can send you a download link? Thanks!
-
AuthorPosts
This topic was marked as solved, you can't post.