KH can pull one configured feed or discover streams from a master instance. The receiving server owns the relay configuration. Decide which model is needed before enabling either, because discovery and individual-feed authentication have different responsibilities.

Start with one feed

This excerpt belongs directly inside <icecast> on a local receiving instance. Another local test server must already provide /feed.ogg on port 8001:

xml · Code example
<relay>
  <local-mount>/relay.ogg</local-mount>
  <server>127.0.0.1</server>
  <port>8001</port>
  <mount>/feed.ogg</mount>
  <on-demand>1</on-demand>
  <retry-delay>30</retry-delay>
</relay>

Listeners use /relay.ogg on the receiving server, not the upstream path. On-demand operation can leave the upstream disconnected while no listener needs it. Test the first connection and reconnect delay instead of equating idle with broken.

Add discovery only when intended

Master relay configuration supplies the remote host/port, polling interval and relay credentials. The pinned documentation also describes a <master> block as an alternative layout. Keep the credential used to discover the stream list separate from ordinary listener credentials. KH’s reserved /admin/streams mechanism can apply a dedicated authentication policy for relaying; do not expose relay privileges as an ordinary audience login.

Understand optional redirection

The documented master/slave redirection model involves max-redirect-slaves on the master and master-redirect on the receiver. It sends new listeners an HTTP 302 to a registered receiving instance. That is a client redirect, not a transfer of an already running connection. The announced receiver hostname and port must be reachable and the actual player must follow the response correctly.

Verify both ends

First prove direct upstream playback. Connect one listener through the receiving instance and compare both servers’ logs and statistics. Test correct and wrong authentication, no-demand idle behaviour and upstream loss. Prevent cycles where instances pull one another. For alternate origin feeds within one relay, use multiple hosts and priority; do not model that as an unrelated fallback mount without considering listener placement.