On Tue, 09 Dec 2008 06:16:16 +0100 cbreak <cbreak@the-color-black.net> wrote:
Sounds like a very easy problem. As many already said here, you should use -input file=some.fifo for controlling your mplayer. I suspect that the reason this didn't work for you was, that you never actually created a fifo with mkfifo. I wrote this script a few weeks ago to launch mplayer so that it is controllable remotely (via the network):
#!/bin/sh
PORT=44444 FIFO=rconmp.fifo
function tempname { # Generate an unlikely to be used name dd if=/dev/random bs=16 count=1 | openssl base64 | sed -e "s/\///g" - e "s/=//g" }
FIFOFILE=${FIFO}.$(tempname)
mkfifo ${FIFOFILE} nc -kl ${PORT} > ${FIFOFILE} & NCPID=$! echo pause | mplayer -slave -idle -input file=${FIFOFILE} "$@" echo killing nc with PID ${NCPID} kill ${NCPID} rm ${FIFOFILE}
For your situation, you only need this:
#!/bin/sh
PORT=44444 FIFO=rconmp.fifo mkfifo ${FIFO} mplayer -input file=${FIFO} "$@" rm ${FIFO}
(or you set input=file=some.fifo in your .mplayer/config for all mplayer you will ever start. Of course, do not forget to mkfifo it first)
It appears to be a shell issue and not specific to mplayer. I have it working fine using FIFO outside of the cgi environment. Likely related to the parent scripts exiting or being rerun. Actually in the cgi setup, the call works once because I can start music by sending a playlist via FIFO, then starts, then after that mplayer works but is no longer listening to the pipe. You can not write to the pipe via script or cli at that point. So something in my cgi's env is messing up the pipe. -Pete