fra81

[fra81]

You don’t see nxcodec.bin when using vp8 because the encoding, in that case, is done by the nxnode process. Generally speaking, encoding, if done in software, is a heavy operation, and I don’t see anything abnormal in your description.

[fra81]

Do you think the cpu’s server cannot handle encoding h264 and could be the reason of high cpu on on a mac client ?

This is possible if you say that the resolution is very high and given that the CPU is not very powerful. But also note that such CPU usage just means that a bit more than 2 CPU cores are used of the 8 at disposal. To limit CPU usage further, besides reducing the resolution, you can try to lower the frame rate in the Display settings panel.

[fra81]

Now hardware decoding is working, although my cpu is 135%, a little worse than with software decoding.

Normally hardware decoding offloads the CPU, but this could not happen with particular combinations of hardware and drivers. Unfortunately this is not something that our software can have control over.

[fra81]

Thanks for info!

Finally we reproduced something similar between two Macs in our labs. I’ll let you know the results of investigations.

About color spaces you are right, but NoMachine dealt already with this problem (see https://www.nomachine.com/FR03M02907).

[fra81]

Thanks for info. Indeed you would have to export those devices explicitly in order to trigger that problem.

Would you mind to try one more thing? In https://www.nomachine.com/AR03P00973 you can find a couple of methods to turn off the local X server on Ubuntu. In this case NoMachine will then use its own virtual frame buffer and we would be able to exclude or narrow down this issue to drivers on server side. And if possible, it would be nice to check the CPU usage of the server while reproducing the issue.

[fra81]

Hi,

this is very strange. Logs look clean and we can’t reproduce anything similar on various Windows Servers in our labs. Though another user experienced a similar problem: could you check if the workaround here makes any difference for you?

[fra81]

A small clarification to what Britgirl wrote – obviously we handle multi-touch events such as the ‘traditional’ two-finger swipe or pinch-to-zoom in our iOS and Android apps, and we will add support for them on Windows tablets soon.

[fra81]

This is a really strange issue. Could this Trouble Report possibly apply to your case?

https://www.nomachine.com/TR06P08609

[fra81]

Hi,

could this Trouble Report apply to your case (i.e., are you sharing a USB device between client and server by NoMachine services)?

https://www.nomachine.com/TR06P08609

And yes, logs could be useful. Please find instructions for the server side in https://www.nomachine.com/AR10K00697 and for the client in https://www.nomachine.com/DT10O00163#2. You can send files to forum[at]nomachine[dot]com.

[fra81]

Logs are pretty clean. Are you sure it’s not something with your network setup. Are you using a VPN service between the client and the server maybe? Could that be the culprit?

I would also try to disable UDP (Edit connection -> Advanced -> uncheck ‘Use UDP communication for multimedia data’).

Also, please check CPU usage during the “freeze”.

[fra81]

Hi Babok,

can you tell us more about the hardware you have on the server and about the desktop environment (GNOME, KDE…) in use? Besides lowering the screen resolution, you could try to use a lightweight desktop environment, if that’s not the case already (see https://www.nomachine.com/AR07K00676).

Sometimes had to relaunch the server NoMachine because I couldn’t connect to. I read this bug has been reported before, any news on macOS problem occurring on monitors supporting wide color gamut?

Can you tell us more about this problem? If you are referring to https://www.nomachine.com/TR10P08920, that should be fixed in version 6.8.

[fra81]

Hi Ross,

please gather server and client side logs, as explained in https://www.nomachine.com/AR10K00697 and https://www.nomachine.com/DT10O00163#2.3. You can send them to forum[at]nomachine[dot]com.

Also session statistics could be useful:
– open the Connection panel in the NoMachine Menu Panel (see https://www.nomachine.com/DT07M00087#9);
– click on ‘Take the statistics’ once to reset counters and discard the result;
– reproduce the issue (for example type in the terminal and wait for the result);
– click on ‘Take the statistics’ one more time and send us the resulting file.

[fra81]

Hi,

please collect server-side logs from the Windows 8.1 computer and show us. You can send them to forum[at]nomachine[dot]com.

Are you connecting to the login screen of your Windows 8.1 computer?

[fra81]

Hi davide445,

it’s hard to provide any exact figure without a specific investigation. I can confirm that latency generally is in the order of few milliseconds, but as you can imagine it can depend on many factors, like the hardware, the availability of a hardware decoder, the frame resolution, etc. I think the best way is trying it out…

[fra81]

Hi,

I wasn’t able to reproduce your problem. Could you send a screenshot of the scaling options from the display settings of both your client and server Macs?

[Author]

Posts