Forum / NoMachine for Linux / Remote application resolution / display issues
- This topic has 19 replies, 4 voices, and was last updated 4 years, 10 months ago by graywolf.
June 18, 2018 at 15:17 #18730
I’m running into difficulties when trying to run remote Linux Applications (via X11) on NoMachine Windows Desktop client (and web client). The resolution / display for the remote linux application looks terrible (see screenshot attached). The display of the application is unusable and the application is very laggy.
Which is strange is that if I run the same remote Linux application using either X2Go or MobaXterm then the remote application works fine, using the same command to launch the application from the same Windows Desktop (see screenshots attached).
NoMachine Enterprise Server V6 is installed on RHEL 7, and the NoMachine Windows desktop application (latest update) is running on Win 7.
I was wondering if anyone knows why this issue is occurring with NoMachine, but not with other X11 clients?
Attachments:June 18, 2018 at 16:50 #18753fra81Moderator
that is really strange indeed. I would start with trying to disable hardware decoding (check “Disable client side hardware decoding” in Display settings in the session menu). It would be great if you could gather server side logs as described in https://www.nomachine.com/AR10K00697 and client side logs as decribed in https://www.nomachine.com/DT10O00163#2. You can attach them here or send to forum[at]nomachine[dot]com.June 19, 2018 at 07:24 #18756
Attached are the logs from what’s requested in the URLs mentioned.
Note: debugging is turned on for terminal server to the logs will be quite large.
TBH, I’m somewhat lost with what’s going on with this issue, so any input is very much appreciated.
Attachments:June 20, 2018 at 12:07 #18783
@dmoors, there may have been a little confusion about what you need to send us. We received logs from the server component installed on your connecting client 🙁
What we need is:
– server logs from the server you are connecting to (the Enterprise/Terminal Server ?, you mentioned previously)
– client-side logs of the client component
The instructions are those that Fra mentioned previously. Btw, if you have a Subscription of Enterprise Server, might I suggest you open a support ticket from your customer area? Customers are provided with an upload area for logs.June 20, 2018 at 14:45 #18787
I tried to upload the Terminal Server Logs, but this file was 6Mb (due to having debugging switched on at the server level) and the file got rejected because of the 1024kb limit imposed by the forum. The tar file is 6Mb compressed as the NXWebClientLog is 50Mb! Is there an email address I can send this to that will accept a 6Mb file?
I’m unable to raise a ticket for Enterprise Server as we’re trialing NoMachine software as a replacement for X2Go. Unfortunately this isn’t trial isn’t going so well at the moment 🙁
I’ve attached the client-side logs as requested. I uploaded the wrong ones in my previous post. Apologies for that.
Is there someone in sales / support who could do a Webex / conference call with me to discuss these issues? If we can get this working correctly my client may be willing to license the Enterprise Software for a large number of users.
Attachments:June 20, 2018 at 15:14 #18790
Hi, before we go further, can you please disable HW decoding as Fra suggested and tell us if that helps?
“Disable client side hardware decoding” in Display settings in the session menu
We tested on the fly with SpyderPython and we weren’t able to reproduce the behaviour you are seeing. I can send you details on where to submit logs via email if disabling client-side HW decoding has no effect.June 21, 2018 at 10:01 #18791
I’ve previously suggested I’ve already disabled HW decoding on the client side (see screenshot attached).
I’ve also tried NoMachine with the a different application, Stata, Again these rendering issues keep occurring. On the same client (Win 7 64bit) using [removed] or [removed] to open the same remote Linux application, using the same start command I don’t experience the rendering issues?
This all seems very odd?
I’ve attached the screenshots for testing the ‘Stata’ application.
Any help would be much appreciated as I’ve got to report back to my client shortly on my trial of NoMachine, and unfortunately it’s not currently a viable option with this rendering issue, which is a real shame as I was hoping this would be the Enterprise Solution they’ve been looking for 🙁
Attachments:June 21, 2018 at 11:37 #18802
Another thing I need to mention is that every morning I get an Ooops message when starting a NM session, advising of a ‘Permission Denied’ to the nxserver log fine. (See screenshot attached).
I then have to restart the Terminal Server so I can start a session again.
Not sure if this is relevant or not?
Attachments:June 21, 2018 at 12:09 #18811
I have sent you an email with details on how to submit the logs.June 25, 2018 at 10:04 #18819
We got the logs and took a look. No indication of what could be happening.
They are from Enterprise Terminal Server which, I assume, you are using to connect to a number of Terminal Server Nodes. The problem is therefore on the Terminal Server Node and the logs must be enabled and extracted from the affected node.
Please clarify your set-up by confirming:
Enterprise Terminal Server and OS and version?
Terminal Server Node and its OS and version?
So far we have been unable to reproduce the issue affecting your session.June 26, 2018 at 14:02 #18825
The Enterprise Terminal Server & Server Node are installed on the same machine (a VM). I’m guessing this is an OK set-up for NM?
Below are the commands I ran and the results:
sudo /etc/NX/nxnode –version
NoMachine Enterprise Terminal Server Evaluation Node – Version 6.1.6
sudo /etc/NX/nxserver –version
NoMachine Enterprise Terminal Server Evaluation – Version 6.1.6
Red Hat Enterprise Linux Server release 7.3 (Maipo)
Would it be worth trying to re-install the software again and see if that improves things? I’d like to get this working a I think there could be potential licence sales if we can get this working in a robust manner.
DavidJune 26, 2018 at 15:50 #18827
on VMs on the same machine is fine, but ETS must be on one VM and TSN on a separate VM (just wanted to clarify that in case other readers are wondering). Can you tell me what virtualization software you’re using for the VMs?
Can you try connecting from a completely different client machine? Try from a different Windows computer and, if possible, a different OS. Is the problem still there?July 4, 2018 at 14:37 #18880
Hi David, did you manage to try from a different Windows client or different OS?July 5, 2018 at 10:14 #18914
It’s taken me a couple of week to procure a second VM with RHEL 7 on, to be able to set up the Terminal Server Node, as I’d assumed you could you the same VM instance for both the Enterprise Terminal Server and a Terminal Server Node.
I’ve installed the NoMachine software and configured them to talk to each other. I just need to wait for some admin changes to be done on RHEL (I’m not allowed to make these changes myself), then I’ll be able to test it.
As this is a PoC for NoMachine, we don’t have other users who can test NoMachine with different OS, and we’re only provided a remote Windows 7 desktop as the client has strict security to access their data/servers.
I’m hoping to have the admin changes will be done within the next 24 hours and I can re-test the Linux application in the new set-up.
Thanks for your help and keeping an eye on this track, and when I have any new information I’ll let you know.
DavidJuly 10, 2018 at 14:12 #18969
Following on from my previous message, I’ve set up a Terminal Server Node on a different VM and this is now communicating with the ETS.
When I try and use the NoMachine desktop client I still get the green hue around the Linux application (Stata14 in this case) I’m trying to run. This is despite un-installing and re-installing the NoMachine desktop application.
However if I now use the NM Webplayer the green hue has now gone and the application looks OK. Performance via the Web player still seems to be a bit sluggish, but this is a major improvement on the desktop application. No idea why this is the case, I would have thought this would be the other way around?
I’ve attached some screenshots for reference purposes.
This topic was marked as closed, you can't post.