Icecast - Sep 2008 - schedule a fallback and / 2 sources streaming at 1 server ???

Dick Trump wrote:
> kosnickx wrote:
>   
>> So my question is if it is possible to schedule 
>> some sort of fallback to another mount point whenever i want to
>>     
>
> Yes.  I have a Windows installation where my live stream comes from
Simplecast with multiple mount points with the same data.
>
> At certain points in the day, I need to insert alternate material to an
individual mount point instead of the main stream provided by Simplecast.  I
wrote a separate scheduling application that launches EZstream for the one hour
inserts.  All other mount points continue to receive the main program.
>
>   
First of all thanks for your answer.
Now let's see if i got it right.
You have lets say 5 mount points, all of them playing the same stream 
(from the same client - Simplecast).
Every hour you use one of these mount points (lets say #3) to insert 
alternate stream.
So with your own application (kind of scheduler i guess) you connect a 
new client (that is EZstream) to mount point 3 (i suppose only for a few 
moments - some ads and jingles maybe).
So EZstream provides mount point 3 with new stream right?
What happens to Simplecast (it was streaming to mount point 3 too - now 
both Simplecast and EZstream stream to mount point 3)?
What happens when EZstream stops streaming to mount point 3 (while, i 
guess, Simplecast kept streaming to mount point 3)?
Once again thanks.

kosnickx wrote:
> Now let's see if i got it right.
Mostly right.
> You have lets say 5 mount points, all of them playing the same stream 
> (from the same client - Simplecast).
Yes
> Every hour you use one of these mount points (lets say #3) to insert 
> alternate stream.
> So with your own application (kind of scheduler i guess) you connect a
> new client (that is EZstream) to mount point 3 (i suppose only for a few
> moments - some ads and jingles maybe).
No.  The inserts are usually an hour long and for a given mount, only occur once
or twice a day.  This is a state-wide radio network for the blind, serving
multiple communities.  These inserts are pertinent to the local community, not
the rest of the stations in the network.
> So EZstream provides mount point 3 with new stream right?
Yes
> What happens to Simplecast (it was streaming to mount point 3 too - now
> both Simplecast and EZstream stream to mount point 3)?
Simplecast continues to encode to all mount points but is temporarily
disconnected from mount point 3 (in your example).
> What happens when EZstream stops streaming to mount point 3 (while, i 
> guess, Simplecast kept streaming to mount point 3)?
When EZstream is forced to stop by the application (necessary since by default,
it would just loop), Icecast reconnects to the primary source from Simplecast.

Here's where my application is somewhat backward from what the normal intent
of fallbacks would be.  Instead of the Simplecast mount point being the primary
one, it is configured as the fallback-mount.  The insert (temporary) mount point
is the primary mount for that destination.  So the configuration for destination
3 would look something like this:

     <mount>
        <mount-name>/MOUNTNUM3-INSERT</mount-name>
        <max-listeners>3</max-listeners>
        <fallback-mount>/MOUNTNUM3</fallback-mount>
        <fallback-override>1</fallback-override>
    </mount>

The INSERT mount is sourced by EZstream and the fallback-mount is sourced by
Simplecast.

Of course, the max-listeners tag of 3 has nothing to do with the MOUNTNUM3 but
rather allows me to connect for monitoring purposes only.

Since all of this happens on a single machine,  I can only handle one insert at
a time (one instance of EZstream).  If I ever need to schedule two inserts
simultaneously, I'll need to use a 2nd machine to handle that.

Incidentally, this same machine also runs another program on schedule that
captures segments of the stream that are live, archives them and FTP's them
to our web server for on-demand streaming.  Not too bad for an old P3 machine
donated when it was "obsolete".

-- 
Dick
dtrump1 at triadav.com

Dick Trump wrote:
> kosnickx wrote:
>   
>> Now let's see if i got it right.
>>     
>
> Mostly right.
>
>   
>> You have lets say 5 mount points, all of them playing the same stream 
>> (from the same client - Simplecast).
>>     
>
> Yes
>
>   
>> Every hour you use one of these mount points (lets say #3) to insert 
>> alternate stream.
>> So with your own application (kind of scheduler i guess) you connect a
>> new client (that is EZstream) to mount point 3 (i suppose only for a
few
>> moments - some ads and jingles maybe).
>>     
>
> No.  The inserts are usually an hour long and for a given mount, only occur
once or twice a day.  This is a state-wide radio network for the blind, serving
multiple communities.  These inserts are pertinent to the local community, not
the rest of the stations in the network.
>
>   
>> So EZstream provides mount point 3 with new stream right?
>>     
>
> Yes
>
>   
>> What happens to Simplecast (it was streaming to mount point 3 too - now
>> both Simplecast and EZstream stream to mount point 3)?
>>     
>
> Simplecast continues to encode to all mount points but is temporarily
disconnected from mount point 3 (in your example).
>
>   
>> What happens when EZstream stops streaming to mount point 3 (while, i 
>> guess, Simplecast kept streaming to mount point 3)?
>>     
>
> When EZstream is forced to stop by the application (necessary since by
default, it would just loop), Icecast reconnects to the primary source from
Simplecast.
>
> Here's where my application is somewhat backward from what the normal
intent of fallbacks would be.  Instead of the Simplecast mount point being the
primary one, it is configured as the fallback-mount.  The insert (temporary)
mount point is the primary mount for that destination.  So the configuration for
destination 3 would look something like this:
>
>      <mount>
>         <mount-name>/MOUNTNUM3-INSERT</mount-name>
>         <max-listeners>3</max-listeners>
>         <fallback-mount>/MOUNTNUM3</fallback-mount>
>         <fallback-override>1</fallback-override>
>     </mount>
>
> The INSERT mount is sourced by EZstream and the fallback-mount is sourced
by Simplecast.
>
> Of course, the max-listeners tag of 3 has nothing to do with the MOUNTNUM3
but rather allows me to connect for monitoring purposes only.
>
> Since all of this happens on a single machine,  I can only handle one
insert at a time (one instance of EZstream).  If I ever need to schedule two
inserts simultaneously, I'll need to use a 2nd machine to handle that.
>
> Incidentally, this same machine also runs another program on schedule that
captures segments of the stream that are live, archives them and FTP's them
to our web server for on-demand streaming.  Not too bad for an old P3 machine
donated when it was "obsolete".
>
>   
Thanks a lot!

kosnickx wrote:
> Well i just tried what you said and it works fine.
> But there is one thing : while falling back from one mount point to 
> another it takes about 10 to 15 seconds. Does this happen to you too? Is
> there any way to reduce this to minimum or to 0 if possible.
> Sorry for being so anoying.
Not annoying at all.  I'm happy to be able to add some of my own experience
to how useful Icecast can be.

I suspect the gap may vary with the connected client (listener).   Since there
is an interruption in the stream, the receiving software must resync.  All my
"receivers" are running mpg123 on Linux with a custom script that is
constantly looking at the received stream status.  If there is any interruption,
it will immediately kill mpg123 and restart it making the interruption as brief
as possible.  Since these receivers are all remotely located, I don't hear
them but I have never heard a complaint about it.
-- 
Dick
dtrump1 at triadav.com

Hi,

On Sun, Sep 7, 2008 at 12:30 AM, Dick Trump <dtrump1 at triadav.com>
wrote:
> kosnickx wrote:
>> But there is one thing : while falling back from one mount point to
>> another it takes about 10 to 15 seconds. Does this happen to you too?
Is
>> there any way to reduce this to minimum or to 0 if possible.
I've been wanting to advise you to give liquidsoap a try since the
beginning of this thread. Now I'm decided.

As long as you're happy with icecast-level fallbacks, it's cool, since
it does not put any constraint on your source clients. Maybe you're
tied to particular source clients for functionalities or availability
on Windows. But that solution has some limitations as you noticed: the
listeners can hear it, and the transition is not very smooth. If you
want to do better, you need to use a tool for that.

Liquidsoap [1] is a solution: it's a source client that can relay
other source clients, and manage a fallback between them, possibly
with transitions. Then liquidsoap creates the stream and sends it to
icecast, it's seamless for the listener. And in case you don't _need_
to have two separate source clients, let me precise that the fallback,
like any other operation in liquidsoap, works as well with source
clients than with internal sources such as playlists.

Feel free to ask on savonet-users at lists.sf.net if you have any questions.

Cheers,
--
David

[1] http://savonet.sf.net