Bug 9084 (int-159643)

Summary: Media Player [bridge_work-que] battery drain
Product: [Maemo Official Applications] Media player Reporter: mafonso
Component: GeneralAssignee: unassigned <nobody>
Status: RESOLVED FIXED QA Contact: media-player-bugs
Severity: major    
Priority: Unspecified CC: andre_klapper, brad0112358, eero.tamminen, jhperez, mafonso
Version: 5.0/(3.2010.02-8)Keywords: use-time
Target Milestone: 5.0/(10.2010.19-1)   
Hardware: ARM   
OS: Maemo   

Description mafonso (reporter) 2010-02-16 20:53:51 UTC
SOFTWARE VERSION:
(Settings > General > About product)
2.2009.51-1

EXACT STEPS LEADING TO PROBLEM: 
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
1. Notice first that CPU downs to 250Mhz when idle (e.g using Conky)
2. Start Media Player
3. Choose Video (Video thumbs are shown)
4. Leave Media Player

EXPECTED OUTCOME:
When idle the device should down the CPU to 250Mhz

ACTUAL OUTCOME:
- The CPU speed wont get lower than 500Mhz
- gst-video-thumbnailerd still running heavy for a few seconds (guess its
normal)
- after a few seconds a bridge_work-que process shows up running with high cpu
load and maybe keeping the CPU from getting into an idle state, thus draining
battery. 

REPRODUCIBILITY:
(always)
Comment 1 Andre Klapper maemo.org 2010-02-17 01:23:31 UTC
Hi,
I assume this still happens in 3.2010.02-8? There are some issues with the
thumbnailer daemon, see bug 8165 for example... :-/
Comment 2 mafonso (reporter) 2010-02-17 01:36:02 UTC
Yes, bug is still present in 3.2010.02-8. 
I just finished updating to 3.2010.02-8 and tested, and it still happens
exactly the same way.

Another clue: Opening the video files straight from the File Manager does not
trigger this issue no matter how many times I do it. 

The only thing that triggers it, is using the "Video" option in the Media
Player menu, which calls the thumbnailer daemon. Using other Media Player
options such as Music or Internet Radio do not seem raise any issue. So it
looks definitely thumbnailer related.
Comment 3 Andre Klapper maemo.org 2010-02-25 23:21:40 UTC
Does this still happen in 3.2010.02-8?
Comment 4 mafonso (reporter) 2010-02-26 15:48:31 UTC
(In reply to comment #3)
> Does this still happen in 3.2010.02-8?
> 

yes, reproducible in the same way.
Comment 5 Eero Tamminen nokia 2010-03-12 15:32:15 UTC
> - gst-video-thumbnailerd still running heavy for a few seconds (guess its
>   normal)
> - after a few seconds a bridge_work-que process shows up running with high cpu
>   load and maybe keeping the CPU from getting into an idle state

AFAIK this bridge kernel thread communicates with the DSP.  Video thumbnailer
uses DSP to get suitable frame from the video for the thumbnail (it needs to
seek a bit into video as videos often start with black screen).

So video-thumbnailer first doing something and DSP then doing something else is
natural.

What happens if you wait longer until video-thumbnailer has definitely stopped
working (say several minutes, depending on how many videos you have)?
Comment 6 mafonso (reporter) 2010-03-13 03:54:02 UTC
I just noticed I can no longer reproduce this issue.  thumbnailerd runs for a
while as usual, but then there is no more weird activity on brigde_work_que.

I haven't used the media player for videos since then. I either open the videos
from the file manager or from command line with the mplayer tool, which I
installed meanwhile.

Other change I can remember since then is that I deleted some videos I couldn't
open, maybe due to codec issues. Could it be that an invalid video triggered
the issue.

As long as I recall, once [bridge_work-que] went crazy it would stay with heavy
load for much more then a few minutes, hours even. 
In fact, the reason I found the issue, was because I noticed the battery
draining fast and then a wild process not letting the CPU idle.

Something changed on my environment since then, as it is no longer
reproducible.
Comment 7 Eero Tamminen nokia 2010-03-15 12:11:47 UTC
(In reply to comment #6)
> Other change I can remember since then is that I deleted some videos
> I couldn't open, maybe due to codec issues. Could it be that an invalid
> video triggered the issue.

Many of the issues related to video are codec/stream/file specific.  Are these
files something you can give a link to or legally attach to this bug?


> As long as I recall, once [bridge_work-que] went crazy it would stay with
> heavy load for much more then a few minutes, hours even. 
> In fact, the reason I found the issue, was because I noticed the battery
> draining fast and then a wild process not letting the CPU idle.
Comment 8 Eero Tamminen nokia 2010-03-15 12:19:40 UTC
This seems related to bug 6823.
Comment 9 Andre Klapper maemo.org 2010-03-17 04:59:21 UTC
This issue seems to be triggered only with some specific videos which show also
problems like in the already fixed bug 6823.
This was tested also with videos that found from that bugs and could not be
reproduced anymore in current internal versions.

Hence this will be also fixed by the next public update "PR1.2".
Comment 10 Brad Bosch 2010-08-19 19:05:45 UTC
Running PR 1.2 with extra decoders support installed.  Over the past few days,
I have noticed any time I view the list of videos in Media player (and then
quit media player), the phone becomes warmer and battery drains fast until I
reboot.  I checked, and indeed, the bridge_work-que process is periodically
(every 10 to 60 seconds) consuming 100% of the CPU for several seconds (perhaps
5).  I noticed a video which didn't display a preview thumbnail and when I
removed it, the problem went away after the next reboot and didn't come back on
viewing the list of videos.  Apparently, this bug still exists in PR 1.2

Please reopen this bug.  Let me know if and where you want me to email the
offending video file (it is large)
Comment 11 Andre Klapper maemo.org 2010-08-20 12:59:20 UTC
Brad: Please file a new report with exact steps (and testcase) please.
Comment 12 Brad Bosch 2010-08-20 23:26:14 UTC
Please excuse my skeptical attitude, but why would you want a duplicate bug
report when the old report already specifies exactly the way to produce the
problem in the original comment and the symptoms I see are exactly the same? 
It seems that the root cause was not entirely fixed.

As I said, I'm happy to email the video, or perhaps I can truncate it and
attache it here and it will still produce the symptoms, but the easy thing
would be for me to email it to you.

Thanks,

--Brad
Comment 13 Andre Klapper maemo.org 2010-08-21 13:02:43 UTC
Because different code issues can create the same outcome, and because that's
how it works for Nokia. Same for http://wiki.meego.com/Bugzilla/how-report-bugs
: "DO NOT reopen if same defect found again after more than 2 weeks. New bug
report is mandatory."
Comment 14 Brad Bosch 2010-08-29 23:33:14 UTC
OK.  I have created bug 11214 which is the same problem with a sample video
clip which reproduces it attached.

I'm not sure if these two bugs should be linked as dependencies....

Thanks!
Comment 15 John Perez 2010-09-16 23:25:06 UTC
Still happening to my n900
Comment 16 Andre Klapper maemo.org 2010-09-16 23:31:10 UTC
(In reply to comment #15)
> Still happening to my n900

See bug 11214.