[MPlayer-users] SIGCONT causes fast-forward effect

[cbreak]

On 07.12.2008, at 02:54, Pete Nesbitt wrote:

> Hi,
> I have a bash based cgi script set which uses mplayer in a while loop
> that runs as a bg process. It passes values from a form based web
> page (via POST). I use SIGSTOP & SIGCONT for pause and resume  
> functions.
>
> When I click 'resume' and the mplayer loop is un-paused, it seems to
> want to fast forward to where it should be in time. So if you pause it
> for one minute, then resume, it sounds like it is on fast forward  
> for a
> second or so, until it is where it would have been in the song had the
> process not been frozen. Then everything plays normally.
>
> Here is the relevant part of the code:
> pressing pause runs:
> kill -s SIGSTOP `/sbin/pidof mplayer` &> /dev/null
>
> pressing resume runs:
> kill -s SIGCONT `/sbin/pidof mplayer` &> /dev/null
>
> (I have tried removing the stdout/err redirs as well)
>
> Here is the mplayer loop. Note the bg call after 'done' putting the
> entire loop in the background via a previous iteration of the
> script (via a cgi call to 'play').
>
> while read TRACK
>  do
>    # snipped some 'now playing' status tracking etc
>
>   ${MPLAYER} -quiet ${TRACK} < /dev/null &> /dev/null
>
>    # snipped some 'now playing' status tracking etc
>   let TRACK_NUM=TRACK_NUM+1
>  done < ${PLAY_LIST} &> /dev/null &
>
> The player needs to be in the background, so I don't think there is a
> way to pass a keystroke to a process running in the bg of a different
> shell.
>
> I can reproduce it at the cli with this, which just replicates the cgi
> POST: (then run SIGSTOP etc from a diff shell (same user))
>
> QueryString="song=%2Fdata%2Fmedia%2Fmusic%2Falbums%2FGenesis 
> %2FNursery_Cryme-72_1.flac%3C%2Ftd"
> export QueryString
> ./cm_playing-cgi.sh
>
> However, not using the cgi, it is fine, just SIGSTOP mplayer, then
> SIGCONT (diff shell) it works as expected. (note the line wraps!)
>
> mplayer /data/media/music/albums/Genesis/Nursery_Cryme-72_1.flac
> < /dev/null &> /dev/null &
>
>
> As a wild guess I would say that mplayer is not aware it is paused
> at the process level (related to being in a bg'd while-loop??), so
> when it is resumed it tries to catch up to where the system clock or
> some timer says it should be. I'm thinking I need to tell it not to
> sync to the real time, but just carry on.
>
> Does anyone have any ideas what causes this and how I can prevent it?


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)

>
> Thanks.
> Pete
>
> -- 
> Pete Nesbitt
>
> http://www.linux1.ca
> _______________________________________________
> MPlayer-users mailing list
> MPlayer-users at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users