Forum Replies Created
-
Posts
-
Hi, this looks like you installed the wrong package. You have 86x-64 architecture which means you require 64-bit packages.
It’s the second button here: https://download.nomachine.com/download/?id=1&platform=linux.I’m happy to do that, but I don’t see where the setting is to enable debug, even if I can find the Take Logs.
Apologies I should have pointed you to the instructions (https://kb.nomachine.com/DT08U00298?s=logs#1.1).
On the Mac Mini, where you find the Take logs button in Server settings, there should be a level you can set as well. Set it to level 9, then restart the server (see the attached image). Pasting in the first few steps that apply to you from the document mentioned above.
Step 1 – Open the UI on the server host -> Settings -> Server -> Security
Step 2 – Scroll down the Security panel till the end to find section ‘Server logs’. Set there the log level as requested by the Support Team. Restarting the server is requested to make change effective, this will terminate all sessions. If this is not an option, use the manual procedure from command line.
Step 3 – Reproduce the problem.
Step 4 – Click on the ‘Take logs’ button: you will be requested to provide username and password of the administrator. Logs will be saved in a .zip archive.
However, in that context, is it safe to discard logs that are older than that?
Yes.
it is worth noting that I’m finding both Windows and Linux clients are able to discover this machine as active.
So you can see the Mac Mini when you are on the Windows and Linux clients, but you cannot connect from either?
A quick update on the investigation, thanks for your patience so far. We have not been able to reproduce this issue with any of the multiple Windows systems with WSL enabled in our labs. It is likely due to a particular combination of tests and drivers that we have no way of verifying. We’ll continue to investigate, however, but we’ll close this topic for now. Should we have something to report, we will provide an update here.
The key you tried to add in player.cfg is not supported.
On the NoMachine server host, it’s possible to enable a key in the node.cfg file to configure the packet prioritization flag for
NoMachine data traffic for data from server to client:#
# Set the DS (Differentiated Services) 8-bit field, previously known
# as ToS (Type of Service), at the IP network layer. Valid values are
# numbers from 0 to 255 in decimal or hexadecimal format (0x00-0xff).
# The six most significant bits should be set to the DSCP values recom-
# mended by RFC-2597 and RFC-2598 (e.g. use 72 or 0x48 for DSCP Class
# AF21). The two least significative bits should be set to 0. It is
# also possible to use the obsolete ToS flags (e.g. 16 or 0x10 for the
# LOWDELAY behaviour).
#
# ProxyPacketPriority 0x48Remove the pre-pending # from the key name.
The logs showed that there is no FullHD in use, but 3840×1080 (so height is 1080 but the width is 1920*2) hence why SW encoding is being used given that for resolutions higher than 4K, hardware encoding is disabled. Work has already started to remove this limitation.
Hi, this is the expected behaviour. It is the new default behaviour, introduced in 9.1.24, by which scaling mode preserves the aspect ratio during resize operations when scale-to-window is enabled. What you can do is hold Ctrl while maximizing the player window to get the old behaviour (for more details, refer to: https://www.nomachine.com/AR07W01315).
We were able to reproduce this and opened a Trouble Report, here’s the link you can use to monitor its status: https://kb.nomachine.com/TR10W11586.
If you can, it would be better to enable debug, restart, reproduce (so check that the nxnode is not running) and retake the logs (if you do it from Server settings > Security , Take logs), it will make sure we receive everything we need from the server side. Thanks!
You can modify the shortcut starting the Player by adding the option
--exit-alwaysto the command line. However, when doing so, the Player can still try to reconnect to the server if there is an unexpected error. If you want to avoid it by just terminating the Player as soon as any errors occur, change the key “Automatically reconnect to the server” to false in the file %USERPROFILE%\.nx\config\player.cfg.You can modify the shortcut starting the Player by adding the option
--exit-alwaysto the command line. However, when doing so, the Player can still try to reconnect to the server if there is an unexpected error. If you want to avoid it by just terminating the Player as soon as any errors occur, change the key “Automatically reconnect to the server” to false in the file %USERPROFILE%\.nx\config\player.cfgHi. Can you please save the logs from Player Settings > Security of that computer and send them? Also, what antivirus software are you using?
A zip file is recommended for attachments. Alternatively, you can email them to us at forum[at]nomachine[at]com. Thanks.
Thanks for all your input and collaboration. We have now inserted a Trouble Report which you can monitor at the following link: https://kb.nomachine.com/TR11W11634.
“Should I update to 9.2.18 and look at the server.cfg ?” If you can, yes.
We would also needs logs from both of you before you go back to the previous version (our Info team is already handling the temporary download link). This would help us immensely because we are unable to reproduce the issue. Are you able to send us the server-side logs so we can check them, enabling debug first? You can extract them using the instructions here: https://kb.nomachine.com/DT08U00298. It can be done directly from the UI in Settings > Server > Security, scrolling down, setting debug level, restarting, wait a few minutes, then Take logs.
Send them to forum[at]nomachine[dot]com or attach. Please use the title of this topic as the subject of your email. Thanks to both of you!