Ticket #146 (closed defect: fixed)

Opened 3 years ago

Last modified 2 years ago

High CPU usage when paused

Reported by: mp2user Owned by:
Priority: normal Milestone:
Component: General Version: devel
Severity: major Keywords:
Cc: Platform: Linux

Description

Hi

Recently i switched to the git version of mplayer2, after my distribution stopped providing it through the repos.

The issue is that when a video is paused, then the cpu usage increases to 100%. Otherwise the usage is normal. This behaviour wasn't displayed by the repository version.

Note: I found that this happens only when using a file manager. Tested with mc, pcmanfm.

When using the terminal, this doesn't happen.

Change History

comment:1 Changed 3 years ago by uau

The problem could be that the file manager starts the process with terminal keyboard controls enabled, but with stdin not being connected to anything readable. Do the command file options used by the file manager contain anything like --no-consolecontrols? That should be used if the process has no terminal.

If so, this is primarily an error in how the file managers start the player, though it would probably be possible to add some workaround on the mplayer2 side to detect this situation and stop attempts to read from stdin.

comment:2 Changed 3 years ago by mp2user

While using pcmanfm, the mplayer.desktop file is used. It contains

mplayer -really-quiet %F

And midnight commander (mc) uses its own extensions file, which has

mplayer %f >/dev/null 2>&1 &

comment:3 follow-up: ↓ 4 Changed 3 years ago by uau

Where does that mplayer.desktop file come from? The mplayer2 sources contain one, but it doesn't match that (there's no --really-quiet; the included file looks outdated in general).

comment:4 in reply to: ↑ 3 Changed 3 years ago by mp2user

Replying to uau:

Where does that mplayer.desktop file come from? The mplayer2 sources contain one, but it doesn't match that (there's no --really-quiet; the included file looks outdated in general).

I thought it was from the mplayer2 sources, but it seems it's bundled by the package maintainer. Actually i am using arch linux, and it's a package from the AUR --> mplayer2-git.

If the .desktop file is an issue, i'll ask the maintainer to use a recent one.

But, what about mc's command, is it fine?

comment:5 follow-up: ↓ 6 Changed 3 years ago by tcwardrobe

Hi,

Debian sid with mplayer2 from debian-multimedia.org version 2.0~git20120128-0.0 used here.

For what it's worth, strace shows messages like this while pausing a video, repeating over and over again in a loop:

gettimeofday({1328404822, 157903}, NULL) = 0
select(5, [0 4], NULL, NULL, {0, 20000}) = 1 (in [0], left {0, 19998})
read(0, "", 256) = 0
recv(4, 0xa028928, 4096, MSG_WAITALL) = -1 EAGAIN (Resource temporarily unavailable)

No idea if that helps and aside from that I can confirm that this issue only happens when using mplayer2 via a file-manager (nautilus used here). The only option used there is "-idx >/dev/null 2>&1". That is from a handcrafted .desktop file I generated years ago for mplayer1. And as another side-note, mplayer1 does not have this issue but no idea if that helps as I don't know if the codebase does differ way too much these days to help find the buggy code.
At least I have no idea when that issue was introduced.

Tested piping to /dev/null in a xterm, no issue there btw.

regards
Michael

comment:6 in reply to: ↑ 5 ; follow-up: ↓ 7 Changed 3 years ago by uau

Replying to tcwardrobe:

That strace is about what I'd expect in the situation described above. There's no need to provide such extra info; the behavior is already known. Why did you not test with --no-consolecontrols? Currently you should use that unless you start the process from a terminal and want to use keyboard input through the terminal window to control the process. As described above, a workaround that could be implemented on the player side would be to try detecting when stdin is a terminal and disable controls by default if not.

This is not exactly a bug, and terminal input reading behavior itself hasn't significantly changed. The difference from old versions is that the old versions had enough latencies in input reading code to prevent CPU use from reaching 100% even in the presence of spurious input events. Now input handling is more efficient, and input events can thus cause a higher load.

It seems you haven't understood what triggers the high CPU use. "Piping TO /dev/null" is irrelevant. It's the input side that matters. Piping FROM /dev/null is expected to trigger high CPU use if you leave terminal controls enabled.

comment:7 in reply to: ↑ 6 Changed 3 years ago by tcwardrobe

Please, bear in mind I am a *user* and not a developer. So some things may not come to me so... natural.

Replying to uau:

Replying to tcwardrobe:

That strace is about what I'd expect in the situation described above. There's no need to provide such extra info; the behavior is already known.

You did "suspect" something, I did provide the "proof" now we *know*! What is wrong with that?

Why did you not test with --no-consolecontrols?

Because I did miss / overread that piece or at least didn't understand the implications right at first.

Currently you should use that unless you start the process from a terminal and want to use keyboard input through the terminal window to control the process.

Tested, works, will use that from now on. :)

As described above, a workaround that could be implemented on the player side would be to try detecting when stdin is a terminal and disable controls by default if not.

Sounds like a good idea.

This is not exactly a bug, and terminal input reading behavior itself hasn't significantly changed. The difference from old versions is that the old versions had enough latencies in input reading code to prevent CPU use from reaching 100% even in the presence of spurious input events. Now input handling is more efficient, and input events can thus cause a higher load.

Funny how improvements can work out. ;)

It seems you haven't understood what triggers the high CPU use.

Exactly, and it is still kinda fuzzy to me. But as I am just a user and not a developer... I really don't mind! :)

"Piping TO /dev/null" is irrelevant. It's the input side that matters. Piping FROM /dev/null is expected to trigger high CPU use if you leave terminal controls enabled.

NACK. Piping from /dev/null doesn't work at all, piping from /dev/zero does and does indeed produce 100% CPU use on one core. I may understand that to a certain degree, and I did not say piping to /dev/null did cause the high CPU use... but I was not *sure* if it *may* have to do something with it. As... I am just a user and not a developer! ;)

In other words, I am happy now, thanks for mplayer2, works even better than mplayer1 and some really annoying mplayer peculiarities are a thing of the past. Thanks again! :)

regards
Michael

comment:8 Changed 2 years ago by sghpunk

I use mplayer-encode  http://git.mplayer2.org/divverent/mplayer2.git/commit/?h=encode&id=3d6e2cfd96cf7bf413e13b75e1b278d7121020fa
And found same issue.
With -noconsolecontrols mplayer works fine. Maybe need to make this option default?

comment:9 Changed 2 years ago by harklu

Here's a fix for this, that shouldn't need -noconsolecontrols anymore:  http://git.mplayer2.org/uau/mplayer2.git/commit/?id=b93ed278362185ff980e0ce8f4ab3029f8fe395f

comment:10 Changed 2 years ago by uau

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

Now leaving console controls enabled without readable stdin should only print one error message.

Note: See TracTickets for help on using tickets.