Forum Replies Created
-
Posts
-
Hi, thanks for taking the time to report this. We have yet to add Fedora to our officially supported list and will do soon. Initial tests have not shown similar issues, so we will need logs from you of the two cases you are describing 🙂 I take it you are using the NoMachine v7.9.2 both sides? Reproduce and submit logs
1) of when you get the grey screen when connecting to the login window
2) in the moment you start the desktop session after having changed WaylandModes to “drm,egl,compositor”.For instructions on how to enable logs, please see this guide:
https://knowledgebase.nomachine.com/DT11R00182You can send both sets as attachments to an email to forum[at]nomachine[dot]com. Please insert the title of the topic in the subject of your email. Thanks!
It does, however, make perfect sense to have an uncompressed session to improve latency.
In practice it’s not like that. Fra81, one of our lead video core developers will explain why 🙂
We just checked that specific Debian version just to make sure and everything works correctly. CPU usage is normal, sessions work fine.
Regarding the upgrade, we can’t be sure about what happened. Did you install the free version on top of the existing legacy free version? Please submit nxinstall.log and nxupdate.log which you can find in /usr/NX/var/log/.
After that, I recommend a complete uninstall of NoMachine and removing /usr/NX /etc/NX and /var/NX $HOME/.nx completely, then reinstalling version 7.9.2.
NoMachine supports all the most common enterprise 2FA solutions. Here you can find details about how to set it up:
Integrating NoMachine with Various Authentication Methods
https://knowledgebase.nomachine.com/DT11R00187NoMachine is developing its own 2FA, fully integrated into the NoMachine system, which will be much easier to set up and use, and will come together with NoMachine Network.
I now understand what you mean. What you would like to achieve is available in the NoMachine terminal server range. Please download and try NoMachine Workstation.
As the other topic mentioned. It was something we had planned to add.
This is a typical case where having a feature request for uncompressed output can be misleading and doesn’t point out what the problem actually is. It makes no sense to make an uncompressed session just to improve the quality. The job of NoMachine is to improve the quality, so much so to give seamless and 1:1 rendering, but still compressed. How are we going to do that? With lossless refinement. There are two ways to do that: refinement with video encoding such as h264, x264,vp8, etc , which will never be 100% lossless, and progressive refinement that means you get to the stage where the last refinement is 1:1, 100% lossless.
When will this be available in production code? It’s work in progress 🙂 We work on refining the output everyday, day by day. Any new improvements we produce during development go into the production code at every release. When will this work be finished? Never. There is no code that you cannot improve in one way or the other 😉
I decided to do the down grade of graphics card driver version. Then the problem is solved.
Ok Chrys, thanks for letting us know. We suspected as much that the drivers were causing the problem.
First, can you check that the correct permissions are set on the Mac computer? Here you can find some further hints: https://knowledgebase.nomachine.com/AR09S01139. In some cases, after a OS update, it might be necessary to remove (uncheck) the permissions and grant again.
If that doesn’t help, please send us the logs. A similar issue has been reported here:
https://forums.nomachine.com/topic/no-available-desktops-on-this-server-4 and you can follow the instructions for logs there. We can then check to see if it’s the same problem indeed.Hi, from what you’ve written I understand that both userA and userB are connecting remotely to the computer. Are user A and B sharing the same system account to get remote access? If they are, it’s perfectly normal that the session to the physical desktop is being migrated. NoMachine understands that the user is the same because the account is the same and therefore switches the NoMachine remote session to the other device.
If you don’t want this to happen, each user must have their own system account on the computer they want to get access to. In that case, with the free edition, if “usernameA” is remotely connected to the computer and “usernameB” tries to connect as well, username B can be refused by userA or userA can decide to disconnect. With Enterprise Desktop, on the other hand, if user B connects whilst user A is remotely connected, NoMachine asks user A what they would like to do (authorise to share or refuse).
We took a second look at the stack dump.
Confirmed it fails exactly in the video decoder device initialization and this initialization doesn’t require any special parameter. At a glance this seems to be a device bug and, indeed, we found this same problem reported for Outlook:You didn’t say what exact driver version you are using. The first step, we’d say, is to update your video drivers.
Please try disabling hardware decoding on the Windows client.
You can disable it completely in the player.cfg. Please edit the file$HOME/.nx/config/player.cfgand set the configuration key “Enable hardware accelerated decoding” to “disabled”.I understand that the computer you are connecting from is Windows 10. What NoMachine product installed on the server side? Are you the administrator of that machine? What OS is the server side?