Forum Replies Created
-
Posts
-
Can you send us the server side logs after enabling the debug level, as explained in https://www.nomachine.com/DT04M00076? You can send them to forum[at]nomachine[dot]com.
Additionally, please try to edit the connection in order to connect with SSH protocol (instead of default NX) and “System login” (Advanced tab).
Hi Mule52,
supported resolutions don’t depend on the NoMachine software, but on what is supported on the remote system. In other words, the 2560×1440 screen resolution will be available in your NoMachine session only if such resolution is selectable in the system settings of your remote Mac.
If that resolution is among the available ones on your Mac, then you may simply need to click on the “Resize remote screen” button (the one on the right of “Fit to window”). That will make the remote screen automatically resize to the resolution that will fit better in your local screen.
Hi ilker,
you may need to run a virtual session on your linux laptop, so that the physical desktop will not be affected by what you run remotely. Virtual sessions are supported by the NoMachine Workstation product. You can find the evaluation version here: https://www.nomachine.com/download-enterprise.
Alternatively, you can try the instructions of this article: https://www.nomachine.com/AR10K00710. There is explained how to manually setup a virtual X server.
Regarding the HTTP proxy, the typical usage in on the client side. For example, direct connections to the internet are not allowed at your workplace, so you need to configure a HTTP proxy for connecting from workplace to home.
More in this article:
Hi yaris,
I still think you are facing the same bug of the other post. This crash occurs when the UDP negotiation fails, whatever the reason that makes it fail. The correct behaviour would be to fallback to TCP silently.
A fix to that TR will be released very soon in the next update.
Hi cameron,
here are two possible issues. The first one is about the failure in establishing a connection and it seems the same issue tracked here: https://www.nomachine.com/TR08M05855. The normal behaviour would be that the connection falls back to using TCP seamlessly.
The second possible issue is about UDP being not functional with the firewall enabled, regardless the exception rule. We will do more tests in our labs with the same environment. Thanks for reporting!
Hi smartin,
the problem was known and a fix will be released with the next update.
Here you can track the issue:
Hi babbtong,
we were not able to reproduce the described issue with the same platforms. Can you please tell us:
1) Are you connecting to a headless Mac (no monitor plugged)? If yes, is it possible to try with a monitor attached?
2) Is 3D acceleration enabled in VMWare Fusion? Can you try to tweak this setting?
3) What is the version of VMWare Fusion?
4) Does the whole VMWare screen refresh when you pass the mouse over it, or only the pixels under the mouse pointer?
We reproduced this issue in our labs and opened a Trouble Report for tracking it: https://www.nomachine.com/TR06M05612.
Thank you for reporting 🙂
Thank you for the feedback.
Here is the related Trouble Report: https://www.nomachine.com/TR06M05611. It will be fixed in the next update.
Hi Tim,
we recently found a problem with UDP that could arise in particular conditions. Please try to disable UDP: Edit the connection -> Advanced -> uncheck “Use UDP communication for multimedia data”.
Logs show that the server is trying to use the H.264 codec even if it is not available. You should be OK with the workaround of disabling H.264 forcedly. Click on the NoMachine tray icon on the server (on the Mac), then on “Show the server status” -> “Server preferences” -> “Performance” -> “Use a specific display encoding” and select VP8.
We are not able to reproduce this problem in our labs, even when H.264 is not available. So would you be willing to help us in identifying the problem, we would need to gather more logs. Attached is a debug library with verbose logging enabled. It should be placed on server side as per following instructions:
1) sudo /Applications/NoMachine.app/Contents/Frameworks/bin/nxserver –shutdown
2) untar and place the attached library in the /Applications/NoMachine.app/Contents/Frameworks/lib directory (make a backup copy of the original)
3) sudo /Applications/NoMachine.app/Contents/Frameworks/bin/nxserver –startup
4) reproduce and send us server side logsPlease disregard my request for logs. We checked your logs already but unfortunately they didn’t help to point out the problem. We’re trying to reproduce the issue in our labs.
Hi chatmoa,
we were not aware of this problem. We will be testing with the same environment. In the meanwhile, server side logs could be useful. You can gather them by following the instructions in https://www.nomachine.com/DT04M00076. You can attach here or send to forum[at]nomachine[dot]com.
Lib names had “-<number>.dll” so I tried using with and without those additions in name (example: libav.dll and libav-56.dll). And still no luck.
That said for avcodec, how did you rename avutil? Maybe a screenshot of the content of your bin directory could help to clarify 🙂
In any case, everything should work out of the box if you just copy the zaranoe libraries without renaming.On a Linux side, I did compiling per instructions for server host, and confirmed libs are moved on correct location with correct permissions. You asked me for a ls -l command output so here it is: http://pastie.org/10200853
And here seems all correct.
At this point you could send us the logs for further investigation. Please find the instructions in https://www.nomachine.com/DT04M00076. You can attach the logs here or send directly to forum[at]nomachine[dot]com.