Description of problem: When working with isochronous devices, a situations arise when: * remote-viewer windows is not responsive * r-v RAM usage keeps growing from ~110M to more than one GB * video from webcam keeps being received by the VM but gains tens-of-seconds latency After some time, the situation settles. Some info about the environment/setup: * client-guest is site network with ~80-100 Mbps real speed * RHEL client on the same physical HW/network works correctly * tests with video call (through skype) showed that video stream from webcam keeps being received (although with big delay) in spite of non-responsive UI Version-Release number of selected component (if applicable): usbdk v0.04-1 + associated virt-viewer patches (64b) Windows 7 64b How reproducible: frequent but no clear reproducer Steps to Reproduce: A) 0) launch task manager/(h)top 1) go to app that will pick up webcam automatically, e.g: * linux: cheese * windows: skype -> options -> video settings 2) plug in the webcam 3) watch remote-viewer process memory consumption while waiting till it resumes B) (not sure about reliability) 0) configure skype in the guest to use webcam mic and then headset mic 1) disconnect from VM, unplug the devices 2) connect to a VM, plug webcam, make skype call 3) during the call, plug headset Actual results: As in description, for some time, remote-viewer process has: * irresponsive UI * steadily growing memory usage Expected results: remote-viewer works from start Additional info: process dump (64b) is available @: http://10.34.73.3/nfs/iso/djasa/dumps/remote-viewer_webcam_temp-mem-surge_unresponsive.dmp \\10.34.73.3\\iso\djasa\dumps\remote-viewer_webcam_temp-mem-surge_unresponsive.dmp
80-100 Mbps (Mega-bit per second) is not enough for camera redirection. Depending on resolution and frame rate camera may consume much more (one of cameras we have consumes around 200 Mbps). Do you see the same problem with faster network (1Gbps)? In case the problem is not observed on faster connections it looks like there is a bufferization strategy glitch on application layer (libusbredir/spice-gtk) that needs to be investigated.
this is an automated message. oVirt 3.6.0 RC3 has been released and GA is targeted to next week, Nov 4th 2015. Please review this bug and if not a blocker, please postpone to a later release. All bugs not postponed on GA release will be automatically re-targeted to - 3.6.1 if severity >= high - 4.0 if severity < high
The problem was solved in another component ( spice-gtk ), pending approval. See dependencies. We need another BZ for mingw... in rhevm 3.6
(In reply to David Blechter from comment #3) > The problem was solved in another component ( spice-gtk ), pending approval. > See dependencies. We need another BZ for mingw... in rhevm 3.6 Patches were acked and it will be upstream this week.
(In reply to David Blechter from comment #3) > The problem was solved in another component ( spice-gtk ), pending approval. > See dependencies. We need another BZ for mingw... in rhevm 3.6 Moving this to mingw-virt-viewer which it seems more accurate then ovirt. Target release is set to 3.6 and moving to POST due patches being acked [1] [2] [1] http://lists.freedesktop.org/archives/spice-devel/2015-October/022660.html [2] http://lists.freedesktop.org/archives/spice-devel/2015-October/022661.html
Patches pushed upstream usbredir: a88e197b18785d6de2322b5f26484c4130a6f2b9 e1a7e3dbbe091bfdc568372ff5ab18ed7eae972e spice-gtk: 36c7db9a38cc5335727c2abbe7968112eb6667e0
If this bug requires doc text for errata release, please provide draft text in the doc text field in the following format: Cause: Consequence: Fix: Result: The documentation team will review, edit, and approve the text. If this bug does not require doc text, please set the 'requires_doc_text' flag to -.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-0377.html