similar to: Fwd: More fallback handling

Hi, I'm the author of the patch in question. Mike emailed me to say that he was not very much convinced the run command features would be useful. He also mentioned that the implementatiton is problematic. Well, to understand the reason for the command execution, one really has to know how this patch came about. I am new to icecast, four days ago I didn't know it existed. I hooked up

On Wednesday 14 January 2004 20:46, iceuse@kezako.net wrote: > Hello, > I have a problem with icecast > a have a source+ a fallback source > when source disconnect after a network interruption, all lilsteners are > transfered to the fallback source but then, a few seconds later, source > come back and didn't get back its previous listeners. > > Is there a way to have

On Tuesday 13 January 2004 17:15, Melanie wrote: > Hi, > > On 2004.01.13 02:32 Michael Smith wrote: > > Since we've now (finally!) got 2.0 out the door, I'm now coming back to > > these > > patches - hoping to actually get the functionality incorporated. > > > > I've got a few questions, though: > > 1) Documentation: did you ever manage to

On Wednesday 21 January 2004 04:48, Melanie wrote: > On 2004.01.20 15:22 iceuse@kezako.net wrote: > > Good introduction to a new question: > > When a source is down, should we connect new listeners to the fallback > > source? > > My original patch does just that. By the way, Melanie - I forgot to tell you, but your patch (with some significant changes) is now

Hello, I have a problem with icecast a have a source+ a fallback source when source disconnect after a network interruption, all lilsteners are transfered to the fallback source but then, a few seconds later, source come back and didn't get back its previous listeners. Is there a way to have this behaviour : source disconnect => listeners transfered to fallback source reconnects =>

Hi, On 2004.01.13 02:32 Michael Smith wrote: > Since we've now (finally!) got 2.0 out the door, I'm now coming back to > these > patches - hoping to actually get the functionality incorporated. > > I've got a few questions, though: > 1) Documentation: did you ever manage to write any? The options > you added are > fairly straightforward for the most part, so

On Tuesday 02 December 2003 20:43, Melanie wrote: > Hi, > > I've split it into three patches now and also made it fit to current CVS, > with, I believe, Karl's changes for the double free bug. > > Order for the patches is: > > icecast-multilevel-fallback.patch > icecast-timewindow.patch > icecast-yp-override.patch > > As for docs: How? What format? Any

Here I go again. This is the second patch, it adds the ability to override some YP settings on the server. <yp-override>1</yp-override> If this is not set, we don't override the yp flag. <yp-public>1</yp-public> When this is set, the stream will be public or non public, according to it's content. This only works when yp-override is set. It allows to suppress

On 5/21/2020 1:10 AM, Philipp Schafft wrote: > Good morning, > > On Sat, 2020-05-16 at 12:30 -0700, Jack Elliott wrote: >> Hi, I'm pretty sure this isn't going to be possible, but I'll ask. I'd >> like to add a <stream-title> to my fallback mount so when the main >> stream mount drops and the fallback kicks in, that the connected player >>

Main source: http://radio.stalig.com:443/radio-bro-gwened-ori.ogg reencoded OGG: http://radio.stalig.com:443/radio-bro-gwened-16.ogg http://radio.stalig.com:443/radio-bro-gwened.ogg http://radio.stalig.com:443/radio-bro-gwened-64.ogg reencoded to mp3: http://radio.stalig.com:443/radio-bro-gwened.mp3 (very bad, but mp3 is here just to have some mp3 in case of the listener is under Mac OS9 or

Good afternoon, On Fri, 2020-05-22 at 05:52 -0700, Jack Elliott wrote: > On 5/21/2020 1:10 AM, Philipp Schafft wrote: > > On Sat, 2020-05-16 at 12:30 -0700, Jack Elliott wrote: > >> Hi, I'm pretty sure this isn't going to be possible, but I'll ask. I'd > >> like to add a <stream-title> to my fallback mount so when the main > >> stream

Hi, thanks in advance for any help that can be provided for this head-scratcher. I'm configuring a new server and can't get it to move listen clients to the fallback file when the source client disconnects. I probably have a misconfiguration in icecast.xml. Here is the <mount> section: <mount type="normal">

On Tuesday 02 December 2003 01:23, Melanie wrote: > Hello, > > this is the first patch, it implements some basic multilevel fallback > handling logic, the time window and the no mount option. > > New options are possible within an <mount> section: > > <fallback-override>1</fallback-override> > > This will allow a source connecting to a mount point to

Good morning, On Sat, 2020-05-16 at 12:30 -0700, Jack Elliott wrote: > Hi, I'm pretty sure this isn't going to be possible, but I'll ask. I'd > like to add a <stream-title> to my fallback mount so when the main > stream mount drops and the fallback kicks in, that the connected player > shows a different title. > > Then back again, of course. The

i have two icecast servers on the same host (logging to the same file) one is a public server that people connect to one is a backend switcher to switch what they listen to and handle fallbacks. when a source or relay times out, the public server disconnects at the same time that the backend server switches to the fallback. what is the best way to deal w/ this? increase the source timeout on the

Hello, this is the first patch, it implements some basic multilevel fallback handling logic, the time window and the no mount option. New options are possible within an <mount> section: <fallback-override>1</fallback-override> This will allow a source connecting to a mount point to steal the clients from it's fallback mount. All clients of the fallback are transferred

> > >To me it sounds like a bug; surely the fallback never needs statistics, > only the real steam because this is where listeners connect to. Well, the fallback mount is still a mount-point nonetheless. you could still use it as a "regular" mount-point even if its configured as a fallback to another. Now, as for the statistics, should we be able to help without knowing

Goedemorgen. On Sun, 2015-12-06 at 13:13 +0100, Jeroen van Oosten wrote: > Hello, > > I've come across a small problem and I'm not sure it's a bug or a > misconfiguration in icecast, so I thought I'd ask here. > > The situation: we have an automated radio station that is fed from a > dedicated virtual machine with SAM broadcaster. I set up a stream with a

We found an interesing issue that after a downed publishing point is restored, the fallback relay doesn't stop relaying. We've tried everything, but once /asf2 or /asf3 is envoked for /asf1 fallback reasons, they don't stop relaying their source streams even though the output stream /asf1 has returned to normal. Eventually we end up with /asf2 relaying indefinately with no

On Thursday 15 January 2004 11:42, Michael Smith wrote: > On Wednesday 14 January 2004 20:46, iceuse@kezako.net wrote: > > Hello, > > I have a problem with icecast > > a have a source+ a fallback source > > when source disconnect after a network interruption, all lilsteners are > > transfered to the fallback source but then, a few seconds later, source > >