On 07.12.2008,t 02:54, Pete Nesbitt wrote:
> Hi,
> I have bash based cgi script set which uses mplayer in a while loop
>hat runs as a bg process. It passes values from a form based web
> page (viaOST). I use SIGSTOP & SIGCONT for pause and resume
> functions.
>
> When I click 'resume'nd the mplayer loop is un-paused, it seems to
> wanto fast forward to where it should be in time. So if you pause it
> for one minute,hen resume, it sounds like it is on fast forward
> for
>econd or so, until it is where it would have been in the song had the
> process not been frozen. Thenverything plays normally.
>
> Here ishe relevant part of the code:
> pressing pauseuns:
> kill -s SIGSTOP `/sbin/pidof mplayer` &> /dev/null
>
> pressingesume runs:
> kill -s SIGCONT `/sbin/pidof mplayer` &> /dev/null
>
> (I haveried removing the stdout/err redirs as well)
>
> Here ishe mplayer loop. Note the bg call after 'done' putting the
>ntire loop in the background via a previous iteration of the
>cript (via a cgi call to 'play').
>
> whileead TRACK
> do
> #nipped some 'now playing' status tracking etc
>
> ${MPLAYER} -quiet ${TRACK} < /dev/null &> /dev/null
>
> #nipped some 'now playing' status tracking etc
> et TRACK_NUM=TRACK_NUM+1
> done < ${PLAY_LIST} &> /dev/null &
>
> The player needso be in the background, so I don't think there is a
> wayo pass a keystroke to a process running in the bg of a different
>hell.
>
> I caneproduce it at the cli with this, which just replicates the cgi
>OST: (then run SIGSTOP etc from a diff shell (same user))
>
> QueryString="song=%2Fdata%2Fmedia%2Fmusic%2Falbums%2FGenesis
> %2FNursery_Cryme-72_1.flac%3C%2Ftd"
>xport QueryString
> ./cm_playing-cgi.sh
>
> However, notsing the cgi, it is fine, just SIGSTOP mplayer, then
> SIGCONT (diffhell) it works as expected. (note the line wraps!)
>
> mplayer /data/media/music/albums/Genesis/Nursery_Cryme-72_1.flac
> < /dev/null &> /dev/null &
>
>
> As wild guess I would say that mplayer is not aware it is paused
>t the process level (related to being in a bg'd while-loop??), so
> when it isesumed it tries to catch up to where the system clock or
>ome timer says it should be. I'm thinking I need to tell it not to
>ync to the real time, but just carry on.
>
> Doesnyone have any ideas what causes this and how I can prevent it?
Soundsike a very easy problem. As many already said here, you should
use -input file=some.fifo for controllingour mplayer. I suspect that
theeason this didn't work for you was, that you never actually
created fifo with mkfifo. I wrote this script a few weeks ago to
launch mplayero that it is controllable remotely (via the network):
#!/bin/sh
PORT=44444
FIFO=rconmp.fifo
functionempname
{
# Generaten unlikely to be used name
dd if=/dev/random bs=16 count=1 | openssl base64 |ed -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 withID ${NCPID}
kill ${NCPID}
rm ${FIFOFILE}
Forour situation, you only need this:
#!/bin/sh
PORT=44444
FIFO=rconmp.fifo
mkfifo ${FIFO}
mplayer -input file=${FIFO} "$@"
rm ${FIFO}
(orou set input=file=some.fifo in your .mplayer/config for all
mplayerou will ever start. Of course, do not forget to mkfifo it
first)
>
> Thanks.
>ete
>
> --
>ete Nesbitt
>
> http://www.linux1.ca
> _______________________________________________
>Player-users mailing list
>Player-users at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users
