Opened 15 years ago

Closed 9 years ago

#3680 closed bug (fixed)

Remnant threads in media player after playback

Reported by: koki Owned by: dlmcpaul
Priority: normal Milestone: R1
Component: Audio & Video/Codecs Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

A couple of threads in the MediaPlayer keep consuming CPU after the playback of a M4V video file is finished. It seems to happen with all the M4V files that I have here, but not with video files in other formats.

I can provide a sample file if needed. For now I am attaching a screenshot that shows the threads in question, and a BT from the KDL debugger.

(Feel free to change component if necessary.)

Attachments (2)

1-threads.png (151.7 KB ) - added by koki 15 years ago.
Thread running after video playback is finished
2-kdl-bt.jpg (280.5 KB ) - added by koki 15 years ago.
BT from KDL

Download all attachments as: .zip

Change History (8)

by koki, 15 years ago

Attachment: 1-threads.png added

Thread running after video playback is finished

by koki, 15 years ago

Attachment: 2-kdl-bt.jpg added

BT from KDL

comment:1 by marcusoverhagen, 15 years ago

Owner: changed from marcusoverhagen to dlmcpaul

probably a bug in the mp4 reader, reassigning

in reply to:  1 comment:2 by dlmcpaul, 15 years ago

Status: newassigned

Replying to marcusoverhagen:

probably a bug in the mp4 reader, reassigning

From the bt attachment it looks like the mp4 reader is not detecting EOF on that file so is continuing to read chunks.

I will debug further.

comment:3 by dlmcpaul, 15 years ago

I am having trouble reproducing this.

I am using the duetto_8-9.m4v file you sent me before.

Is there anything else you can tell me about what is happening?

comment:4 by koki, 15 years ago

@dlmcpaul

Thanks for looking into this. :) I am not doing anything unusual during playback; in fact, I can reproduce this 100% of the time by playing the above-mentioned file right after booting the system, without starting any other apps.

For what may be worth, here is the hardware this is happening on:

Acer Aspire One netbook Atom CPU (N270, single-core w/hyperthreading running @ 1.6G) Intel 945GSE Express chipset Intel 82801GBM (ICH7M) I/O controller

I am using the Haiku HDA native driver (OSS not installed), which otherwise seems to be working fine for the most part. Haiku revision is 29843, and this is gcc2 build.

There are what look like HDA-related entries towards the end of the syslog; if this is something that may help, I could attach the syslog if you want.

in reply to:  4 comment:5 by dlmcpaul, 15 years ago

Replying to koki:

@dlmcpaul

Thanks for looking into this. :) I am not doing anything unusual during playback; in fact, I can reproduce this 100% of the time by playing the above-mentioned file right after booting the system, without starting any other apps.

For what may be worth, here is the hardware this is happening on:

Acer Aspire One netbook Atom CPU (N270, single-core w/hyperthreading running @ 1.6G) Intel 945GSE Express chipset Intel 82801GBM (ICH7M) I/O controller

I am using the Haiku HDA native driver (OSS not installed), which otherwise seems to be working fine for the most part. Haiku revision is 29843, and this is gcc2 build.

There are what look like HDA-related entries towards the end of the syslog; if this is something that may help, I could attach the syslog if you want.

Ok I will try to load the current build on my Eee PC (similar specs to above)

I might send you a debug mp4_reader as well later.

comment:6 by pulkomandy, 9 years ago

Resolution: fixed
Status: in-progressclosed

There is no mp4_reader anymore, ffmpeg takes care of this now. Closing.

Note: See TracTickets for help on using tickets.