Icecast - Feb 2021 - fallback-override takes very long to switch back -- Is there a way to switch back immediately?

Hi, thank you for Icecast!

I would like to be broadcasting mp3 audio for just about half an hour a day (at
the moment via a hosted service), however, listeners are usually waiting and we
have some interaction, so delay becomes an issue when it exceeds a couple of
seconds.

I like the possibility to provide a fallback mp3 in the web root that is played
if someone joins before we start to broadcast. However, as I have tried out
multiple times, the delay is far longer then. If I am already broadcasting live
or start in the seconds directly after someone joins, they get a delay of five
to ten seconds. When they have listened to the fallback mp3 for half a minute
before I go live, they receive my live audio with over a minute of delay. So,
while someone joining later is directly connected with only a couple of seconds
of delay, those already joining before have to listen to the fallback audio for
over another minute before it switches to the live mount.

They are listening to an HTML5 element player like this:

<audio controls preload="none" id="player">
<source src="https://domain.name:port/mount"
type="audio/mp3">
</audio>

With this mount configuration:

<mount type="normal">
<mount-name>/mount</mount-name>
<fallback-mount>/fallback.mp3</fallback-mount>
<fallback-override>1</fallback-override>
<fallback-when-full>1</fallback-when-full>
<intro>/intro.mp3</intro>
<hidden>1</hidden>
</mount>

Is there anything I can do about this to get those in the fallback loop switched
to the live mount immediately?

Thanks for your suggestions and for this wonderful piece of software!

Lorenz

On Fri, 26 Feb 2021, Lorenz Reichelt wrote:
> I would like to be broadcasting mp3 audio for just about half an hour a day
(at the moment via a hosted service), however, listeners are usually waiting and
we have some interaction, so delay becomes an issue when it exceeds a couple of
seconds.
>
> I like the possibility to provide a fallback mp3 in the web root that is
played if someone joins before we start to broadcast. However, as I have tried
out multiple times, the delay is far longer then. If I am already broadcasting
live or start in the seconds directly after someone joins, they get a delay of
five to ten seconds. When they have listened to the fallback mp3 for half a
minute before I go live, they receive my live audio with over a minute of delay.
So, while someone joining later is directly connected with only a couple of
seconds of delay, those already joining before have to listen to the fallback
audio for over another minute before it switches to the live mount.
Hi,

The problem is that if Icecast is streaming an MP3 internally, it will 
stream it to the client as quickly as it can.  So the listener will get 
multiple loops of the MP3 file in the time that it takes to play just one. 
It will need to play through all of these before picking up the new data 
from the live mount.

The way to get around this is to stream the fallback mount, rather than to 
have it streamed by Icecast.  You can use something like ezstream or ices 
0.x to stream to your backup mount and it can run on the same machine as 
the Icecast server.

The backup streamer will stream to Icecast at the bitrate of the file, and 
so the audio will be pushed to the listener at that same rate.  The switch 
should be pretty quick.

HTH,
Geoff.