Forum Replies Created
-
Posts
-
Hi snejok,
we observed a similar behaviour in our labs with the same environement. Firefox seems to actually draw by bitmaps and it is not suprising that the codec (along with the other techniques developed by NoMachine for the new display protocol) performs better in these circumstances.
However we are already working to provide the best experience in lightweight mode even with the graphics-intense drawing performed by some modern applications. In version 5.1 is already implemented https://www.nomachine.com/FR01N03003. Further optimizations will come 😉
Hi,
does the spinning wheel stay forever? Or does the connection recover at some point if you wait?
To understand what is going on in this case, the session logs would be more useful than the statistics. Please find here the instructions on how to gather them: https://www.nomachine.com/DT07M00098. You can send the logs to forum[at]nomachine[dot]com.
Hi,
we can’t reproduce any problem with the same platforms in our labs. To investigate this issue further, we would need the logs from the client and the server side. Please find the instructions here: https://www.nomachine.com/DT07M00098. You can send them to forum[at]nomachine[dot]com.
Hi Larry,
at the moment NoMachine only uses the NVENC capabilities on cards of the Maxwell generation. That is because NoMachine relies on some encoder features that are not fully supported in the previous Kepler generation, and that is the case of the K520 card virtualized in the G2 instance.
However we are already working on a special mode that can work with Kepler cards without glitches, and we are going to enable NVENC on such cards in the next release.
Is it possible that there have been other changes in you system (e.g. a bigger monitor)?
There are a few requisites to fulfill for actually enabling H.264. Here you can find the relevant info:
https://www.nomachine.com/AR10K00706
You can check the codec currently in use in the Display settings panel from the session menu.If you are willing to test a debug package, I renew the offer to send it to you. In that case contact us to forum[at]nomachine[dot]com.
Please try to add the following line to the ‘/usr/NX/etc/node.cfg’ file on your server machine and restart the server (‘/usr/NX/bin/nxserver –restart’):
DisplayServerExtraOptions “-nodamage”
That should confirm if the problem is due to an incorrect event reporting from the Damage extension.
Here you can find the relevant info about H.264:
https://www.nomachine.com/AR10K00706Can you please provide some more info:
– Are you connecting to a physical or a virtual display?
– What is the desktop evironment in use (Gnome, KDE, …)?
– A screenshot of the Display settings panel: Open the session menu -> Display -> Change settings.
Among other things, there is indicated the codec in use.The attached sample doesn’t seem to indicate a faulty state, as most CPU cycles are spent on diplay encoding. We are not able to say if upgrading to El Capitan will solve the problem, since we are not able to reproduce this problem with any OS X version.
Regarding your last question, here you can find how to install from command line:
https://www.nomachine.com/AR07K00683Let us know the result of your test. The next step would be sending you a debug package, should you be willing to test it. In that case you can contact us to forum[at]nomachine[dot]com.
Also enabling the H.264 encoding would decrease the CPU usage. You can find more info in these links:
https://www.nomachine.com/AR10K00706
https://www.nomachine.com/AR10K00695The release of this feature has not been scheduled yet, but you can track it here and also decide to be notified:
Hello,
as you noted, on headless machines it should be possible to set any resolution. We are trying to reproduce your issue in our labs. We will be back to you!
Sure, the patch will be included in the next release! Thank you for letting us know.
You can check here to be notified when the Trouble Report will be closed:
Thank you for the info. Actually they exclude that your are experiencing the same problem we had found (and that will be fixed anyway in the next release). In fact from our observations the problem we found has a very limited impact.
Unfortunately we are not able to reproduce any further problem on any of the machines we tested on. Is it possible that the regression you observed is triggered by a system update? Could you maybe try to uninstall the present version and try version 5.0.47 again in order to see if you get the same results?
Another possible explanation is if you had enabled the H.264 codec with the previous version by installing the NoMachine AVC Pack or by compiling the encoding library by hand. Is this a possibility?
Please also take a ‘sample’ of the process that is consuming the CPU. You can find the option to take a sample in the Activity Monitor utility.
Should I assume that you are running the Java application in a custom session in ‘floating window mode’? In that case the rendering is delegated to Xquartz, and so it actually depends on the Xquartz implementation. In virtual desktops instead the rendering is handled internally by NoMachine and so it is platform independent. Work on removing such dependency from Xquartz in floating window sessions is something we have already in our development roadmap.
Hi,
you might be missing to set ‘EnableDisplayServerVideoCodec 1’. Also restarting the server (‘/usr/NX/bin/nxserver –restart’) could be necessary. However you can use the graphical interface to do those settings:
Click on the NoMachine tray icon -> Show the server status -> Server preferences -> Performance tab