Opened 10 years ago

Closed 9 years ago

#11173 closed bug (fixed)

Media player breaks under heavy load

Reported by: _samui Owned by: stippi
Priority: normal Milestone: R1
Component: Applications/MediaPlayer Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

#47758, real hardware, run from usb stick.

Opening multiple files (over ten) so that processor chokes: You get the usual dropping frames on terminal, the deskbar freezes. When you close the media player windows one by one, deskbar becomes responsive again. Despite closing those windows, mediaplayer still has the associated au_control etc. processes attached to every mediaPlayey instance you opened. MediaPlayer wont respond to close app, you have to manually kill it from processcontroller. If you leave it be, you get the following crash (included).

After the crash mediaPlayer can be started again. But it starts in a zombie mode and gets stuck opening files.

Attachments (2)

MediaPlayer-988-debug-29-08-2014-08-41-23.report (55.9 KB ) - added by _samui 10 years ago.
heapsafiles.txt (96.2 KB ) - added by _samui 10 years ago.
terminal log excerpt

Download all attachments as: .zip

Change History (7)

by _samui, 10 years ago

Attachment: heapsafiles.txt added

terminal log excerpt

comment:1 by stippi, 10 years ago

Thanks for the report. Which threads consume the most CPU? Also, it would be interesting to know whether this behaviour was already present before the work on the kernel scheduler. Can you try on Alpha 4.1?

in reply to:  1 ; comment:2 by _samui, 10 years ago

Thanks for the report. Which threads consume the most CPU?

The problem with testing with alpha4.1 is that there are so many video playback problems with it so would be pointless to test in my opinion. The recent work by Colin has improved things much, the video playback works really well now compared to say 2 months ago.

When the load goes high enough and deskbar freezes, how can I see the cpu consumption? Is there a thing to enter to the terminal to see it? Of course all that video stuff is realtime priority, im not suprised them freezing stuff.

in reply to:  2 comment:3 by stippi, 10 years ago

Replying to _samui:

The problem with testing with alpha4.1 is that there are so many video playback problems with it so would be pointless to test in my opinion. The recent work by Colin has improved things much, the video playback works really well now compared to say 2 months ago.

Interesting. What video formats have improved the most for you?

When the load goes high enough and deskbar freezes, how can I see the cpu consumption? Is there a thing to enter to the terminal to see it? Of course all that video stuff is realtime priority, im not suprised them freezing stuff.

You can launch the command top in the Terminal. In Deskbar, you should have the display of the CPU activitiy and it has a right-click menu where you see load graphically by component. But with Deskbar being frozen, this might not be helpful.

With the media playback, two contradicting concepts clash: High priority threads should not be CPU-intensive threads. But audio should not skip, so it is high priotity and it is decoding (CPU intensive). Sometimes video decoding is intermangled, since it is reading from the same file any may even contain important sync information.

In any case, the audio decoding having a higher priority than GUI redraw is on purpose so a peak of graphics activity does not make the audio skip. The freezing may be expected, depending on whether it is reasonable, given the actual video files you played and your hardware, to expect so many to play concurrently. In any case, MediaPlayer should not be left broken after things return back to normal.

comment:4 by _samui, 10 years ago

could somebody please close this. it's two separate bugs.

comment:5 by Barrett, 9 years ago

Resolution: fixed
Status: newclosed

Looks like fixed under different systems as of hrev49662.

Note: See TracTickets for help on using tickets.