Forum Replies Created
-
Posts
-
I’m looking forward to testing a new version. My users are as well! If you want to look at another program that handled this well, WinSCP handles this cleanly, so you can use that as a baseline.
Per this feature request, H.264 is not supported in X11 mode, so this shouldn’t be the issue, correct?
https://www.nomachine.com/FR11O03550.
If this FR has simply not been updated, and H.264 is in fact available in X11 mode, you may be correct. In testing, I was not able to get H.264 enabled on my system (by disabling X11), but I also never saw the problem. It is possible it is kicking in for the people having an issue.
I am also unclear on the h.264–I do not have a license for it, I only have the standard 4 seat workstation license. Is H.264 enabled by default now even without the license?
More information: It appears that the problem can be resolved by having the options “fit to window” and not having the desktop in full screen mode. I believe the issue is fundamentally something to do with the display drivers the systems are using, and how VP8 is interacting with them. By resizing, my theory is that it is adjusting the render flow to avoid the issue. I will update once I validate what display drivers the users with the issue are using, but this provides a reasonable workaround.
Update: While this appears related to VP8, the issue is more subtle. Another user that previously did not have an issue is now having an issue as well, without having updated any software on their machine. It was working, they left a session, opened a new one, and now is having the same issue. Attached is a screenshot showing one app rendering fine, but Chromium is not.
Attachments:
To be honest, I’m surprised every time a complex tool allows authentication this way. It is however, technically four factor authentication. 1) ssh key itself 2) the passcode to decrypt the ssh key, 3) google authenticator 4) the unix password. If there is any assistance needed to set this up, please let me know, as the authentication setup is quite confusing, in particular when puttyagent kicks in and bypasses the ssh key password for the user.
Update: The issue only appears to happen when using floating windows on Mac. If a full desktop is used, then the problem goes away. This is also in the context of using SSH as the protocol, not the NX protocol, so this may also be related. As the desktop works, and we have few mac users, this effectively resolves our issue.
I haven’t opened a ticket yet, I was looking for any obvious issues first. I worked through the docker stuff, but it doesn’t exactly apply to our situation, so it isn’t quite as documented. That said, since it works for Windows, I wouldn’t expect that it would break on a Mac. The most notable part of the logs is this:
Info: The session was closed before reaching an usable state.Info: This can be due to the remote display refusing access to the client.This to me says that there is something going on with the client side that may be impacting the display of the application. I don’t have a Mac to test this with, this is one of the users having the issue, but was hoping someone else had encountered this and resolved it. Google didn’t help with this one. 🙁
