Cause:
On migration, the destination host does not send the client its multi-media time (does not send MSG_MAIN_INIT).
Consequence (from comment #0):
If there is no audio playback, and the 2 hosts that are involved in migration have different uptime, the client that is connected during migration, holds the multi-media time of the source server. Then, video frames that are created after migration (and thus hold the destination mm-time), are dropped by the client.
Fix:
Make destination host send multi-media time after migration.
Result:
Video without audio now plays successfully.
Description of problem:
If there is no audio playback, and the 2 hosts that are involved in migration have different uptime, the client that is connected during migration, holds the multi-media time of the source server. Then, video frames that are created after migration (and thus hold the destination mm-time), are dropped by the client.
Disconnecting and reconnecting the client will eliminate the inconsistency.
How reproducible:
(1) VM without audio device (I'm not sure that just muting the sound will stop sending audio frames to the client).
(2) connect a client to the vm
(3) migrate between 2 hosts with significantly different mm-time
(4) play video.
An alternative to (1) is to play a video without a soundtrack.
Additional info:
When there is a soundtrack, the client updates it mm-time by using the audio frames mm-time.
This bug is complementary to bug #951664
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.
http://rhn.redhat.com/errata/RHBA-2013-1571.html
Description of problem: If there is no audio playback, and the 2 hosts that are involved in migration have different uptime, the client that is connected during migration, holds the multi-media time of the source server. Then, video frames that are created after migration (and thus hold the destination mm-time), are dropped by the client. Disconnecting and reconnecting the client will eliminate the inconsistency. How reproducible: (1) VM without audio device (I'm not sure that just muting the sound will stop sending audio frames to the client). (2) connect a client to the vm (3) migrate between 2 hosts with significantly different mm-time (4) play video. An alternative to (1) is to play a video without a soundtrack. Additional info: When there is a soundtrack, the client updates it mm-time by using the audio frames mm-time. This bug is complementary to bug #951664