Icecast Streaming Media Server

[DJ-Zath]

hi Karl and everyone else

I have tried searching for this, but I couldn't find somethig that explained it right...

plain and simple, what I need to do is fall back to a SECOND mount when the first one is out..

BUT

the second mount is NOT in succession to the first one.. it MUST be "OR switched" at the final mount in the chain..

example:

mount 1 (DJ input) -> mount 2 (binding relay) -> mount 3 (main out)
mount 4 (external backup relay) -> mount 3

'OR switch' mount 2, to fall back to mount 4 ...

this way, I can keep the external relay OUT of the studio input thus preventing it from interfering with the auto switchover systems

can this be done?
_________________
-DjZ-

[karlH]

I'm not entirely sure on the description here, is mount 3 supposed to be an on-demand relay?, what will listeners actually request. may be be mean that mount 3 is what listeners request which will be a relay of either mount 1 or mount 4. At the moment I think you either want main to fallback to DJ and in turn falls back to mount 4 (on-demand) or you want main to be a relay (keeping listeners there) and that relays mount 4 which is overridden by the DJ

karl.

[DJ-Zath]

hi Karl and thanks for the reply!

sorry for any confusion, I'll try to re-explain it:

first, I'll explain the mounts and their reason:

mount 4 = external relay mount, feeds music from 'mainesmixx.com'

mount 1 = remote DJ input mount

mount 2 = 'bind relay' mount, this ones needed to "bind" the mounts so that they don't 'hop around' and prevents the studio output from feeding itself (very bad condition!)

mount 3 = main output mount (studio input mount)

Now, in the 'conventional' way, one would do it as:

mount 4 -> mount 1 -> mount 2 -> mount 3 -> listeners

the problem here, however, is that "mount 4" is feeding mount 1, which shows up as an "input stream" on the studio console- although the switching system was written to handle the new input, Icecast itself treats this as another "DJ input" and I had a bad thing occur when a DJ was signing out; instead of the automatic switchover happening smoothly, the EXT RELAY started feeding music onto the DJ channel while the local playout went into "auto mode".. the result was multiple programs being mixed onto the studio console and me rushing the input faders down! (this now is another issue, as if another DJ logs in, they would be MUTED as the input faders are down!)

so, the solution is to have mount 4 "double fallback" at the main output mount.. this way it won't show up as a program source on the DJ input channels on the console.. yet be able to feed program when the studio and DJ mounts are both offline...

to do this, I need to "fall back to a fall back" in logical terms:

output B (mount 4) IF output A (mount 2) is not available AND output A (mount 2) IF output S (studio input) is not available

B > A > S = Out

I hope this explains it better!

-DjZ-
_________________
-DjZ-

[karlH]

based on your description (and I'm assuming a number of things so correct it if need be).

/mount4 as a relay from external
/mount1 as a point for DJs, fallback to /mount4
/mount2 as a local relay of /mount4 (can be on-demand). This bounces between mount4 and mount1, no fallback here.

/mount3 fallback to /mount2

you could of course use a local relay for handle the switches over mount2 and mount3 while keeping listeners in one place (think YP).


karl.

[DJ-Zath]

hi Karl!

you're close.. but I don't think you're quite understanding mount 2's purpose..

mount 4 and mount 2 are "relay" mounts ( <relay></relay> )
mount 1 is a shoutcast mount, mount 3 is an icecast mount ( <mount></mount> )

mount 2 simply "binds" everything to localhost; this seems nessesary as, without it, what happens is the console input can end up listening to the output mount.. this, of course causes an immediate feedback loop at the console. VERY BAD! I never understood this issue, and all versions- even the KH branch- has this bug.. it happens under a specific chain of events; where the DJ logs in, then out, or if the server is started/restarted with a DJ on then the studio logs in and boom.. there it is, the console is listening to ITSELF on OUTPUT mount!

mount 2 was added as a "bind" or "isolator" mount to seperate mount 3 from the other mounts... nothing listens to mount 2.. except mount 3 and that, "relays" mount 1.. this process isolates the mounts and prevents the bug, though I think it a slight whaste of resources, and complexity.. it IS nessesary for all of this to work properly.

mount 4 brings in an external feed.. you know how this mount works.

now the issue/reason re-explained

whatever mount 1 receives, the console is listening to.. if mount 1 falls-back to mount 4, then mount 4 shows up on the "DJ input" faders; this is a bad idea since I can not MUTE mount 4 separately from the DJs.. so, if the audio system kicks in and plays LOCAL programming, and the DJ logs out.. OOPS! now the DJ input is playing the RELAY alongside with the local playout! the result is a mixed program mess! the immediate fix is to MANUALLY "pull down" the faders for the DJ input.. but this defeats the point of an "automatic switchover" system; and, then the engineer has to also mind the faders when a DJ logs back in since now, they are MUTED..

so, the solution is that the "relay" has to come into the chain AFTER the console.. that means AFTER mount 1... since mount 2 is a <relay> mount, a fallback to mount 4 directive can't work there... so now comes mount 3- the main output mount.. but this mount allready "falls back" to mount 2 when the studio input feed is unavailable..

I realize, now, that, that's where you might be getting confused.. the FALLBACK is to mount 2 from mount 3, this occurs IF the studio is NOT online to manage the incoming feed- its meant as an "emergency reroute for input DJs to air" this way, if the studio loses net (being Comcast Business Net, it always does) while a DJ is on-air, they are immediately pushed to the output mount (pushed to air) instead of the missing studio section cutting the whole thing off!

get it? its ingenious!

many stations have TRIED this, and FAILED because they run into the problem where the input will end up listening to itself on the output.. but inserting a "relay to localhost" SOLVES this problem.. and everything works perfectly- like clockwork!

but, now, I need mount 3 to have TWO successive fall-backs:

example:
<fallback-mount-1>/mount 2</fallback-mount-1>
<fallback-mount-2>/mount 4</fallback-mount-2>

So, this way, if theres no studio feed AND theres no input DJ feed, then it can push the external program (an affiliate radio station) to air without said relay showing up on the DJ input faders..

[karlH]

The relay would normally look like a listener, so the fact that it follows through fallbacks is not surprising but there has been cases were ideally it would be nice to prevent that in such cases. The hack I use for slave relays does try to identify itself as a special case by using the /admin/streams?mount=/mountpoint style of request but I believe that still follows across moves to other mounts. I suppose a header could be optional for such cases.

Could you have the relay switch between the different mounts instead of trying to use this via fallback? eg