Forum Replies Created
-
Posts
-
@martinidry, do you get a situation similar to the samples uploaded by Enverex (thank you!) in the other topic: How can I improve quality when using H264 ?
Hello.
A problem with VP8 codec could explain why disabling X11 drawing mode makes the whole desktop stop working. Could you provide some more detail: you see only a black screen, connection failure or what?
About H.264, it works in X11 mode as well as VP8. H.264 is the first choice, when available. Video encoding and X11 work together, an optimizing algorithm chooses the best mode in real time: the specific video codec in use doesn’t matter.
@martinidry and @Enverex
H.264 is the recommended choice because it offers better quality and faster encoding/decoding process. Consider it is also implemented in many GPUs, with obvious leverage of the offload to specialized hardware.
By the way, I think I’ve been able to reproduce the behavior you are complaining of. Rather than a low quality, I see a sort of light “shift” in colors. It is perceived with some specific color combination, so that hasn’t been noticed before. In order to improve the situation, keep multi-pass encoding enabled.
I’m going to open a Trouble Report to get the issue quickly fixed.
Thanks for the update. Probably you need to install XQuartz on the Mac client host. Start the X11 application under the Utilities folder and it will point you to the download page.
Should it not work, something else is going bad on the Mac client side. If you cannot get the client log, would you provide more info about that? I’ll try to reproduce on my own. I’d need to know:
- The Mac OS version
- If problem occurs with some specific application run in floating window mode
Free version does not restrict access to the root user.
By the way, could you retry with node.cfg modified as in my previuos post and send the log again?
In headless systems it could happen that video card goes into sleep mode. Try to turn off the display manager completely with
systemctl stop gdmand disable the automatic start on boot withsystemctl disable gdm. In that way, NoMachine will run its own display server.Hello. In NoMachine 6 it looks working. I’m wondering if your issue is related to the mouse input setting of your desktop environment (is it GNOME?) for example the double-click speed.
Is it a headless system?
It could be a misconfiguration of the desktop environment. Could you create a new user in the system and try to create remote session using her credentials?
Please raise the debug level from 6 to 7 in node.cfg and server.cfg:
SessionLogLevel 7Keeping the old log folder could also be helpful. In node.cfg change the related option to 0:
SessionLogClean 0Hello dmoors, a Trouble Report has been opened: https://www.nomachine.com/TR07P08707
Use the “Notify me” box to follow the state.
Hello dmoors,
it seems such an issue occurs only for “custom floating window” session type and Windows client display set to 16 bit depth (that is often the case when the Windows client is reached by Windows Remote Desktop).
Could you confirm is your case similar?
Please, reproduce and collect the server and node log following this: How do I collect the NoMachine log files?
Then send log to forum (at) nomachine (dot) com
NoMachine for Linux is able to use GPU for video encoding:
What do I need to do to allow NoMachine software to use H.264?
How to use Intel H.264 HW encoder with NoMachine on Linux platformsWhat I meant is option you mentioned does not control such feature.
Hello, that option has no effect on servers running on Linux systems. If you want to change it anyway it is named “EnableDirectXSupport” in node.cfg.
In the log you posted I wasn’t able to find a reason for the authentication failure. Could you run these commands and show the output:
sudo -l -U stan
sudo -l -U admin