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

[Reimar Döffinger]

On Sat, Aug 13, 2011 at 12:50:19PM +1000, Tim Connors wrote:
> It seems that relatively recently there has been a regression where
> the keyboard reading from /dev/stdin doesn't do appropriate error
> checking.  If /dev/stdin is redirected from /dev/null (eg, when
> mplayer is run from a cronjob), strace shows:
> 
> select(1, [0], NULL, NULL, {0, 10000})  = 1 (in [0], left {0, 9997})
> read(0, "", 256)                        = 0
> select(1, [0], NULL, NULL, {0, 10000})  = 1 (in [0], left {0, 9997})
> read(0, "", 256)                        = 0
> select(1, [0], NULL, NULL, {0, 10000})  = 1 (in [0], left {0, 9997})
> read(0, "", 256)                        = 0
> select(1, [0], NULL, NULL, {0, 10000})  = 1 (in [0], left {0, 9996})
> read(0, "", 256)                        = 0
> 
> The parent process is stuck read()ing with a return code that should
> imply EOF.  mplayer appears not to check for EOF, so just reads again
> immediately.  Fortunately, the worker process is still doing its job,
> but my poor dualcore CPU in my laptop is getting a bit warm.
> 
> (If I simply redirect /dev/stdin to a named pipe with no writer
> connected to it, then mplayer doesn't even start up because it's
> blocking on read.  So that's not a suitable workaround)

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).