Last time, we wrote a post about how to make your own internet broadcast with idjc under blackPanther OS. Today, we will show you how to send the radio stream from IDJC by using Icecast2 server. To install Icecast2, just simply run
# installing icecast2
Start your favorite package manager (default: KPackageKit) and search of the icecast name in the search bar. Select it and install to the system.
Minimal configuration of Icecast2 server:
fterwards we must edit /etc/icecast2/icecast.xml. Most default values should work fine for now, but you should change the passwords in the<authentication>…</authentication> section. The source-password is the password that IDJC (or Ices2 or another broadcast application) will later on use to connect to Icecast2; the admin-password is the password that the admin will use in Icecast2’s web interface; we won’t use the relay-password, but anyway you should change it.
# mcedit /etc/icecast2/icecast.xml
[...] <authentication> <!-- Sources log in with username 'source' --> <source-password>password1</source-password> <!-- Relays log in username 'relay' --> <relay-password>password2</relay-password> <!-- Admin logs in with the username given below --> <admin-user>admin</admin-user> <admin-password>password3</admin-password> </authentication> [...]
That’s it already, we can now start the Icecast2 server:
# services icecast2 start
You can now direct your browser to http://192.168.0.100:8000/ (replace 192.168.0.100 with your own IP address or FQDN) and browse through the web
Icecast running on blackPanther OS
Icecast2 config details:
The source of the relay may require authentication itself, if so state the password here.
If you are relaying a Shoutcast stream, you need to specify this indicator to also relay the metadata (song titles) that is part of the Shoutcast stream (1=enabled, 0=disabled).
An on-demand relay will only retrieve the stream if there are listeners connected 1=enabled, 0=disabled (default is <relays-on-demand>).
Mount Specific Settings
<mount> <mount-name>/example-complex.ogg</mount-name> <username>othersource</username> <password>hackmemore</password> <max-listeners>1</max-listeners> <max-listener-duration>3600</max-listener-duration> <dump-file>/tmp/dump-example1.ogg</dump-file> <intro>/intro.ogg</intro> <fallback-mount>/example2.ogg</fallback-mount> <fallback-override>1</fallback-override> <fallback-when-full>1</fallback-when-full> <public>1</public> <stream-name>My audio stream</stream-name> <stream-description>My audio description</stream-description> <stream-url>http://some.place.com</stream-url> <genre>CLASSical</genre> <bitrate>64</bitrate> <type>application/ogg</type> <subtype>vorbis</subtype> <hidden>1</hidden> <burst-size>65536</burst-size> <mp3-metadata-interval>4096</mp3-metadata-interval> <authentication type="htpasswd"> <option NAME="filename" value="myauth"/> <option NAME="allow_duplicate_users" value="0"/> </authentication> <on-connect>/home/icecast/bin/source-start</on-connect> <on-disconnect>/home/icecast/bin/source-end</on-disconnect> </mount>
This section contains the settings which apply only to a specific mountpoint and applies to an incoming stream whether it is a relay or a source client. The purpose of the mount definition is to state certain information that can override either global/default settings or settings provided from the incoming stream.
A mount does not need to be stated for each incoming source although you may want to specific certain settings like the maximum number of listeners or a mountpoint specific username/password. As a general rule, only define what you need to but each mount definition needs at least the mount-name. Changes to most of these will apply across a configuration file re-read even on active streams, however some only apply when the stream starts or ends.
The name of the mount point for which these settings apply.
An optional value which will set the username that a source must use to connect using this mountpoint.
An optional value which will set the password that a source must use to connect using this mountpoint.
An optional value which will set the maximum number of listeners that can be attached to this mountpoint.
An optional value which will set the length of time a listener will stay connected to the stream. An auth component may override this.
An optional value which will set the filename which will be a dump of the stream coming through on this mountpoint.
An optional value which will specify the file those contents will be sent to new listeners when they connect but before the normal stream is sent. Make sure the format of the file specified matches the streaming format. The specified file is appended to webroot before being opened.
This optional value specifies a mountpoint that clients are automatically moved to if the source shuts down or is not streaming at the time a listener connects. Only one can be listed in each mount and should refer to another mountpoint on the same server that is streaming in the same streaming format.
If clients cannot fallback to another mountpoint, due to a missing fallback-mount or it states a mountpoint that is just not available, then those clients will be disconnected. If clients are falling back to a mountpoint and the fallback-mount is not actively streaming but defines a fallback-mount itself then those clients may be moved there instead. This multi-level fallback allows clients to cascade several mountpoints.
A fallback mount can also state a file that is located in webroot. This is useful for playing a pre-recorded file in the case of a stream going down. It will repeat until either the listener disconnects or a stream comes back available and takes the listeners back. As per usual, the file format should match the stream format, failing to do so may cause problems with playback.
Note that the fallback file is not timed so be careful if you intend to relay this. They are fine on slave streams but don`t use them on master streams, if you do then the relay will consume stream data at a faster rate and the listeners on the relay would eventually get kicked off.
When enabled, this allows a connecting source client or relay on this mountpoint to move listening clients back from the fallback mount.
When set to 1, this will cause new listeners, when the max listener count for the mountpoint has been reached, to move to the fallback mount if there is one specified.
Setting this option prevents this mountpoint from advertising on YP. The default is 0 so YP advertising can occur however you may want to prevent it here if you intend listeners to connect to a local relay instead. Deprecated option, replaced by <public>
The default setting for this is -1 indicating that it is up to the source client or relay to determine if this mountpoint should advertise. A setting of 0 will prevent any advertising and a setting of 1 will force it to advertise. If you do force advertising you may need to set other settings listed below as the YP server can refuse to advertise if there is not enough information provided.
Setting this will add the specified name to the stats (and therefore YP) for this mountpoint even if the source client/relay provide one.
Setting this will add the specified description to the stats (and therefore YP) for this mountpoint even if the source client/relay provide one.
Setting this will add the specified URL to the stats (and therefore YP) for this mountpoint even if the source client/relay provide one. The URL is generally for directing people to a website.
Setting this will add the specified genre to the stats (and therefore YP) for this mountpoint even if the source client/relay provide one. This can be anything be using certain key words can help searches in the YP directories.
Setting this will add the specified bitrate to the stats (and therefore YP) for this mountpoint even if the source client/relay provide one. This is stated in kbps.
Setting this will add the specified mime type to the stats (and therefore YP) for this mountpoint even if the source client/relay provide one. It is very unlikely that this will be needed.
Setting this will add the specified subtype to the stats (and therefore YP) for this mountpoint. The subtype is really to help the YP server to identify the components of the type. An example setting is vorbis/theora do indicate the codecs in an Ogg stream
This optional setting allows for providing a burst size which overrides the default burst size as defined in limits. The value is in bytes.
This optional setting specifies what interval, in bytes, there is between metadata updates within shoutcast compatible streams. This only applies to new listeners connecting on this mountpoint, not existing listeners falling back to this mountpoint. The default is either the hardcoded server default or the value passed from a relay.
Enable this to prevent this mount from being shown on the xsl pages. This is mainly for cases where a local relay is configured and you do not want the source of the local relay to be shown
This specifies that the named mount point will require listener authentication. Currently, we only support a file-based authentication scheme (type=htpasswd). Users and encrypted password are placed in this file (separated by a 🙂 and all requests for this mountpoint will require that a user and password be supplied for authentication purposes. These values are passed in via normal HTTP Basic Authentication means (i.e. http://user:password@stream:port/mountpoint.ogg). Users and Passwords are maintained via the web admin interface. A mountpoint configured with an authenticator will display a red key next to the mount point name on the admin screens. You can read more about listener authentication here.
State a program that is run when the source is started. It is passed a parameter which is the name of the mountpoint that is starting. The processing of the stream does not wait for the script to end. This option is not available on win32
State a program that is run when the source ends. It is passed a parameter which is the name of the mountpoint that has ended. The processing of the stream does not wait for the script to end. This option is not available on win32
<paths> <basedir>./</basedir> <logdir>./logs</logdir> <pidfile>./icecast.pid</pidfile> <webroot>./web</webroot> <adminroot>./admin</adminroot> <alias source="/foo" dest="/bar"/> </paths>
This section contains paths which are used for various things within icecast. All paths should not end in a ‘/’.
This path is used in conjunction with the chroot settings, and specified the base directory that is chrooted to when the server is started. This feature is not supported on win32.
This path specifies the base directory used for logging. Both the error.log and access.log will be created relative to this directory.
This pathname specifies the file to write at startup and to remove at normal shutdown. The file contains the process id of the icecast process. This could be read and used for sending signals icecast.
This path specifies the base directory used for all static file requests. This directory can contain all standard file types (including mp3s and ogg vorbis files). For example, if webroot is set to /var/share/icecast2, and a request for http://server:port/mp3/stuff.mp3 comes in, then the file /var/share/icecast2/mp3/stuff.mp3 will be served.
This path specifies the base directory used for all admin requests. More specifically, this is used to hold the XSLT scripts used for the web-based admin interface. The admin directory contained within the icecast distribution contains these files.
alias source=”/foo” dest=”/bar”
Aliases are used to provide a way to create multiple mountpoints that refer to the same mountpoint.
<logging> <accesslog>access.log</accesslog> <errorlog>error.log</errorlog> <playlistlog>playlist.log</playlistlog> <loglevel>4</loglevel> <-- 4 Debug, 3 Info, 2 Warn, 1 Error --> </logging>
This section contains information relating to logging within icecast. There are two logfiles currently generated by icecast, an error.log (where all log messages are placed) and an access.log (where all stream/admin/http requests are logged).
Note that on non-win32 platforms, a HUP signal can be sent to icecast in which the log files are re-opened for appending giving the ability move/remove the log files.
Into this file, all requests made to the icecast2 will be logged. This file is relative to the path specified by the <logdir> config value.
All icecast generated log messages will be written to this file. If the loglevel is set too high (Debug for instance) then this file can grow fairly large over time. Currently, there is no log-rotation implemented.
Into this file, a log of all metadata for each mountpoint will be written. The format of the logfile will most likely change over time as we narrow in on a standard format for this. Currently, the file is pipe delimited. This option is optional and can be removed entirely from the config file.
This value specifies (in Kbytes) the maxmimum size of any of the log files. When the logfile grows beyond this value, icecast will either rename it to logfile.old, or add a timestamp to the archived file (if logarchive is enabled).
If this value is set, then icecast will append a timestamp to the end of the logfile name when logsize has been reached. If disabled, then the default behavior is to rename the logfile to logfile.old (overwriting any previously saved logfiles). We disable this by default to prevent the filling up of filesystems for people who don`t care (or know) that their logs are growing.
Indicates what messages are logged by icecast. Log messages are categorized into one of 4 types, Debug, Info, Warn, and Error.
The following mapping can be used to set the appropraite value :
- loglevel = 4 – Debug, Info, Warn, Error messages are printed
- loglevel = 3 – Info, Warn, Error messages are printed
- loglevel = 2 – Warn, Error messages are printed
- loglevel = 1 – Error messages only are printed
<security> <chroot>0</chroot> <changeowner> <user>nobody</user> <group>nogroup</group> </changeowner> </security>
This section contains configuration settings that can be used to secure the icecast server by performing a chroot to a secured location. This is currently not supported on win32.
An indicator which specifies whether a chroot() will be done when the server is started. The chrooted path is specified by the <basedir> configuration value.
This section indicates the user and group that will own the icecast process when it is started. These need to be valid users on the system