VNC client copy/paste stops working after a while about turbovnc HOT 20 CLOSED

Sorry, guys, but I simply can't reproduce this. I've tried hard. There is some critical piece of information still missing-- obviously something different about your machine vs. mine that is causing the problem, but I don't know what it could be. Absent any further information, there is nothing I can do about this, because I cannot fix what I cannot reproduce. Any chance that it's a Java bug? Are you using the latest JRE? Does the issue also occur with the native viewer? The more information you give me, the more likely it is I'll be able to solve the problem. A specific reproduction procedure or a video showing the problem would maximize your chances of getting this fixed.

from turbovnc.

Are you running TurboVNC 2.0.1 on the server as well, or TurboVNC 2.0?

from turbovnc.

Also, I assume you're running the native Windows TurboVNC Viewer, not the Java viewer?

from turbovnc.

I'm running the Java viewer, and whatever build you had me install on the server before - I think it was a 2.0 RC, not sure how to find that out

from turbovnc.

rpm -q turbovnc

from turbovnc.

Sorry, you're using Ubuntu. dpkg --list | grep turbovnc

from turbovnc.

2.0.1-20151105

from turbovnc.

Others have reported this issue as well, and apparently it also exists in TigerVNC. @bphinz reported that he had some luck with using the -poll setting for vncconfig to work around the issue, so I have it as an action item to add that feature to tvncconfig. I don't think anyone really understands the underlying cause of this issue, though. I've seen it happen on my machine as well, and usually it is accompanied by some clipboard-related error message on the viewer's command line-- basically Win32 stops accepting the clipboard updates. I haven't had time to diagnose it further.

from turbovnc.

The latest pre-release build (http://www.turbovnc.org/DeveloperInfo/PreReleases) now includes a -poll option for tvncconfig. My best advice is to edit /opt/TurboVNC/bin/vncserver, change "tvncconfig" to "tvncconfig -poll 1000", restart the server, and see if by some miracle that works around the issue.

The TigerVNC developers who reported this same problem (assuming it is in fact the same problem) said that running their version of vncconfig with -poll 1000 worked around it. I've only seen the problem a couple of times, and I'm not sure how to reliably reproduce it. Any further information you can gather whenever the failure occurs-- errors printed on the viewer's command line, etc.-- would be helpful, as would any information that might shed light on why it's occurring in the first place (any other remote display programs running that might be interfering with it, what you were doing at the time, etc.)

Leaving the issue open until we develop a better understanding of it.

from turbovnc.

Also, double-check that there aren't multiple instances of tvncconfig or vncconfig running in the same session. Sometimes people start vncconfig in their .bashrc or something like that, which can lead to problems if it's already running.

from turbovnc.

That was not a contributing factor

from turbovnc.

Windows client: TurboVNC 64bit 2.1.1
Servers: tigervnc-standalone-server_1.7.0+dfsg-6 (on Debian)

Clipboard sharing works from the servers to the client, but the other way around (client -> server) only works sporadically (have a feeling it only works once and then stops working).

Using the RealVNC 4.1.3 client, sharing works both ways.

from turbovnc.

from turbovnc.

@mslinn since you never described precisely how you were using the clipboard feature and precisely how it was behaving differently than expected, it was impossible for me to reproduce this issue. However, I checked in another clipboard fix that affected Windows. This fixed a bug that was preventing the clipboard from being transferred if text was selected on the server, the viewer window was not the foreground window, and a user pressed the middle mouse button in the window to both focus it and paste the clipboard.

Since Java doesn't provide a "clipboard changed" event, we are forced to check the clipboard when the window gains focus, and this new commit causes the viewer to also check the clipboard when the mouse is clicked in the window.

If that doesn't fix it for you, then you're going to have to provide me with more information, including exact reproduction steps.

from turbovnc.

I have this problem too -- I opened a new issue #613 but maybe that is the same as this issue

from turbovnc.

@kingaj12 Well, my problem is still the same: I can't fix what I can't reproduce. I have never been able to reproduce this.

from turbovnc.

Yeah. I sympathize. I have a feeling that is related to the X server configuration.

from turbovnc.

Wondering if this is still reproducible with TurboVNC Server 2.0 beta1. The new version syncs the clipboard directly, within the Xvnc process, instead of using the tvncconfig helper application.

from turbovnc.

I kept running into this as well, and a coworker figured out it had to do with the KDE environment. Specifically, klipper. Either killing that process or disabling "prevent empty clipboard" fixed my issues.

from turbovnc.

The OP was using Xubuntu, which doesn't have KDE, so there are probably multiple related issues here. I'm reasonably certain that the original issue that inspired this post was fixed when we eliminated tvncconfig in TurboVNC 2.2.

from turbovnc.