Description: After watching a video once in Video app, pressing play to watch a second time results in a static image with audio only. Video is not replayed. Videos in library are all 3GP files and were recorded with device. Repro Steps: 1) Updated Buri to BuildID: 20140408040204 2) Launch Video app 3) Select video and watch 4) Once video playback is complete, press play button to watch again Actual: Static image with audio is shown on second playthrough in video app. Expected: User can watch and rewatch videos with no issues encountered. Environmental Variables: Device: Buri Master M-C Mozilla RIL BuildID: 20140408040204 Gaia: 1958454595b1fa0e061f0652ae965629993f5708 Gecko: 8883360b1edb Version: 31.0a1 Firmware Version: v1.2-device.cfg Notes: Repro frequency: 3/3, 100% See attached: Youtube video clip & logcat

Youtube link: http://youtu.be/fj3ux-NdS1k Note: If video app is closed via card view, user can watch video again by reopening video app. After watching it again however, this issue reoccurs.

Can we confirm this isn't happening on 1.4?

(In reply to Jason Smith [:jsmith] from comment #2) > Can we confirm this isn't happening on 1.4? Following the repro steps, I was unable to repro on the latest 1.4 Buri build 1.4 Environmental Variables: Device: Buri 1.4 MOZ BuildID: 20140409000202 Gaia: 26983f356ecb1bcf30e862d334b5de790071803e Gecko: e450e07e3a58 Version: 30.0a2 Firmware Version: v1.2-device.cfg

Mozilla Inbound Regression Window: Last Working Device: Buri 1.5 MOZ BuildID: 20140331115051 Gaia: 26839cb46f856d610b192f5655a8c38a6bfe0829 Gecko: abebf45061a9 Version: 31.0a1 Firmware Version: v1.2-device.cfg First Broken Device: Buri 1.5 MOZ BuildID: 20140331232935 Gaia: 874fe42b82e8d819d592690e74db91c07179e68c Gecko: ba93b2f34a3f Version: 31.0a1 Firmware Version: v1.2-device.cfg First Broken Gaia Last Working Gecko: Issue Doesn't reproduce Gaia: 874fe42b82e8d819d592690e74db91c07179e68c Gecko: abebf45061a9 Last Working Gaia First Broken Gecko: Issue Does reproduce Gaia: 26839cb46f856d610b192f5655a8c38a6bfe0829 Gecko: ba93b2f34a3f Gecko Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=abebf45061a9&tochange=ba93b2f34a3f

The window here is incorrect. There should be only a couple changesets present in the push log if this was done correctly.

Revised Mozilla Inbound Regression: Last Working Device: Buri 1.5 MOZ BuildID: 20140331200633 Gaia: eee8caa81a368f0feace718201ed15a423812c18 Gecko: d313210d2619 Version: 31.0a1 Firmware Version: v1.2-device.cfg First Broken Device: Buri 1.5 MOZ BuildID: 20140331204432 Gaia: eee8caa81a368f0feace718201ed15a423812c18 Gecko: 35180f110e44 Version: 31.0a1 Firmware Version: v1.2-device.cfg Gaia did not change between builds so this seems to be a Gecko issue Gecko Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d313210d2619&tochange=35180f110e44

Either bug 778077 or bug 631058 broke this. Chris - Do you know?

I can reproduce this bug on Otoro with B2G Master with m-c tip, but B2G Master with Gecko revisions 9c0afbe41ce8 (bug 778077) and 35180f110e44 (bug 631058) do not reproduce this bug. Are you sure that regression window is correct?

I'm wrong. This *is* a regression from bug 631058, this bug does not occur with only bug 778077 landed.

The problem is that we're setting the decoder to idle once we pause in order to seek, and then when we decode in DecodeToTarget() the decode fails. So don't set the reader idle when we're seeking. And add assertions in debug builds to ensure we don't break this again.

Landed for Gecko 31: https://hg.mozilla.org/integration/mozilla-inbound/rev/6cc06a35f253 Thanks for catching/reporting this guys.

(In reply to Chris Pearce (:cpearce) from comment #10) > Created attachment 8406569 [details] [diff] [review] > Patch > > The problem is that we're setting the decoder to idle once we pause in order > to seek, and then when we decode in DecodeToTarget() the decode fails. > > So don't set the reader idle when we're seeking. And add assertions in debug > builds to ensure we don't break this again. MediaDecoderStateMachine::DecodeSeek calls EnsureActive before calling mReader->Seek or mReader->DecodeToTarget to ensure the reader is active. It looks like EnsureActive didn't work for Bug 1000841.