Closed Bug 1122400 Opened 9 years ago Closed 8 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
[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
(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
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)
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
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
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: 8 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: