Apparently, on Wed, Jun 22, 2005 at 09:13:18AM -0600, Kevin Sookocheff wrote:
> Thanks for all the help,
>
> Paul hit the nail on the head. Mplayer likes an interactive shell. Changing
> the redirection of output streams helped me fix the problem:
>
> Here is my new crontab that works:
> 0 22 * * 1-5 /home/xxxxxx/scripts/radio2 >> /dev/null 2>&1
> 5 2 * * 1-5 killall -9 mplayer >> /dev/null 2>&1
>
For what it's worth, here is the script I use to "record" audio streams
----- begin script -----
#!/bin/bash
stream="$1"
outfile=$2
length=$3
mplayer -nocache -dumpaudio -dumpfile /path/to/save/to/${outfile} ${stream} &
/bin/sleep ${length}
/bin/kill -2 $!
----- end script -----
This mplayer command dumps the stream as it actually is so there is no
re-encoding step and thus no diminishing of quality of something that
is, most likely, already not high quality.
The -nocache argument to mplayer isn't required and a cache might be
helpful if your connection to the stream isn't too great.
Assuming the script is called stream_rec_cron.sh, I run it from cron like
this to "record" a show every weekday from 11:00-12:00.
0 11 * * 1-5 /path/to/stream_rec_cron.sh http://url.of.stream/ FILENAME-$(date +\%y\%m\%d\%I\%M).mp3 3600 > /dev/null 2>&1
The .mp3 extension on the filename can be changed to whatever format
the stream actually is (ogg, wmv, etc) or just leave it off altogether.
The 3600 is the duration of the recording, in seconds. There is no
killall cron line necessary because the script itself handles killing
the mplayer process (and only that mplayer process) when the duration
specified as an argument is up. If like me, you may have several
mplayers running (but paused), doing a killall could prove to be rather
inconvenient.
