Forum Replies Created
-
Posts
-
Hello milovan,
yes, you can expect less lag with the H.264 codec. From our tests, H.264 uses 20-30% less bandwidth and takes 20-30% less time to encode a frame. Both those aspects will impact the latency.
You may also be interested in our upcoming feature about hardware H.264 encoding:https://www.nomachine.com/FR03M0290
This implementation will help reducing the encoding time and the CPU usage considerably.
Hi Paulo,
I think you may find this article useful:
How to use NoMachine 4 on a headless Linux server
https://www.nomachine.com/AR10K00710Hi yaroslavvb,
a problem with breaking clipboard functionality was fixed in version 4.5.0: https://www.nomachine.com/TR02M05022. Is it possible that is the same issue?
Regarding point 2, updating the system clipboard only when focusing out from the session window was a design choice. Desktop sessions can be shared among different users, and this way was chosen to minimize undesired behaviours.
Hi pmatos,
the blurring/refocusing effect you see is due to the progressive encoding technique used to increase the responsiveness. It can be disabled by checking the “Disable multi-pass display encoding” checkbox in the ‘Display settings’ tab from the menu panel. In the same panel you can tweak the Quality slider to find the better compromise between quality and performance.
The colors shift is due to the colorspace conversion required by the encoder. Find here the Feature Request addressing this issue: https://www.nomachine.com/FR03M02907.
Slowness depends certainly on the network bandwidth. Enabling the H.264 encoder would be a way to lower the used bandwidth. Here you can find the relevant info: https://www.nomachine.com/AR10K00706.
Finally, since you are connecting to a linux server, you may want to try the “lightweight” mode. That would help with bandwidth usage and would provide perfect quality for most graphics elements on screen. Here are the info on the lightweight mode: https://www.nomachine.com/AR02L00779.
In order to enable the lightweight mode, you need one of the Terminal Server products. Evaluation packages can be downloaded from this page: https://www.nomachine.com/terminal-server.Hi Ammar,
I realize I had probably misunderstood your first post. In the scenario you are describing, if I understand correctly now, a user is moving the mouse plugged into the server machine, while another user is watching his actions remotely through the NoMachine session. And the cursor movement in the player window doesn’t appear to be real-time, but delayed.
This description represents the expected behaviour. NoMachine algorythms add some frame buffering when there is no user input on the session in order to make the playback smoother. We can evaluate if making this feature optional.
Hello Ammar,
thank you for your feedback.
The “remote cursor” being more sluggy is somewhat expected, since a round trip is required to update its position and the delay depends on the network latency. For that reason keeping “Show the remote cursor” disabled is preferable in most cases, given that also the local cursor is updated with the remote cursor shape. Can you explain what is the reason why you prefer to see the remote cursor?
Regarding your request to hide the local cursor, this is not currently possible. Also for this request we would like to know more about your use case, and we will evaluate your feature request in the future.
Hi Moorecm,
sorry for the delay in getting back to you. You are right about the “uncooperative colors”. Unfortunately some colors may suffer from the colorspace conversion to the YUV format, that is the dowsampled format required by video encoders. Anyway we are aware of the problem and are working on a solution consisting in a lossless addtional encoding pass, to be introduced in the NoMachine display protocol.
Here is the relevant Feature Request: https://www.nomachine.com/FR03M02907
As for the other problem with the non-persistence of display settings, we are not aware of such problem and we are not able to reproduce. Should it happen again to you, we would be glad to take a look at the logs.
Here are info on how to gather logs: https://www.nomachine.com/AR07K00677
Thank you Krusher,
you were right in saying that it is the particular combo to produce the blurred text. Unfortunately some colors may suffer from the colorspace conversion to the YUV format, that is the dowsampled format required by video encoders. Anyway we are aware of the problem and are working on a solution consisting in a lossless addtional encoding pass, to be introduced in the NoMachine display protocol.
Hi murky,
the lock screen feature is currently available only on Windows but it is being implemented also for Mac and Linux and it will be available on those platforms in one of the next updates.
Here is the relevant Feature Request:
https://www.nomachine.com/FR09I02610You can check the box for being notified when it will be implemented.
Update on the disconnection problem:
What the logs show is the expected behaviour. The user connected to the server is not the same user logging in remotely (“root” vs “rbt”). You can either use the same user or set the PhysicalDesktopAuthorization configuration key to 0 in the /usr/NX/etc/server.cfg file. This will allow the connection even if the owner of the desktop is not the same as the connecting user.
Can I assume that the version you tried years ago was the NX 3 free version? In this case, note that NX 3 supported virtual desktop sessions also in the free version, while the free version of NoMachine 4 only allows to attach to the physical display, so it wouldn’t be exactly the same way.
As for the reported problem, logs are still under investigation.
Regards
Hi claus,
the desktop environment in use remotely doesn’t make any difference generally. What can make a difference would be the used protocol, specifically the “lightweight” protocol. I assume you are using the NoMachine free version to connect to the physical display of your remote machine. The lightweight protocol is available in a virtual desktop session or in rootless custom session (with the latter you can forward a single application instead of the full desktop, which is what you may want). To enable those types of session you need one of the Terminal Server products: https://www.nomachine.com/terminal-server. They are available for evaluation.
More info on the lightweight protocol here: https://www.nomachine.com/AR02L00779.
As for the problem you are reporting, we would like to see the logs. You can gather them by following the instructions here: https://www.nomachine.com/AR07K00677. You can attach them here or send to forum[at]nomachine[dot]com.
Hi thomasneh,
1) Please send us a complete set of logs that you can gather by following the instructions in https://www.nomachine.com/AR07K00677. If you prefer, you can email them to forum[at]nomachine[dot]com.
Furthermore, we would like to see a screenshot of the Display settings tab, the one shown at paragraph 5.6 of this guide: https://www.nomachine.com/DT10K00060.2) Is it the local or the remote host to turn black? Logs of point above can be useful here too.
3) We checked the ffmpeg package of the link in option 2. This pre-built avcodec has also a dependency to swresample-1.dll. So what you need to do is just copy swresample-1.dll to C:\Program Files (x86)\NoMachine\bin and it should work.
You could also use the ffmpeg package we provide here: http://www.nomachine.com/opensource.
Instructions for compiling are here: http://www.nomachine.com/AR09K00690.4) That warning is not critical and it won’t prevent the software from working correctly. Anyway it will be fixed in the next update.
So what could be causing the
Error: No nodes available for user’s profile’.
That problem seems due to a wrongly formatted key in the cfg file:
Error: Parse error at display option h264,mjpeg,clipboard.
Consider that no change is required in the configuration in order to get H.264 working. If you leave the defaults, H.264 will be automatically used when available.
Anyway, if I understand, you are now able to connect. So please send us a new set of logs when the session is running, as per instructions in my post above. We need client and server side logs.