Yes, mp3 shoutcast streams can be recorded this way. I've tested before.
Someone told me about using lynx --source for this one. If you want to play
it, pipe lynx's output in to mpg123. The output is mp3.
At 02:27 AM 1/8/02 -0700, you wrote:
>On Sun, 6 Jan 2002, James R. Van Zandt wrote:
>
>> You will at least have to put your recording command in parentheses
>
>The parentheses are not necessary, when only one pipeline is
>involved. You would only need this to enclose a set of command
>lines.
>
>> (so it runs as a subprocess) and follow it with an ampersand (so it
>
>Yes, the ampersand was missing, and necessary, to backgound the
>process; "$!" is only meaningful after that.
>
>> runs in the background, and control returns to the parent process
>> immediately). So, I would write it this way:
>>
>> #!/bin/sh
>> (lynx --source `cat /tmp/streamurl` >path_to_file.mp3)&
>> PROC=$!
>
>The "at" command syntax requires the commands to be taken from a
>file, or fed via the standard input, like my example with the
>"here" document, or, to correct the line above:
>
>echo "kill $PROC" | at $END
>
>> However, I have not tested this. In particular, I'm not sure the at
>> job will inherit the environment so that $end is defined.
>
>Yes, it does inherit the environment (with a couple of minor
>exceptions like TERM -- see the man page). So the "`cat
>/tmp/streamurl`" and temp file could be eliminated, and the URL
>could simply be passed by an environmental variable (make sure
>you export all the variables "at" will need, though, in the
>starting script):
>
>export STREAMURL
>
>Can you really capture streaming audio with the -source option to
>lynx? I've never tried this, but it would really solve some
>problems for me: what format would the result be in? Would I
>need to pipe it through sox?
>
>See the script corrections below, too, for your original example.
>
>> >From: Brent Harding <bharding@doorpi.net>
>> >Date: Sat, 05 Jan 2002 21:55:28 -0600
>
>> >Cool, that's what using at was for. I never knew how to get the process of
>> >a script in to a variable with $!, better than using killall. Is there any
>> >way, to for say,
>> >Read a time as the prompt for some script which is in a variable, use
it to
>> >schedule up an at job for start and end this way?
>
>> >For example:
>#!/bin/sh
>echo "Script to record broadcast or webcast material"
>
>echo -e "Enter the time to start recording (default is now): \c"
>read START
># Do not remove the next line -- not just a comment:
>: set default start time, for testing -- ${START:=now}, if not set already.
>
>echo -e "Enter the time to stop recording: (default is one hour): \c"
>read END
># : set default stop time, for testing: ${END:=now+5minutes}if not set
already
>: set default stop time: ${END:=now+1hour}if not set already
>
>echo -e "Enter the stream url to be recorded: \c"
>read STREAMURL
>export STREAMURL END
>
>read OUT_FILE\?"Enter the output filename with no suffix
> (suffix will be added -- default is captured_broadcast): "
>: set default filename to ${OUT_FILE:=captured_broadcast} if not already set.
>
># old wrong: # at $START /usr/local/bin/record
>at "$START" << End_of_here_document_marker
> # /usr/local/bin/record & # replaced:
> # Does the next line mean that the stream must be in mp3
> # format? Will it work?
> lynx --source "$STREAMURL" > ${OUT_FILE}.mp3 &
> export PROC=$!
> # And we need another "at" command within the "at" command:
> at "$END" << End_Of_File_Mark
> # Prevent loss of recording with move command:
> kill $PROC && mv --backup --version-control=numbered \
> ${OUT_FILE}.mp3 ${OUT_FILE}.saved.mp3
>End_Of_File_Mark
>
> # exit "at" script at marker:
> # Marker string specified above for "here document" must start
> # at beginning of line (next line):
>End_of_here_document_marker
>
>exit
>
># Broken record script eliminated:
>> >Then in /usr/local/bin/record
>> >#!/bin/sh
>> >lynx --source `cat /tmp/streamurl` >path_to_file.mp3
>> >PROC=$!
>> >at $end kill $PROC
>> >One would probably use a date command to insure the file name won't
>> >overwrite the last episode if it's not gone yet, and clean up the temp
file
>> >created. The only real problem with it is that if someone put in (halt) in
>> >as a time, your system would go down if this is run by root. No error
>
>Never run a script with external input as root! Security hazard!
>But "at" would not accept halt as a valid time: you would just
>get an email from "at" telling you that you made a time format
>error, and no recording would be made. "at" scripts are run as
>the user that invoked them, not root. And halt wouldn't work
>anyway, even if it was in the "here document", unless you ran it
>as root, and used the root path.
>
>LCR
>
>The remaining lines are just quotation from the discussion thread:
>
>> >checking at all in this, not sure if time is a possible test to make
sure a
>> >valid time of day is used.
>> >At 04:55 PM 1/5/02 -0700, you wrote:
>> >>And you might find that the "at" command is better choice
>> >>for timing than "sleep" or cron. For example:
>> >>
>> >>mpg123 lecture.mp3 &
>> >>SOUNDPROC=$!
>> >>
>> >>at now+2hours << End_of_here_document
>> >># Or:
>> >># at 9:30pm << End_of_here_document
>> >>kill $SOUNDPROC
>> >>End_of_here_document
>> >>
>> >>On Fri, 4 Jan 2002, James R. Van Zandt wrote:
>> >>
>> >>> One way to limit the duration of a command is to run it in a
>> >>> subprocess (i.e. put the shell command in parentheses) and have the
>> >>> parent kill it. Here's an example:
>> >>>
>> >>> #!/bin/bash
>> >>> # try to send a string to the synthesizer via four different serial
>> >>> #ports
>> >>> for x in 0 1 2 3; do
>> >>> (DTK_PORT=/dev/ttyS$x
>> >>> echo "trying $DTK_PORT"
>> >>> stty sane 9600 raw -echo crtscts <$DTK_PORT &&\
>> >>> stty -echo <$DTK_PORT &&\
>> >>> stty ixon ixoff <$DTK_PORT &&\
>> >>> echo "this is /dev/t t y s $x" $'\r' >$DTK_PORT )&
>> >>> # if one of the above commands hangs, kill the process
>> >>> sleep 2; kill $! >/dev/null 2>&1
>> >>> done
>
>--
>L. C. Robinson
>reply to no_spam+munged_lcr@onewest.net.invalid
>
>People buy MicroShaft for compatibility, but get incompatibility and
>instability instead. This is award winning "innovation". Find
>out how MS holds your data hostage with "The *Lens*"; see
>"CyberSnare" at http://www.netaction.org/msoft/cybersnare.html
>
>
>
>_______________________________________________
>
>Blinux-list@redhat.com
>https://listman.redhat.com/mailman/listinfo/blinux-list
>
>