Closed Bug 1153895 Opened 9 years ago Closed 9 years ago

test_music_songs_3gp.py: " TimeoutException: TimeoutException: Timed out after 10.3 seconds with message: 3gp sample did not start playing "

Categories

(Firefox OS Graveyard :: Gaia::Music, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.5+, firefox40 fixed, b2g-master fixed)

RESOLVED FIXED
2.2 S12 (15may)
blocking-b2g 2.5+
Tracking Status
firefox40 --- fixed
b2g-master --- fixed

People

(Reporter: njpark, Assigned: bwu)

References

Details

(Whiteboard: fbimage)

Attachments

(2 files, 1 obsolete file)

Attached file MUS_0001.3gp
Gaia UI test (music/test_music_songs_3gp.py) fails because MUS_0001.3gp cannot be played on Music app.

STR:
Load attached music file
Open Music app, select and play the app

Actual:
the Pause button is shown, but nothing is playing.  File length counter is not shown.
Expected:
Music file should play.
The music file should play without
ni?ing hub for assessment.

Geo, should we disable this test script?
Flags: needinfo?(hub)
Flags: needinfo?(gmealer)
Whiteboard: fbimage
Renaming your title to help out with queries.
Observed this in an adhoc job as well: 0/5 passing

http://jenkins1.qa.scl3.mozilla.com/job/flame-kk.ui.adhoc/786/HTML_Report/

Traceback (most recent call last):
  File "/var/jenkins/2/workspace/flame-kk.ui.adhoc/.env/local/lib/python2.7/site-packages/marionette_client-0.9-py2.7.egg/marionette/marionette_test.py", line 290, in run
    testMethod()
  File "/var/jenkins/2/workspace/flame-kk.ui.adhoc/tests/python/gaia-ui-tests/gaiatest/tests/functional/music/test_music_songs_3gp.py", line 38, in test_select_songs_play_3gp_file
    message='3gp sample did not start playing')
  File "/var/jenkins/2/workspace/flame-kk.ui.adhoc/tests/python/gaia-ui-tests/gaiatest/gaia_test.py", line 960, in wait_for_condition
    Wait(self.marionette, timeout).until(method, message=message)
  File "/var/jenkins/2/workspace/flame-kk.ui.adhoc/.env/local/lib/python2.7/site-packages/marionette_driver-0.2-py2.7.egg/marionette_driver/wait.py", line 143, in until
    cause=last_exc)
TimeoutException: TimeoutException: Timed out after 10.2 seconds with message: 3gp sample did not start playing
Summary: Flame: Music app can't play 3gp audio file → test_music_songs_3gp.py: " TimeoutException: TimeoutException: Timed out after 10.3 seconds with message: 3gp sample did not start playing "
To me this looks like a change in Gecko broke stuff. We should try to get a regression range for it.
Flags: needinfo?(hub)
qawanted for branch check and regression range.
Actually, this does not repro on today's nightly build: https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-central-flame-kk-eng/2015/04/2015-04-14-07-24-38/ 

Perhaps the backout for https://bugzilla.mozilla.org/show_bug.cgi?id=1153831 is the reason?

Should monitor it for a couple more builds, and close it.
I was able to reproduce this issue manually on a 4/13 nightly build, but not on today's build. So I think this bug is no longer occurring and should be closed.

Repro'ed on:
Device: Flame 3.0
BuildID: 20150413010203
Gaia: 3c68964cb9fdba7cf0f6829b7f44562acaf1f1d7
Gecko: 0a46652bd992
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

No repro on (the attached 3gp file can be played in Music app):
Device: Flame 3.0
BuildID: 20150421010201
Gaia: a8e4f95dce9db727dda5d408b038f97fb4296557
Gecko: 7b823253d9f2
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

----

Also checked v2.2 and it's not reproducing either.

No repro on:
Device: Flame 2.2
BuildID: 20150421002501
Gaia: 828dd03a0e3b140d74b2e49355197df4d91d9227
Gecko: 36f72a3efb9b
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Status: NEW → RESOLVED
Closed: 9 years ago
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Resolution: --- → WORKSFORME
This is consistently failing in automation again for what appears to be the same error:
* http://jenkins1.qa.scl3.mozilla.com/job/flame-kk-319.mozilla-central.nightly.ui.functional.non-smoke.2/187/HTML_Report/
* http://jenkins1.qa.scl3.mozilla.com/view/UI/job/flame-kk.ui.adhoc/812/HTML_Report/

Traceback (most recent call last):
File "/var/jenkins/2/workspace/flame-kk.ui.adhoc/.env/local/lib/python2.7/site-packages/marionette_client-0.11-py2.7.egg/marionette/marionette_test.py", line 296, in run
testMethod()
File "/var/jenkins/2/workspace/flame-kk.ui.adhoc/tests/python/gaia-ui-tests/gaiatest/tests/functional/music/test_music_songs_3gp.py", line 38, in test_select_songs_play_3gp_file
message='3gp sample did not start playing')
File "/var/jenkins/2/workspace/flame-kk.ui.adhoc/tests/python/gaia-ui-tests/gaiatest/gaia_test.py", line 1034, in wait_for_condition
Wait(self.marionette, timeout).until(method, message=message)
File "/var/jenkins/2/workspace/flame-kk.ui.adhoc/.env/local/lib/python2.7/site-packages/marionette_driver-0.4-py2.7.egg/marionette_driver/wait.py", line 143, in until
cause=last_exc)
TimeoutException: TimeoutException: Timed out after 10.2 seconds with message: 3gp sample did not start playing

