Am 07.12.2008, 02:54 Uhr, schrieb Pete Nesbitt <pete@linux1.ca>:
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?
Hi Pete, have you tried slave mode to tell mplayer nicely to pause playing instead of pulling the emergency brake and releasing it again? Greets, Kiste