Forum Replies Created
-
Posts
-
Hi Snejok,
Could you confirmed or not that it is not recommended to use this browser via NX. In FF the fonts appear normal.
we were not aware of this bug in Chromium, so we can’t deny or confirm at the moment.
Maybe also Is it a reason of slow scrolling in chromium in NX?
Yes, if the whole page is rendered as a bitmap, surely this can be a reason for slowness.
Thanks for reporting.
Is there a way to determine which machine has properly installed h264 support for NoMachine besides trying to connect two machines and checking Display -> Change settings?
Correction: when the x264 library loading fails on server side, you would find the following lines in the display server log (in /usr/NX/var/log/node/C-* dir on linux):
Warning: Can’t load H.264 codec library.
Warning: Child process 7807 exited with code 2, ‘No such file or directory’.Hi milovan,
please find my tips inline.
Basically, on Windows I downloaded ffmpeg with shared option, copied from it libavcodec.dll and libavutil.dll into <install_path_of_nomachine>/bin.
Did you download the Zeranoe ffmpeg build maybe? In this case you need to copy also swresample-1.dll, which is a additional dependency of that package.
On Linux, I placed .so files into /usr/NX/lib and made sure permissions are exact like on other libs. Additionally, I also installed yasm for compiling from server article (which passed with no issues), as well as installing package h264enc (which is a shell script that makes it easy to encode DVD or video files to H.264; I read somewhere this package suggestion in search results) which pulls a few dependencies with codecs.
What .so files did you copy? Please list the installation directory content: ‘ls -l /usr/NX/lib’. Note that in order to enable H.264 on the server, you need the x264 library modified by us. You can either download it from https://www.nomachine.com/opensource and build it from source as explained in the article, or install the AVC Pack. The h264enc package you mention would not help.
I suspect that might be a problem in Kubuntu 14.04 which doesn’t have FFMPEG but its fork avconv (present on the machine) and that NoMachine possibly is looking for FFMPEG name rather than forked one, but I am not sure if that is a case.
We didn’t test so far with avconv.
Is there a way to determine which machine has properly installed h264 support for NoMachine besides trying to connect two machines and checking Display -> Change settings?
There’s not, at the moment.
Note that you need libx264 from our website on the server, ffmpeg on the client. If you need to connect also to the other direction and you want to use H.264 in both directions, you need libx264 and ffmpeg on both machines.
Please check the following:
1) is the “Resize remote screen” button selected in the NoMachine toolbar?
2) is the desired resolution listed among the available ones when accessing the system display settings in the remote virtual desktop?
3) do you have a .config/monitors.xml file in the user’s home on the server?
The monitor.xml file could force a certain resolution. If this is the case, you could either remove that file, or choose a different resolution by using the system settings menu in the remote desktop.
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.