Comment 1 Andre Klapper 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... :-/

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 2010-02-25 23:21:40 UTC

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.

Comment 5 Eero Tamminen 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)?

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 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 2010-03-15 12:19:40 UTC

This seems related to bug 6823.

Comment 9 Andre Klapper 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".

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 2010-08-20 12:59:20 UTC

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

Comment 13 Andre Klapper 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."

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

Comment 16 Andre Klapper 2010-09-16 23:31:10 UTC

(In reply to comment #15)
> Still happening to my n900

See bug 11214.