Forum Replies Created
FYI, changing the PhysicalDesktopMode value fixed the issue for me.
Thanks for the help!
So the cat reveals:
cat /usr/NX/etc/server.cfg |grep PhysicalDesktopMode
Should I edit the file and change it to a “1” or “2”? The file is currently read only but I could force it… Then do I need to restart NoMachine on my server? If so it’s not obvious how to do that.
Thanks for the help!
Changing this value to false didn’t seem to help:
<option key=”Enable hardware accelerated decoding” value=”true” />
I sent logs already from my other thread, and this delay occurred for all those instances as well.
To answer the questions:
– Free version for both local and remote
– Physical displays (dual monitors connected to remote machine)
– Remote is running Ubuntu 12.04 with Gnome, local is running Windows 7 Ultimate
– Using the NX protocol to connect
I just tried the monitor switching via CTRL+ALT+N and it’s fantastic. Thanks!
My only recommendation is to have the key sequence be CTRL+N or ALT+N. I switch monitors all the time and pressing all three keys is a bit awkward.
Did the logs I sent help?
Ok, I just sent an email with a detailed account of exactly what I did and included the full list of threads as an attachment.
Here’s what I did:
– initiated connection to corporate VPN via Juno Pulse
– Launched 1st instance of NoMachine and opened connection to remote host
– entered password on remote host lock screen
– relocked remote host screen
– pressed “X” to close NoMachine window
– launched 2nd instance of NoMachine and opened connection to remote host
– White window for 10+ minutes which didn’t respond (this is the first time I’ve seen this freeze on initial connection)
– ran process explorer as Admin and copied thread detail for the two running nxplayer processes into nxplayer_process_1.txt and nxplayer_process_2.txt
– manually killed the hung process (process 2)
– launched another instance of NoMachine and opened connection to remote host
– when I got the remote host lock screen I immediately pressed “X” to close the window; the window did close successfully, but now I have two running nxplayer processes
– copied thread info into nxplayer_process_3.txt
I see the same issue and both my client and server are running a recent build from a few days. See my most recent post in the thread I started a couple days ago.
Thanks for the reply!
Yes, using Ctrl+Alt+N to switch windows would be fantastic. When can I get this version? I assume I just need to update NoMachine on my client and can leave the server running the same version as before?
For my second question I don’t believe I’m running the Enterprise Client as I’m just using whatever free/default version for both the client and server. So in my case it’s expected that the process never goes away? That definitely seems wrong because it leaves an instance of the process running for every single run. In other words if I launch NoMachine, connect to remote machine, preform a few tasks (*you’ll see why this part is important in the next section) and then quit there will be one instance of nxplayer.bin*32 that never goes away. Then if I launch NoMachine again, connect to remote machine, perform a few tasks and then quit there will be two instances of nxplayer.bin*32 that never go away!
Another issue I noticed is that if I launch NoMachine, connect to remote machine and then try to close the NoMachine window before I’ve done anything on the remote machine then NoMachine will freeze and I’ll be forced to manually kill the process.
I’m sending a zip of my recent sessions from tonight (which demonstrate the two issues above) to the email you mention above.Thanks!