[MPlayer-users] SIGCONT causes fast-forward effect

[Pete Nesbitt]

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?

Thanks.
Pete

-- 
Pete Nesbitt

http://www.linux1.ca