Forum Replies Created
-
Posts
-
Hi, sorry for the late answer. How many displays are connected to the client and to the server machines? Are you connecting to the physical desktop of a Linux server? What is your display mode, scaling, viewport or resize?
As for your second question, the client doesn’t normally close the window with the list of connections while other client windows are running, so I’m not sure about what you’re seeing on Windows.
The NoMachine Android application that you’re running on ChromeOS doesn’t support starting concurrent connections, therefore you can make use of the Linux VM and install the NoMachine client for Linux.
The Linux VM is disabled by default on Chromebooks, but it is fairly easy to enable it from Settings > Advanced > Developers > Linux development environment. Look for a guide if you get stuck somewhere.
Once the Linux VM is ready, open a Terminal and install a NoMachine Enterprise Client for Linux.We’ve confirmed that some Wacom driver versions just hang waiting for something when the device input gets enabled on window activation. We didn’t find a code workaround for this unexpected behaviour, so the only possible solution so far consisted in stopping the ISD service, but of course this is not advisable if the tablet/pen must be used.
Can you all please check if there is an updated Wacom driver?https://www.wacom.com/en-us/support/product-support/drivers#latest
Hi, thanks for the report. I’ve some questions to help the investigation.
- What is your Mac model? If it’s a Macbook, do you use the built-in trackpad or an external mouse/trackpad?
- Do you’ve multiple screens on client and/or on server?
- What is the server side operating system?
- When you say “one correct mouse click”, do you mean exactly and only one click?
- What is the NoMachine display mode you use: viewport, scaling, or remote resize?
- Can you verify if the mouse works again correctly by just opening and closing the NoMachine player menu?
- Can you verify if the mouse works again correctly by doing a small NoMachine player window resize?
- Can you estimate more or less how big the mouse offset is, and if it is always the same? Does the offset increase as you move to the bottom-right corner of the NoMachine player window?
Thank you for your help.
I’d like to send you a library that adds some checks in the routines handling the system clipboard, but I’d need to know if you use the 32 or 64 bits version of the software (x86 or x64). Please send an e-mail to forum[at]nomachine[dot]com and use the title of this post as subject, we’ll answer by sending a link to download the library.
Hi. We’ve no open issues about copy&paste causing application freezes, so I’m going to ask you some questions to better outline the problem and confirm it.
When you have this application freeze issue:
– Do you have more than one Player running, connected to multiple desktops?
– Is the main Player window, showing the list of machines, freezing as well?
– Open Task Manager and kill one NoMachine Player process at a time. Do the other Player’s start working correctly?
– When you can manage to start a new NoMachine Player, if you shutdown temporarily the NoMachine server do you see other processes running in Task Manager? How are they called? If you kill them, can you start correctly a new NoMachine Player?Also, please send the file %ALLUSERSPROFILE%\NoMachine\var\log\nxtrace.log, if it does exist, to forum[at]nomachine[dot]com.
Thanks.Happy to know it works!
If you want to automatically run the application, you can look for an automation app in the store and configure a macro to open an NXS file with NoMachine. You can select the trigger (device boot, screen unlock, wifi state change, button presses, etc) and the action to execute (in our case “open file”).
I’ve tried a couple of simple apps but I didn’t manage to start the application correctly after the device boots up. However I tried to run it when the screen unlocks, and it worked beautifully. Nice idea, thanks for sharing it!You can use the intent, try this:
adb shell am start -a android.intent.action.VIEW -d file:///storage/emulated/0/Android/data/com.nomachine.nxplayer/files/NoMachine/Connection\\ name.nxs -t application/octet-streamChange the file “Connection name.nxs” in the example to the name you need, and remember to double escape spaces. You could also need to change the path of the NXS file, usually they are saved in the scoped storage, but you could have also a /sdcard/NoMachine directory.
The first time you’ll do it, the system will show you a list of applications compatible with that mime type. Select NoMachine and toggle “Remember my choice”.
When the application starts check the “Don’t show this message again” switch in the welcome panels, so the next time the connection will start immediately.Hi. In your old post you said “the remote window and the client application window are both frozen”. Do you mean that both the window showing the remote desktop, and the one listing the existing connections, are freezing?
When typing in a Raspberry Pi terminal window with the Apple Magic Keyboard, we have the following problems
Can you please tell the distribution and keyboard layout you’re using on Raspberry, and the keyboard language set on iPad? We’re preparing a release including the fix for this problem, but we’d like to be sure it addresses also the issues you’re experiencing.
The NXS connection files store all your preferences and they are saved by default in the Documents/NoMachine directory. I noticed my post was corrupted for some reasons and the last line was not visible. Read it again to see the option to change.
As for the command line option, you can use it by starting the following command in a terminal:
/usr/NX/bin/nxplayer --exit-always
Since you’re configuring a kiosk you can edit the script/usr/NX/bin/nxplayerand add the option--exit-alwaysto the last line:
exec "$NX_SYSTEM/bin/nxplayer.bin" --exit-always "$@"The client can be configured to ignore errors on disconnection, and that together with disabling the automatic reconnection should do what you want.
You can test these ways:
1. Run the player with the
--exit-alwayscommand line option
2. Edit the NXS connection file, and set the value “always” to the following key:
<option key="Close the client application when a single session terminates" value="always" />Hi. Can you confirm the drop on the window correctly transfers the file to the server? If it is so, and the problem is only occurring when you drag a file out to download it, please try to use all four sides of the client window, and try also to slowly cross the window border. We’re running some tests in our labs, results of your tests would be helpful too. Thanks.
Hi. The drag operation showing the remote cursor is a feature that, on the mobile application, has a slightly different behaviour compared to desktop application. While I perfectly understand your proposal and I agree, one of our policies forces us to have the same solution on all platforms, when deciding how to deal with problems or features. In this particular case we could hide the local cursor on Android, but not on iOS… However as you said the Android cursor is not very nice, so we’re still discussing all possible pros and cons of every solution.
I know this is not the solution you’re looking for, but you could disable the server side cursor when doing the drag operation by editing the node.cfg file on the server and by setting the following key:
DisplayServerExtraOptions “-nocursorlock”
Thank you for your feedback!
We identified the issue and rolled out a new version for an internal testing, so far everything is working as expected. We’re implementing other changes too, so I don’t expect a new version to be published before next week.
@hpb can you confirm the ‘space’ works correctly with other 3rd party apps, please? Compared to other keys, the ‘space’ is received as-is and there is nothing special to do to forward it.
@NebulaBC the problem is a bit more complex, caused by an internal condition clearing out a bit in a mask, and bypassing the definition of the key commands needed by the responder object. I’m sorry we didn’t notice it during our tests.There is a workaround you could try. The bug is not triggered if you avoid to activate input fields before the client connects to the remote desktop, so store username and password in the connection and don’t tap any input fields until you see the desktop. Let me know if this helps (on one of our devices the workaround didn’t… work around! 🙂 We’re still analyzing the reason).