Raise the next Internet radio
But not simple, but more or less automated.
We will do around the clock radio with periodic broadcasts of DJs, automatic creation of low-flow and recording of ethers.
Despite the fact that the solutions used are rather trivial, the topic is intended primarily to see these trivial solutions.
To do this, we need only mpd and icecast. I will not consider their installation and general configuration, because the first is trivial, and for the second, configs examples are supplied.
We assume that you have already done it.
')
Task zero: preparation.
We will need three mount points in the iskaste. We define them:
We will need the first one for round-the-clock broadcasting with mpd, the other two for broadcasting DJs.
Objective 1: round-the-clock broadcasting with periodic DJs.
We need the listeners not to reconnect every time the broadcast starts / ends. It is very easy to do this in eiskaste: fallback-mount.
We give our config mounts in iskaste to this type:
With the help of fallback-mount, we told Iskas to give clients /mpd.ogg stream when there is no broadcast on /radio_low.ogg and /radio_high.ogg.
And the flag fallback-override allows you to return clients to this mount when you start broadcasting to it.
Very simple, isn't it?
Everything seems to be fine, but not all DJs can afford to broadcast in two streams, and this is not very convenient.
Task two: the automatic creation of low-flow.
For this we will use the same mpd, but we will write a new config for it. It will be necessary to change at least the path to the library, playlists and pid-file so that there are no conflicts between two copies of mpd. The output will need to be sent to the mount /radio-low.ogg isiskast. Now we just have to launch a new copy of mpd with this config and add the address of the high-stream radio to the playlist. Thus, the MPD, like any other client, receives either a broadcast from the main MPD or a DJ air, recodes and sends to a low stream. Problem solved.
The last task: automatic recording of the air.
Eiskast supports writing a stream to a file. Unfortunately, he does not know how to separate files himself, and therefore with each new air the old file will be overwritten. Fortunately, he is able to execute scripts at the start / end of the broadcast.
We only need to record high-flow, since DJs only broadcast to him.
Slightly correct the configuration of the iskasta:
We indicated where to record the stream and which script to execute at the end of the broadcast.
I recommend naming the file for a dump by the name of a mount point, because the mount point is passed as a parameter to the script.
It remains only to write this script:
All that the script does is move the dump file to the directory specified in $ path, naming it by the current date and name of the stream.
That's all. If the community is interested, in the next article I will tell you how to make a notification about current tracks and broadcasts using a bot in a jabber conference.
We will do around the clock radio with periodic broadcasts of DJs, automatic creation of low-flow and recording of ethers.
Despite the fact that the solutions used are rather trivial, the topic is intended primarily to see these trivial solutions.
To do this, we need only mpd and icecast. I will not consider their installation and general configuration, because the first is trivial, and for the second, configs examples are supplied.
We assume that you have already done it.
')
Task zero: preparation.
We will need three mount points in the iskaste. We define them:
<mount>
<mount-name>/mpd.ogg</mount-name>
</mount>
<mount>
<mount-name>/radio_high.ogg</mount-name>
</mount>
<mount>
<mount-name>/radio_low.ogg</mount-name>
</mount>
We will need the first one for round-the-clock broadcasting with mpd, the other two for broadcasting DJs.
Objective 1: round-the-clock broadcasting with periodic DJs.
We need the listeners not to reconnect every time the broadcast starts / ends. It is very easy to do this in eiskaste: fallback-mount.
We give our config mounts in iskaste to this type:
<mount>
<mount-name>/mpd.ogg</mount-name>
</mount>
<mount>
<mount-name>/radio_high.ogg</mount-name>
<fallback-mount>/mpd.ogg</fallback-mount>
<fallback-override>1</fallback-override>
</mount>
<mount>
<mount-name>/radio_low.ogg</mount-name>
<fallback-mount>/mpd.ogg</fallback-mount>
<fallback-override>1</fallback-override>
</mount>
With the help of fallback-mount, we told Iskas to give clients /mpd.ogg stream when there is no broadcast on /radio_low.ogg and /radio_high.ogg.
And the flag fallback-override allows you to return clients to this mount when you start broadcasting to it.
Very simple, isn't it?
Everything seems to be fine, but not all DJs can afford to broadcast in two streams, and this is not very convenient.
Task two: the automatic creation of low-flow.
For this we will use the same mpd, but we will write a new config for it. It will be necessary to change at least the path to the library, playlists and pid-file so that there are no conflicts between two copies of mpd. The output will need to be sent to the mount /radio-low.ogg isiskast. Now we just have to launch a new copy of mpd with this config and add the address of the high-stream radio to the playlist. Thus, the MPD, like any other client, receives either a broadcast from the main MPD or a DJ air, recodes and sends to a low stream. Problem solved.
The last task: automatic recording of the air.
Eiskast supports writing a stream to a file. Unfortunately, he does not know how to separate files himself, and therefore with each new air the old file will be overwritten. Fortunately, he is able to execute scripts at the start / end of the broadcast.
We only need to record high-flow, since DJs only broadcast to him.
Slightly correct the configuration of the iskasta:
<mount>
<mount-name>/mpd.ogg</mount-name>
</mount>
<mount>
<mount-name>/radio_high.ogg</mount-name>
<fallback-mount>/mpd.ogg</fallback-mount>
<fallback-override>1</fallback-override>
<dump-file>/tmp/radio_high.ogg</dump-file>
<on-disconnect>/path/to/my/script/stend.pl</on-disconnect>
</mount>
<mount>
<mount-name>/radio_low.ogg</mount-name>
<fallback-mount>/mpd.ogg</fallback-mount>
<fallback-override>1</fallback-override>
</mount>
We indicated where to record the stream and which script to execute at the end of the broadcast.
I recommend naming the file for a dump by the name of a mount point, because the mount point is passed as a parameter to the script.
It remains only to write this script:
#!/usr/bin/env perl
use strict;
use warnings;
use DateTime;
my $path="/path/to/my/archive/";
my $mn=$ARGV[0];
$mn=~s|/||;
my $dt=DateTime->now;
my $dmy = $dt->dmy('_');
my $fname=$path.$dmy."_".time()."_".$mn;
`mv /tmp/$mn $fname`;
All that the script does is move the dump file to the directory specified in $ path, naming it by the current date and name of the stream.
That's all. If the community is interested, in the next article I will tell you how to make a notification about current tracks and broadcasts using a bot in a jabber conference.
Source: https://habr.com/ru/post/97724/
All Articles