aenea icon indicating copy to clipboard operation
aenea copied to clipboard

Text is mangled when sent to a windows VM via xdotool

Open djr7C4 opened this issue 11 years ago • 3 comments

This may be related to #28 but I wanted to make this a separate issue since I did not experience any problems prior to commit 775af7c09d3fc179a2ab0d7bc159f3bd9858102f.

Basically some characters appear to get dropped so that only a subset go through. It's not always a problem but seems to happen intermittently.

djr7C4 avatar Sep 21 '14 18:09 djr7C4

I looked through that commit again verified that it did not touch any of the xdotool logic. I have a hunch that a race condition may have been triggered by the increased server response time from enabling logging. Are you getting any of the "Socket error connecting to aenea server. To avoid slowing dictation,..." error messages in the natlink console? I found that errors such as this decreased significantly after increasing socket_timeout in aenea.json.

mzizzi avatar Sep 21 '14 21:09 mzizzi

Yes, I get them sometimes. Also, I'm not blaming that particular commit. I'm just saying that something at that point or later caused the bug for me. Sorry if that was unclear! I will try your suggestion. Thanks!

On September 21, 2014 5:06:58 PM EDT, mzizzi [email protected] wrote:

I looked through that commit again verified that it did not touch any of the xdotool logic. I have a hunch that a race condition may have been triggered by the increased server response time from enabling logging. Are you getting any of the "Socket error connecting to aenea server. To avoid slowing dictation,..." error messages in the natlink console? I found that errors such as this decreased significantly after increasing socket_timeout in aenea.json.


Reply to this email directly or view it on GitHub: https://github.com/dictation-toolbox/aenea/issues/70#issuecomment-56312763

djr7C4 avatar Sep 21 '14 21:09 djr7C4

The timeout is a direct tradeoff between responsiveness in local mode when no server is up and frequency of disconnects causing commands to be dropped. If everyone's increasing the timeout we should consider doing so in the defaults -- I personally don't think we should optimize for working well when the server is down; as long as it remains at all usable a user can simple disable proxy to eliminate any lag. But dropping commands due to too low timeout is counterintuitive and frustrating.

calmofthestorm avatar Sep 22 '14 00:09 calmofthestorm