Tor

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

[Tor]

Hi Adam, sorry for the late answer. We’ll include the fix in our next maintenance, which should be quite close (within a couple of weeks if all goes as planned).

[Tor]

Hi everyone, quick update. Thanks to the tests you all shared we can exclude a bunch of reasons causing the issue, so we’re analysing the stream of system events generated in the cases you described (screen sleep, OS suspend, etc). We suspect a problem with window activation that could put the application in a state triggering exactly the behaviour you described. I’ll keep you updated.

[Tor]

@rkeen thank you for the additional info. I’ve a question: when you originally said you log in “all keyboard”, do you mean that also the NoMachine window is focused through keyboard (Command + Tab) and then you start using the trackpad, or do you mean you start using the trackpad immediately after logging in the macbook to click-activate the NoMachine window?

@gmhliu thanks, I appreciate your answers. Did you notice if the display mode (viewport, scaling, remote resize) makes any difference?

To anyone wishing to try this: open the Input menu and check the box “Always show remote cursor pointer”. When the issue occurs, the remote cursor stands still in a position, or does it lag behind the local cursor?

[Tor]

I can consistently repro this issue when:

We’d really like to have a way to reproduce the issue, even sporadically, but so far we were unable to do it. I greatly appreciate your report, could I ask you some questions about your steps description?

1. The main NoMachine window is fullscreen as well? On what monitor is it positioned?
2. What method do you use to disconnect the NoMachine session? Disconnect menu, Command+W, etc.
3. For how long do you keep the lid closed before opening it? Minutes, hours or days? This question could seem unrelated, but the closed lid triggers different macOS states depending on the time it stays closed.
4. Do you plug the monitor before or after opening the lid?
5. Assuming the main NoMachine window goes in the external monitor, did you ever notice cursor problems when interacting with the GUI?
Additionally:
6. What is the type of session you run remotely, a virtual desktop (on Workstation/Terminal server products) or a physical desktop sharing?
7. When the issue occurs, how do you work around it to restore the cursor functionality?

Of course we’ve tried to test all the combinations I listed in my questions, to no avail. I’m sorry for all the questions, I’d really like to find a way to reproduce this because the issue is somehow related to how the window receive events from the system, and a simple static analysis didn’t help so far.
Thank you very much.

[Tor]

Hi. I can think to a couple of reasons:

• CFG file is edited while a player is running, so on saving current process overwrites your manual editing

This is easy to check, and honestly I think you verified it already, but it’s better to be sure.

• CFG file gets corrupted and the player creates a new one with default values

This would require more investigations, but we can start by doing two things: check if you see segmentation faults reported for nxplayer process in your system log, and try to edit more key values in the CFG so you can verify if they all change when the “overwrite” occurs (assuming you excluded the first possible issue I listed above). Also, check if in the $HOME/.nx/config folder you see files with extension .BCK or .RECOVER

[Author]

Posts