maemo.org Bugzilla – Full Text Bug Listing
|Summary:||Media Player [bridge_work-que] battery drain|
|Product:||[Maemo Official Applications] Media player||Reporter:||mafonso|
|Status:||RESOLVED FIXED||QA Contact:||media-player-bugs|
|Priority:||Unspecified||CC:||andre_klapper, brad0112358, eero.tamminen, jhperez, mafonso|
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)
Hi, I assume this still happens in 3.2010.02-8? There are some issues with the thumbnailer daemon, see bug 8165 for example... :-/
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.
Does this still happen in 3.2010.02-8?
(In reply to comment #3) > Does this still happen in 3.2010.02-8? > yes, reproducible in the same way.
> - 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)?
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.
(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.
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".
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)
Brad: Please file a new report with exact steps (and testcase) please.
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
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."
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!
Still happening to my n900