Closed Bug 1122400 Opened 10 years ago Closed 9 years ago

[Flame][RTSP]RTSP error appears in browser app, and then there is an unwanted alert page if we play video in video app.

Categories

(Firefox OS Graveyard :: RTSP, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.1 affected, b2g-v2.2 unaffected)

RESOLVED WONTFIX
Tracking Status
b2g-v2.1 --- affected
b2g-v2.2 --- unaffected

People

(Reporter: huayu.li, Unassigned)

References

Details

Attachments

(6 files)

Attached file logcat1.txt (deleted) —
[1.Description]: According to comment#41 in Bug 1120875, this bug is filed. [Flame][v2.1][RTSP] If we play a video in video app after video play fails in browser app, it will prompt "Cannot play the video,Another app is currently using the video player" and then video can be played succeessfully. Occurence time:10:24 see attachments:logcat1.txt,RTSP.3gp. [2.Testing Steps]: 1.Enter www.wowza.com/html/mobile.html. 2.Tap RTSP link to play this video. 3.Playing failed for lost network. 4.Back to home and launch video. 5.Tap a video to play. [3.Expected Result]: 5.The alert page should not appear. [4.Actual Result]: 5."Cannot play the video,Another app is currently using the video player" page is displayed for 1-2 sec. [5.Reproduction build]: Flame 2.1 build: Gaia-Rev 8d4846d7bec777046dc5e3d2b8005adb1370f1f7 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8eb9bc3a945a Build-ID 20150115001207 Version 34.0 Flame 2.2 build: Gaia-Rev 7c5b27cad370db377b18a742d3f3fdb0070e899f Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/ce27f2692382 Build-ID 20150115002505 Version 37.0a2 [6.Reproduction Frequency]: occasionally Recurrence,7/10 [7.TCID]: Free Test
Attached video RTSP.3gp (deleted) —
(In reply to Alissa from comment #0) > Created attachment 8550152 [details] > logcat1.txt > > [1.Description]: > According to comment#41 in Bug 1120875, this bug is filed. Hi, Alissa, May I have I request? Please provide the correct information. Bug 1120875 doesn't have comment 41, right?
Flags: needinfo?(huayu.li)
I think this is edge case. I cannot associate this case with any general user scenario since I think user is not likely to play RTSP streaming with no internet connection, and then launch video in 10 seconds. Also, I think this message only can be easily triggered on low-end device because system resource is easy to lock. So, we need to tell user that the resource is occupied when it happens. But, I think we can double check behavior with feature owner. --- -- - --- -- - --- -- - --- -- - --- -- - --- -- - Hi, Ethan, May I have your help? We saw a system notification when user plays RTSP streaming with no internet access, and then play a video. As demo video. (RTSP.3gp) Do you think it is expected behavior? If you aren't the right person to ask this question, please help me forward it. Many thanks.
Flags: needinfo?(ettseng)
(In reply to William Hsu [:whsu] from comment #2) > Bug 1120875 doesn't have comment 41, right? Hi william, sorry for error information,it is comment 41 of 1111978.
Flags: needinfo?(huayu.li)
(In reply to William Hsu [:whsu] from comment #3) > I think this is edge case. I cannot associate this case with any general > user scenario since I think user is not likely to play RTSP streaming with > no internet connection, and then launch video in 10 seconds. For this ,why we failed video playing with no internet is just to simulate the situation when network is lost. Maybe there are other way to fail RTSP playing, but this way is easy to repro.
(In reply to Alissa from comment #4) > (In reply to William Hsu [:whsu] from comment #2) > > Bug 1120875 doesn't have comment 41, right? > > Hi william, > sorry for error information,it is comment 41 of 1111978. Okay! I saw the initial bug. Thanks.
(In reply to William Hsu [:whsu] from comment #3) > Hi, Ethan, > May I have your help? > We saw a system notification when user plays RTSP streaming with no internet > access, and then play a video. > As demo video. (RTSP.3gp) > Do you think it is expected behavior? After reading the STR description and watching the attached video, I think this is actually the same problem as bug 1111978. Although the steps to cause RTSP failure are different, the essential of these two bugs is the same. Any RTSP failure should not block playing video in other apps. Perhaps the patch of bug 1111978 does not resolve this problem thoroughly. I will look into it to find out what's wrong. Alissa, I remember you mentioned that this bug happens on 2.1 but not on 2.2. Is that right?
Assignee: nobody → ettseng
Flags: needinfo?(ettseng) → needinfo?(huayu.li)
Thanks Ethan! Yes! This is a follow up of Bug 1111978.
> Alissa, > I remember you mentioned that this bug happens on 2.1 but not on 2.2. > Is that right? Yes,The unwated alert page will displayed for 1-3sec,and then video can be played normally on 2.1,It did not appear on 2.2.
Flags: needinfo?(huayu.li)
Attached file Verified2.1.txt (deleted) —
This issue can be repro on latest Flame 2.1 build: See attachment:Verified2.1.txt & video_0009.mp4 Found time:05:26 Repro Steps: 1.Enter www.wowza.com/html/mobile.html. 2.Tap RTSP link to play this video. 3.Playing failed for lost network. 4.Back to home and launch video. 5.Tap a video to play. Expected Result: 5.The alert page should not appear. Actual Result: 5."Cannot play the video,Another app is currently using the video player" page is displayed for 1-2 sec. Reproduction build: Flame 2.1 build: Build ID 20150301001349 Gaia Revision 5d3479fdd438412adee4452720856b6b771fe5cd Gaia Date 2015-02-25 18:20:09 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/9bf4c663241f Gecko Version 34.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150301.034808 Firmware Date Sun Mar 1 03:48:19 EST 2015 Bootloader L1TC000118D0 occasionally Recurrence,3/10
Flags: needinfo?(mlien)
Attached video video_0009.mp4 (deleted) —
QA Whiteboard: [MGSEI-Triage+]
Hi Lance, could you also help to verify if this issue can be reproduced on v2.1S? Since this is a branch specific issue, we may only fixed on partner branch.
Flags: needinfo?(mlien) → needinfo?(liuke)
Attached file logcat_0423.txt (deleted) —
Hi mike,I can reproduce this issue on latest Dolphin 2.1s_512 but can't reproduce on 2.1s_256 Reproducing rate: 3/20 See attachment:2.1s_512.mp4 & logcat_0423.txt Dolphin 2.1s_256 build: Build ID 20150301161204 Gaia Revision a43d64ae01ef108aa4dcc971c770fecd8416a764 Gaia Date 2015-02-26 09:24:39 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/2437280c634f Gecko Version 34.0 Device Name scx15_sp7715ga Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150301.194157 Firmware Date Sun Mar 1 19:42:09 EST 2015 Dolphin 2.1S_512 build: Gaia-Rev a43d64ae01ef108aa4dcc971c770fecd8416a764 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/2437280c634f Build-ID 20150301161204 Version 34.0 Device-Name scx15_sp7715ea FW-Release 4.4.2 FW-Incremental 122 FW-Date Thu Feb 5 12:42:58 CST 2015
Flags: needinfo?(liuke)
Attached video 2.1s_512 .mp4 (deleted) —
Flags: needinfo?(mlien)
Hi Steven, if this issue need to be fixed on v2.1S?
Flags: needinfo?(mlien) → needinfo?(styang)
Let's pick the solution from bug 1111978.
blocking-b2g: --- → 2.1S+
Flags: needinfo?(styang) → needinfo?(vliu)
(In reply to Steven Yang [:styang] from comment #16) > Let's pick the solution from bug 1111978. Hi ettseng, Since the patch of bug 1111978 on v2.1s causes the fonflict, I can't merge it into v2.1s. Could you please help to attach the patch for v2.1s? Thanks
Flags: needinfo?(ettseng)
(In reply to Vincent Liu[:vliu] from comment #17) > Hi ettseng, > Since the patch of bug 1111978 on v2.1s causes the fonflict, I can't merge > it into v2.1s. Could you please help to attach the patch for v2.1s? Thanks I don't get it. The patch of bug 1111978 already landed in v2.1s on 2014/12/31. https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/ae2af1ecd237 Why do you want to merge it to v2.1s? Actually this bug requires another patch to fix (see comment 7). I was working on other tasks and haven't dig into this bug yet. Jonathan, please help to take this bug, thanks.
Assignee: ettseng → jhao
Status: NEW → ASSIGNED
Flags: needinfo?(ettseng)
At first, I cannot reproduce the bug. Then I noticed that in Lance's video, he tap the video many times in video app. So I tried to tap the video for many times very quickly, and I can reproduce the error message, without opening RTSP video beforehand. Therefore, I think the problem wasn't that RTSP occupied the hardware. The problem was that user tap the video many times. The first tap opened the video, but before the video was open, the second tap is rejected because the first tap makes the hardware occupied. I think the bug belongs to video app instead of the RTSP component.
Even though I had to tap more quickly than Lance does in his video, but I guess it depends on the timing, and I doubt that if it can be reproduced if you only tap the video once. Also, the error message is only visible for a very short moment. The video can be played very soon after that. I don't think it is a blocker. CC Steven and Benjamin
According to comment 19 and comment 20, I think this issue is minor and shouldn't be a blocker. Steve, could you please confirm that we can remove the blocker flag?
Flags: needinfo?(slee)
agree. clear the plus. thanks.
blocking-b2g: 2.1S+ → ---
Flags: needinfo?(slee)
Clear the ni? since the Comment 22.
Flags: needinfo?(vliu)
Unassign myself since I'm not actively working on Firefox OS anymore.
Assignee: jhao → nobody
Status: ASSIGNED → NEW
RTSP in FxOS is rarely used by users. Unless there is strong user demand/requirement, I don't think anyone will fix this bug.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: