This section will describe each section of the config file and is grouped into the following sections:
<limits> <clients>800</clients> <sources>2</sources> <queue-size>512000</queue-size> <max-listeners>700</max-listeners> <client-timeout>30</client-timeout> <header-timeout>15</header-timeout> <source-timeout>10</source-timeout> <burst-size>65536</burst-size> </limits>
This section contains server level settings that, in general, do not need to be changed. Only modify this section if you are know what you are doing.
<authentication> <source-password>hackme</source-password> <relay-user>relay</relay-user> <relay-password>hackme</relay-password> <admin-user>admin</admin-user> <admin-password>hackme</admin-password> </authentication>
This section contains all the users and passwords used for administration purposes or to connect sources and relays.
<directory> <yp-url-timeout>15</yp-url-timeout> <yp-url>http://dir.xiph.org/cgi-bin/yp-cgi</yp-url> </directory>
This section contains all the settings for listing a stream on any of the Icecast2 YP Directory servers. Multiple occurances of this section can be specified in order to be listed on multiple directory servers.
<hostname>localhost<hostname> <-- You can use these two if you only want a single listening socket --> <-- <port>8000</port> --> <-- <bind-address>127.0.0.1</bind-address> --> <-- You may have multiple <listen-socket> elements --> <listen-socket> <port>8000</port> <bind-address>127.0.0.1</bind-address> <shoutcast-mount>/mystream</shoutcast-mount> </listen-socket> <listen-socket> <port>8002</port> <bind-address>127.0.0.1</bind-address> <shoutcast-mount>/live</shoutcast-mount> </listen-socket> <fileserve>1</fileserve> <shoutcast-mount>/live.nsv</shoutcast-mount> <http-headers> <header name="Custom-header1" value="some-value" status="[24]*" /> <header name="Custom-header2" value="some-other-value" status="2*" /> </http-headers>
This section contains miscellaneous server settings. Note that multiple listen-socket sections may be configured in order to have icecast2 listen on multiple network interfaces. If a bind-address is not specified for a particular listen-socket, then the socket will be bound to all interfaces. Generally, you won't need to set bind-address.
One example where multiple ports are used is when shoutcast source clients are used to stream data to icecast. Shoutcast source clients use a limited protocol, they require two sequential ports. The base port acts like a normal web servre type port used for metadata updates but the second has an unusual protocol which has stream data sent to it.
The following list the options for use with a listen-socket
This optional flag will indicate that this port will operate in 'shoutcast-compatibility' mode. Due to major differences in the source client connection protocol, if you wish to use any of the shoutcast DJ tools, you will need to configure at least one socket as shoutcast-compatible. Note that when in this mode, only source clients (and specifically shoutcast source clients) will be able to attach to this port. All listeners may connect to any of the ports defined without this flag. Also, for proper Shoutcast DSP compatibility, you must define a listen socket with a port one less than the one defined as 'shoutcast-compat'. This means if you define 8001 as shoutcast-compat, then you will need to define a listen port of 8000 and it must not also be defined as shoutcast-compat. See the example config file is the distribution for more info.
The following are general server settings
The following set of tags are for compatability with the main relaease. This build allows for other changes which will be identified.
<relays-on-demand>0</relays-on-demand> <relay> <server>127.0.0.1</server> <port>8001</port> <mount>/example.ogg</mount> <local-mount>/different.ogg</local-mount> <username>joe</username> <password>soap</password> <relay-shoutcast-metadata>0</relay-shoutcast-metadata> <on-demand>0</on-demand> </relay>
The default on-demand setting for any relays created.
This section contains the server relay settings. There are two types of relays: A "Master server relay" or a "Specific Mountpoint relay." A Master server relay is only supported between icecast2 servers and is used to relays all publically available mountpoints on a remote icecast2 server. A "Specific Mountpoint relay" requests a single stream from remote server which does not have to be an icecast2 server.
A server is configured as a Master Server relay (Slave) by specifying a series of tags that identify the master. The server that is being relayed does not require any special configuration but you will usually want some sort of authentication to allow the slave to relay streams. The traditional set of tags for a slave are
<master-server>127.0.0.1</master-server> <master-server-port>8001</master-server-port> <master-update-interval>120</master-update-interval> <master-username>relay</master-username> <master-password>hackme</master-password>
In this build you can also use a syntax like
<master> <server>a.b.c.d</server> <port>8000</port> <username>joe</username> <password>hackme</password> <on-demand>true</on-demand> <interval>60</interval> </master>
Which ever way the tags are defined, a set of relays are dynamically added/removed based upon information retrieved from the master. This information is typically queried from the master at fixed intervals.
+-----+ +-----+ | | /mount3 | | /mount1 | | <------------------- | | /mount2.ogg +-----+ +-----+ /mount3 Icecast 2 Icecast 2/Shoutcast/Icecast Server 1 Server 2 (RELAY SERVER) (REMOTE SERVER) configured with <relay> settingsSpecific Mountpoint Relays can be configured to relay from an Icecast 2 server, as well as Icecast 1.x and Shoutcast. A server is configured as a Specific Mountpoint Server relay by specifying a <relay> XML chunk in the config file for each mountpoint to be relayed. The server that is being relayed does not need any special configuration.
<relay> <local-mount>/different.ogg</local-mount> <server>127.0.0.1</server> <port>8001</port> <mount>/example.ogg</mount> <http-headers> <header name="Custom-header1" value="some-value" /> <header name="Custom-header2" value="some-other-value" /> </http-headers> <host> <server>master1</server> <port>8000</port> <mount>joe</mount> <tls>yes</tls> <priority>3</priority> </host> <enable>1</enable> <username>joe</username> <password>soap</password> <relay-shoutcast-metadata>0</relay-shoutcast-metadata> <on-demand>1</on-demand> </relay>
An on-demand relay will only retrieve the stream if there are listeners connected 1=enabled, 0=disabled (default is <relays-on-demand>).
The default setting is 1 which means that the relay is active, so it connection attempts occur when they need to etc. If enable is 0 then the mountpoint name is reserved but nothing else occurs, so it is useful if a source of the relay is known to be having problems. Can be updated over HUP or via the admin pages.
The headers specified here just require the name and value elements and these are sent to the relay host when connected. The same block can be specified in the host block if you need to have different headers for different hosts, eg cookies or similar.
The host sub-blocks are unique in the kh series but are often quite useful in situations where you can switch
between feeds without affecting the connected listeners. You always have at least 1 host really even if the XML
does not show it.
The most obvious layout is one above which is where each host stipulates the details for each entry. A
priority 1 host would be tried before priority 2 etc, hosts with same priority have no requirment. Hosts that
do not state the priority use the largest +1, that way the order in the xml is maintained. The priority value has
no other significance other than the ordering of hosts.
You can shorten the listing, if you have a common theme eg 3 hosts each have icecast on port 8000 with same mountpoint
can be defined like
<relay> <local-mount>/stream</local-mount> <retry-delay>60</retry-delay> <port>8000</port> <mount>/feed</mount> <host> <server>a.b.c.d</server> </host> <host> <server>e.f.g.h</server> </host> <host> <server>s.t.u.v</server> </host> </relay>
The highest priority is tried first and if that fails for any reason then the second highest is tried and so on. If a particular feed connects but terminates after a short time then it is treated as failed so the next is tried. If all feeds have failed then a fresh retry on all is attempted after some time has elapsed (retry-delay), but if a stream has been running soem time then stops, then all are retried again. If all have been determined to of failed then any listeners are subject to fallback or being dropped.
The priority of the host ordering is determined by the priority value on the host defintition. If none are specified then the order is as listed in the XML. A priority value of 1 is the highest priority
A recent update to the relay code allowed for the restart of higher priority hosts to kick off, and if established then jumps in as the feed for the existing listeners. As always, like with fallback handling, the different streams from the hosts should have the same stream format if playback is to be maintained. While certain variances can be possible (eg differences in bitrate), the more changes to the format, the less compatability there will be with players.
A Recent feature for the relay is the ability for a connecting source client to use the same mount point as the relay and the relay feed effectively stops but allows for the source to take over, much like the previous section talks of a higher priority host taking over. The overall effect of this is that you have a different type of fallback defined.
What you have here then is a source client feed with a fallback which can be a multi-host relay. One where listeners are anchored in one place as no fallback is specfied. In a few situations people have defined streams A and B to fallback to stream C. A listener join A and at some point falls back to C but if B connects then the listener ends up on B which may not be intended. This new approach allows for A and B to be relays of C (no fallback defined) and the source for A and B connect as needed and the listeners stay where they started from.
<mount> <mount-name>/example-complex.ogg</mount-name> <username>othersource</username> <password>hackmemore</password> <max-listeners>1</max-listeners> <priority>1</priority> <http-headers> <header name="Custom-header1" value="some-value" status="[24]*" /> <header name="Custom-header2" value="some-other-value" status="2*" /> </http-headers> <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> <charset>8192</charset> <mp3-metadata-interval>8192</mp3-metadata-interval> <allow_url_ogg_metadata>1</allow_url_ogg_metadata> <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 can be appledy 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 specify certain information that can override either global/default settings or settings provided from the incoming stream.
A mount does not need to be specified for each incoming source although you may want to specify certain settings like the maximum number of listeners or a mountpoint specific username password for example. 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.
This is optional but defaults to the lowest priority. When you have multiple mount points defined then you may have multiple mount points matching a request if at least one is a pattern eg (/*.mp3). The selection was of the mount point was determined by the order in the XML which is difficult for some as the XML can be generated.
To help define a search order, we look through explicitly defined mounts (no pattern) first, then high priority patterns proceeding to lowest. mount points with no priority defined are in the lowest category, and multiple mount points of the same priority pick the last listed in the xml to match existing setups. The last one found with the highest priority is selcted
Ideally you want wide ranging patterns eg /* to be the lowest prirority, then say /*.mp3 higher than that. The priority can then be defined without a concern for the layout of the xml.
A sub-block to allow for having customized headers to be sent to listeners on this stream. The name and value elements are required to be specified, the status defaults to all return codes. This allows you to add or replace headers sent to players which may be important. You can specify CORS headers here or cookies. These headers do not have any effect on the icecast processing of the stream but can override ones from the source or some of the internally generated one like Date.
The same block defined globally is applied first and then this is applied. At the moment, duplicate headers are not provided for or to have a fixed global one which cannot be changed but that sort of thing could be made to work.
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.
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 a fallback file is now timed based on the rate of the stream or a limit that has been previously specified. You can also embed the bitrate into the filename eg <fallback-mount>/files/fallback[128].mp3<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
Various source clients send metadata in charsets other than UTF8, and fail to say which charset they are using. Here you can define an alternative charset that will convert the metadata to UTF8 for stats/web and YP updates.
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.
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
Mount sections can be appled to relays, source clients and file requests so you can apply authentication on most requests. The exception is the /admin requests as they are specially handled. Most admin based calls require either an admin user/pass combination or if specific to a stream, then the source authentication details would need to be supplied.
In this build, there is a special admin mount reserved for use with authenticating relays. Orignially, relays from slaves used the normal request to retrieve the streams but now we can use a specially reserved mount /admin/streams for allowing slave relays to connect bypassing the usual limiters such as max-listeners and at the same time use the same authentication mechanism that the slave polling would use.
By defining a <mount> block for /admin/streams, you can define an <authentication> section that the slave will use to gain acces for relaying. That authentication section can be like any other so multiple user/passwords or URL based auth can be used to validate the connection attempts.
<paths> <basedir>./</basedir> <logdir>./logs</logdir> <pidfile>./icecast.pid</pidfile> <webroot>./web</webroot> <adminroot>./admin</adminroot> <mime-types>/etc/mime.types</mime-types> <x-forwarded-for>192.168.1.254</x-forwarded-for> <ssl-certificate>./server.pem</ssl-certificate> <ssl-private-key>./key.pem</ssl-private-key> <ssl-cafile>./cacert.pem</ssl-cafile> <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 '/'.
<logging> <accesslog>access.log</accesslog> <accesslog> <name>access.log</name> </accesslog> <errorlog>error.log</errorlog> <errorlog> <name>error.log</name> <size>100M</size> </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 at least 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).
On unix based 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. The admin page allows for triggering a reloading of the config and reopening of the log files. Log files are capable of being cycled automatically, typically when they reach a certain size, but some prefer to have aan external log rotation facility where a reload is triggered after renaming the logs.
<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.