Tor

[Tor]

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!

[Tor]

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-stream

Change 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.

[Tor]

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?

[Tor]

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.

[Tor]

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/nxplayer and add the option --exit-always to the last line:
exec "$NX_SYSTEM/bin/nxplayer.bin" --exit-always "$@"

[Tor]

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-always command 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" />

[Tor]

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.

[Tor]

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!

[Tor]

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).

[Tor]

Perfectly clear, thanks. We’re doing some checks in our labs, I’ll update this thread soon.

[Tor]

Hi! What is your iOS device model? Do you use the virtual keyboard, or an hardware keyboard connected to the device through bluetooth?

[Tor]

Thank you for the report, in the next release we’ll improve the tray icon selection on Mint 21.
You can work around the issue by executing the following commands in a Terminal window:

cd /usr/NX/share/images
for i in tray-dark-*; do sudo cp "$i" "$i.backup"; done
for i in tray-light-*; do sudo cp "$i" "${i//light/dark}"; done

If you want to restore the backed up icons, run this:

for i in tray-dark-*.backup; do sudo mv "$i" "${i//.backup/}"; done

[Tor]

Hi. Can you update your client to the new 8.2 version and try again? We’ve solved some general issues occurring on Ventura, it would be good to know if those fixes help with your issue.

[Tor]

Hi Adam. It looks like your client can’t access the fonts database on your Mac. Can you determine what happened when the client stopped working correctly? Did you update NoMachine, upgrade the OS, installed some 3rd party apps that could affect Mac standard behaviors?

You could check if the font chooser lets you select anything. Click the Settings button under NoMachine logo, select the second icon in the left column (Player), and the second icon in the right column (Appearance). Once there, click the first button you see on the right column and try to select a different font, or let me know if the chooser is empty as well.

[Tor]

Hi. Check if the following folder exist:

mtp:/Pixel 4a (5G)/Internal shared storage/NoMachine

This is normally the directory where we store the connections, the one you see in the file browser is wrong, due to a problem with mount points that will be fixed in a version we’re about to release.

If you find the connection files, you could work around the mount point issue by editing the NXS file and by setting the key path in the following value:

<option key=”Private key for NX authentication” value=”<path>” />

[Author]

Posts