KH fallback policy can route listeners to another mount and can describe a file rate. Decide first whether listeners should move at all. A multi-host relay may be a better fit when they should remain anchored to one local mount, but that is a different policy to validate.

Map the live and backup paths

Inside an existing KH <mount>, a live-stream fallback can use:

xml · Code example
<fallback-mount>/backup.ogg</fallback-mount>
<fallback-override>1</fallback-override>
<fallback-when-full>1</fallback-when-full>

These are fragments, not a complete mount. The backup must exist and carry compatible media. fallback-override governs return when the original source becomes available; fallback-when-full adds an overflow case. Test source failure and audience overflow independently.

Treat a file as a timed media source

The KH documentation differs from older regular-Icecast descriptions by discussing timed file fallback. The pinned parser accepts a fallback block with mount and rate. For a deliberate MP3 file test, the mount fragment can be:

xml · Code example
<fallback mount="/files/backup.mp3" rate="128k"/>

This refers to your own matching file beneath the webroot. The rate is a media-rate declaration, not a guarantee about the file’s actual encoding. Confirm the real bitrate and pacing with your selected source and player; a variable-rate file needs particular care. The manual also mentions bracketed bitrate filenames, but the explicit parsed form makes the intended rate visible.

Examine shared-backup return paths

Several original mounts sharing one backup can produce return destinations that differ from an operator’s assumption. Draw the routing graph and test listener identities through it. Avoid cycles and unavailable final targets. Authentication on an original stream does not automatically make a directly requested backup private.

Record normal playback, original-source loss, backup loss, original return and full-mount behaviour. Include actual listening and source/listener statistics. A fallback URL appearing in XML does not establish that the player accepted the transition or that a relaying receiver consumed a file at the intended rate.