Bug 1357890

Summary:	virt-viewer on Widows 10 responds with HIGH delay
Product:	[Community] Virtualization Tools	Reporter:	Alex <alexander.becht>
Component:	virt-viewer	Assignee:	Daniel Berrangé <berrange>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	ngtech1ltd, pgrunt, rbalakri, xen-maint
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Windows
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-07-21 05:54:58 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alex 2016-07-19 13:43:16 UTC

Description of problem:

Virt-viewer Connection from Windows 10 Host over spice responds verry slow. 

It seems like the Viewer gets the "screen update" delayed. When watching the input in parallel on a Linux Host you can see the input (and output) immediately.
But on the Windows 10 Host it takes up to 60s to see the input and output.

Same Machine with Windows 7 worked fine till upgrading to Windows 10. Have the same issue on at least three machines.


Version-Release number of selected component (if applicable):
4.0-256

Comment 1 Eliezer Croitoru 2016-07-20 02:07:51 UTC

I am experiencing the same issue on 4.0.256.
On the same machine a 3.1.256 works fine.

Comment 2 Alex 2016-07-20 07:39:31 UTC

(In reply to Eliezer Croitoru from comment #1)
> I am experiencing the same issue on 4.0.256.
> On the same machine a 3.1.256 works fine.

Can confirm, 3.1.256 is working fine
Thank you!

Comment 3 Pavel Grunt 2016-07-21 05:54:58 UTC


*** This bug has been marked as a duplicate of bug 1353963 ***

Comment 4 Alex 2016-07-21 10:02:51 UTC

Sorry for bothering you, but I can't believe. 
-> The solution is downgrade! Closed?

No fix for actual or future releases?

Comment 5 Daniel Berrangé 2016-07-21 10:06:27 UTC

No one said we won't fix it - this bug is simply a duplicate of an already filed bug. A fix is still being investigated

*** This bug has been marked as a duplicate of bug 1352216 ***

Comment 6 Pavel Grunt 2016-07-21 10:10:47 UTC

(In reply to Alex from comment #4)
> Sorry for bothering you, but I can't believe. 
> -> The solution is downgrade! Closed?

imo downgrade is just a workaround

> 
> No fix for actual or future releases?

There will be fix, i just closed it as a duplicate of the same bug, the issue appeared with gtk3.20, it works fine with gtk 3.18 or lower. we need to find out why...

Comment 7 Alex 2016-07-25 10:07:56 UTC

Thanks for the update.
I didn't see that the closed duplicate was a duplicate.