Passed 0/6 performed tests today

This issue reproduces manually, using the same file, with 100% repro


Repro Steps:

PreReq:
* 3gp file in music app
1) Update phone to 20150428010206
2) Open Music app
3) Attempt to play *.3gp file
4) Observe UI/Audio playback

Actual Results:
UI transitions to active song, does not play; end time is '---:--'

Expected Results:
UI transitions to active song and plays through track

Repro Rate: 0/5 passing
Status: RESOLVED → REOPENED
Flags: needinfo?(npark)
Resolution: WORKSFORME → ---
[Blocking Requested - why for this release]:

Looks like the bug came back in master, nominating for 3.0
blocking-b2g: --- → 3.0?
Flags: needinfo?(npark)
ni?ing hub again for the comeback of this issue.
Flags: needinfo?(hub)
QA Contact: ychung
Mozilla-inbound Regression Window:

Last Working Environmental Variables:
Device: Flame 3.0
BuildID: 20150427015253
Gaia: b4c949cdc780893897c9b45c1adea46e2eb694ff
Gecko: fe832ef6cc60
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

First Broken Environmental Variables:
Device: Flame 3.0
BuildID: 20150427020457
Gaia: b4c949cdc780893897c9b45c1adea46e2eb694ff
Gecko: 5fa88d413c4f
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Last Working Gaia First Broken Gecko: Issue DOES reproduce 
Gaia: b4c949cdc780893897c9b45c1adea46e2eb694ff
Gecko: 5fa88d413c4f

First Broken Gaia Last Working Gecko: Issue does NOT reproduce
Gaia: b4c949cdc780893897c9b45c1adea46e2eb694ff
Gecko: fe832ef6cc60

http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=fe832ef6cc60&tochange=5fa88d413c4f

Caused by bug 1146729
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Blake, can you take a look at this please? Here is another major issue that seems to have been caused by the landing for bug 1146729.
Blocks: 1146729
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(bwu)
I has confirmed this bug is caused by MP4Reader enabling, bug 1146729. 
So take this bug to check it further.
Assignee: nobody → bwu
Flags: needinfo?(bwu)
Flags: needinfo?(hub)
The rootcause of this bug is MP4Reader doesn't support audio AMR-WB which the attached test content is encoded in. This bug is similar to Bug 1159509. I will make it supported as well.
See Also: → 1160624
The rootcause of this bug is we don't support AMR-WB in MP4Reader, which previously Omx reader supported. And that causes the regression here.  

This patch is to support audio AMR-WB for Gonk in MP4Reader.
Attachment #8600736 - Flags: review?(jyavenard)
Comment on attachment 8600736 [details] [diff] [review]
Support-audio-AMR-WB-for-Gonk-in-MP4Reader.patch

Review of attachment 8600736 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/media/fmp4/MP4Reader.cpp
@@ +380,1 @@
>            aMimeType.EqualsLiteral("audio/3gpp")) &&

I never understood the point of check both mPlatform->SupportsMimeType *and* have all those extra tests anyway in MP4Reader...
Attachment #8600736 - Flags: review?(jyavenard) → review+
(In reply to Jean-Yves Avenard [:jya] from comment #15)
> Comment on attachment 8600736 [details] [diff] [review]
> Support-audio-AMR-WB-for-Gonk-in-MP4Reader.patch
> 
> Review of attachment 8600736 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/media/fmp4/MP4Reader.cpp
> @@ +380,1 @@
> >            aMimeType.EqualsLiteral("audio/3gpp")) &&
> 
> I never understood the point of check both mPlatform->SupportsMimeType *and*
> have all those extra tests anyway in MP4Reader...
To let each Platform be able to have its own supported list...!?
(In reply to Blake Wu [:bwu][:blakewu] from comment #16)
> To let each Platform be able to have its own supported list...!?

yes, that's what mPlatform->SupportsMimeType is for...

We just duplicate the same test in MP4Reader , and do a && on mPlatform->SupportsMimeType like we would do should we want to filter what the MP4Reader will actually support: when it will never make a difference (1 && 1 = 1)
Carry r+ from jya.
Attachment #8600736 - Attachment is obsolete: true
Attachment #8600829 - Flags: review+
Test results look reasonable on try server. Those busted should not be caused by this bug. 
https://treeherder.mozilla.org/#/jobs?repo=try&revision=f4729e434863
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/7bcd2168ad87
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S12 (15may)
Depends on: 1160624
Depends on: 1161546
blocking-b2g: 2.5? → 2.5+
You need to log in before you can comment on or make changes to this bug.