Opened 19 months ago

Last modified 6 months ago

#2296 reopened defect

100% cpu usage while stream cache is filling

Reported by: curaga Owned by: beastd
Priority: low Component: undetermined
Version: HEAD Severity: minor
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: no Analyzed by developer: no

Description

Summary of the bug: While the cache is filling, mplayer uses 100% cpu even though it can do nothing. On a slow server (/internet connection), it can take tens of seconds of high cpu use.

How to reproduce:

% mplayer -cache 16384 -cache-min 99 http://somestream
SVN-r37699-5.2.0

Attachments (2)

good.txt (757 bytes) - added by curaga 6 months ago.
oprofile from a good run (manual xterm start)
bad.txt (22.2 KB) - added by curaga 6 months ago.
oprofile from a bad run (browser-forked)

Download all attachments as: .zip

Change History (9)

comment:1 Changed 14 months ago by compn

  • Resolution set to worksforme
  • Status changed from new to closed

what os?

there used to be a problem with the amount of updates to the command line causing cpu usage, but this was fixed long ago.

comment:2 Changed 14 months ago by curaga

Linux 64-bit. Affects every stream.

Since this was on a 5 months old mplayer build, do you want me to check on latest?

comment:3 Changed 9 months ago by beastd

Did you check with latest MPlayer from SVN?

Is this still reproducible?

comment:4 Changed 6 months ago by curaga

This still happens with today's SVN, 37940.

comment:5 Changed 6 months ago by curaga

  • Resolution worksforme deleted
  • Status changed from closed to reopened

comment:6 Changed 6 months ago by curaga

Checking further, it does not happen when launched manually in a terminal, only when launched by the browser via fork()/system(). The same URL and same arguments were used in both cases.

I wonder if it's due to the browser-forked one running on a VT, and the manual launch in an xterm.

Changed 6 months ago by curaga

oprofile from a good run (manual xterm start)

Changed 6 months ago by curaga

oprofile from a bad run (browser-forked)

comment:7 Changed 6 months ago by curaga

I took oprofile runs from both. In the good run, mplayer and others are in the minority, in the bad run libc and mplayer are taking a ton of cpu.

Note: See TracTickets for help on using tickets.