Tor

[Tor]

Hi Martona. Your large attachment was probably refused because of its size. Could you send it to forum[at]nomachine[dot]com, please?

Edit 10/10/24 – we didn’t receive the missing image but we can maybe assume that the Mac machine possibly has a Retina display. In the future we will add support for the capture the screen of the server at native pixel resolution on High-DPI displays.

[Tor]

Hey Dreas, I’m happy that somehow you got it working, I’ll make sure that it becomes more easy and consistent.
Could I ask you to write the error you got when double clicking the .nx folder? Somehow your message was not added to your post, and I’d like to know details because it seems there are other things to investigate on One UI.
Thank you!

[Tor]

We’ve investigated the problem, it is caused by a wrong disk permissions check for file transfer that causes a bunch of wrong behaviours. One of them causes the issue you noticed: the app doesn’t correctly check file system it has access to, and limits the folders that can be navigated with the file browser. A way to work around that is deleting the file /Android/data/com.nomachine.nxplayer/files/.nx/config/player.cfg to force the app to initialize again some settings after enabling the All files access. The new default folder will be Downloads, which is for sure better than using the app private storage, but for the same reasons I said above it won’t allow to navigate to another folder.

[Tor]

Did you try to disable the scale to window mode after changing the DPI scaling configuration on Windows? Is the quality better?

[Tor]

Hi martona. You can tell Windows to ignore the DPI scaling for a specific application by changing a compatibility flag: right click the application shortcut or binary, select Properties, Compatibility tab, click Change high DPI settings, check the box “Override high DPI scaling behavior” and select “Application” in the combo (it is the default).

[Tor]

Hi. We could reproduce the same behaviour (with some differences between multiple Android versions), but we’re still unsure about what triggers the issue. In all cases, in order to work around it we had to enable the disk access (you was right in your analysis). You can do that on One UI by opening Settings, Apps, top right dots menu, Special access, All files access, turn on NoMachine. We also noticed that the file destination panel has a wrong layout, it is too thin. Whatever happened, did break the app pretty well! I’m sorry for that, we’ll publish a fix in our next update. Disk permissions should be required only when you want to upload a file from any allowed system folder, not necessarily when you download a file (it would be saved in the app’s private storage).

[Tor]

Hi warbaker.
We confirmed that the original issue of this thread is a problem with our window not receiving events sometimes, for unpredictable reasons and without a clear events pattern to work around it. We’re still digging Apple events to find a fix.
However your case seems different, an offset can be caused by a problem in scaling the pointer coordinate. You said you run in fullscreen mode, what is the view mode: viewport (scrollbars or black area around the desktop), resize remote display or scaling?

[Tor]

Hi. From your description it seems that the desktop environment is restoring the previous resolution. Can you check if you’ve a file named monitors.xml in your home directory (usually in ~/.config/), rename it, logout from the destkop session, login and try again to change the resolution in the NoMachine iOS app?

[Tor]

A behaviour like that occurs when the option name is wrong or when it’s not passed at all to the process. Be sure that you’re writing the --session option correctly, and if you’re using scripts or programmatically starting the process, verify that arguments are configured correctly.

[Tor]

Hi. Do I understand correctly that your key does not use a passphrase? Could you share the options you use to generate the key, please?

[Tor]

We didn’t find a way to reproduce your problem despite our efforts. Would you like to sideload a debug APK and retrieve some logs from your device? If you agree, contact us via e-mail forum[at]nomachine[dot]com and use the title of this post as subject.

[Tor]

Hi Phil. We’ve tested both Samsung models running on One UI 6.0 (Android 14) and could not find any issues.
Can you type normally in the app interface, for example to set the user name logging in?
When your keys are being shown slowly on the remote desktop, did you notice if also the desktop screen updates in the app are slow (you could run a video on the desktop while typing)? If you’ve physical access to the server, did you notice if the letter is slow to appear on screen also on the physical display (not only through the app)?
Is there something you can say about the virtual keyboard? Do you use a particular configuration? Do you have bluetooth or USB devices attached to the phone/tablet?
Thanks.

[Tor]

Hi. The problem started when you updated from Ubuntu 20.04 to 22.04, or you tried that as an attempt to solve the issue? What are you device models and kernel versions?

[Tor]

We’ve similar configurations with no issues. Some questions:

1. Do you see in the client Display menu the button to select the current display on the remote desktop?
2. What display driver are you using?
3. On the client get the output of the command xdpyinfo | grep -A1 "screen\|XINERAMA"

Thanks.

[Tor]

Hi. Please send the output of the command xrandr -q executed on client and server machines, it’ll be useful to know your screens configuration and layout.

[Author]

Posts