Bug#637611: mplayer: redirected stdin from /dev/null causes 100% busy loop

[Reimar Döffinger]

Old issue and not that much new to add, but still...

On Sat, Aug 13, 2011 at 08:50:11PM +1000, Tim Connors wrote:
> On Sat, 13 Aug 2011, Reimar Döffinger wrote:
> > Behaviour is to make keyboard control of MPlayer more reliable mostly I
> > expect.
> > I think the MPlayer documentation says you must use -noconsolecontrols
> > when using MPlayer without a terminal (in particular from cron jobs).
> 
> The description in the manpage doens't cover this case (stdin being
> /dev/null rather than a command file or the file being played).
> 
> And it makes matters worse.  CPU usage is still 100%, but I can't see why.
> strace -f doesn't show it busy looping on file descriptor 0 - it's just
> reading the input file and sending stuff to X11.

Using latest SVN MPlayer:
mplayer http://80.237.155.73:80 -dumpaudio -noconsolecontrols
results in low CPU usage.
As does
mplayer http://80.237.155.73:80 -dumpaudio -nocache
(giving specific examples, because the issue will _not_ be
reproducible at all when dumping from a source that can
be read faster than MPlayer can dump - which is why
I never saw the issue when trying with a local file).

> (yes, this is a candidate for the 'useless use of cat' awards, but
> removing the cat doesn't let mplayer start, presumably because mplayer is
> trying to read its first keyboard command, but does it using a blocking
> read.  No idea why it woks with the cat process attached!  Figure that
> out:
> mplayer $args -dumpaudio -dumpfile <out.mp3> <network_stream> < /tmp/devblocker

This is not MPlayer's fault, if you run this and look at the
running processes you will see it hangs in the shell, before MPlayer
is even started.
No I have no idea why the shell (bash in my case) does that.