From lr at pripple.de  Fri Feb 26 16:52:03 2021
From: lr at pripple.de (Lorenz Reichelt)
Date: Fri, 26 Feb 2021 17:52:03 +0100
Subject: [Icecast] fallback-override takes very long to switch back -- Is
 there a way to switch back immediately?
Message-ID: <FA490CE1-2F9F-4F86-809D-7F9747481F57@pripple.de>

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

From geoff at QuiteLikely.com  Fri Feb 26 17:40:00 2021
From: geoff at QuiteLikely.com (Geoff Shang)
Date: Fri, 26 Feb 2021 19:40:00 +0200 (IST)
Subject: [Icecast] fallback-override takes very long to switch back --
 Is there a way to switch back immediately?
In-Reply-To: <FA490CE1-2F9F-4F86-809D-7F9747481F57@pripple.de>
References: <FA490CE1-2F9F-4F86-809D-7F9747481F57@pripple.de>
Message-ID: <alpine.DEB.2.11.2102261934290.1151@debian.work>

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.



From lr at pripple.de  Sat Feb 27 10:13:26 2021
From: lr at pripple.de (Lorenz Reichelt)
Date: Sat, 27 Feb 2021 11:13:26 +0100
Subject: [Icecast] fallback-override takes very long to switch back --
 Is there a way to switch back immediately?
In-Reply-To: <alpine.DEB.2.11.2102261934290.1151@debian.work>
References: <FA490CE1-2F9F-4F86-809D-7F9747481F57@pripple.de>
 <alpine.DEB.2.11.2102261934290.1151@debian.work>
Message-ID: <ED6B68F2-ABB9-4F80-90A7-A89DB35BAE82@pripple.de>

Hi, great, thank you, Geoff!

With your hint I could make it work as I wanted it to.

As someone might come across this thread with the same question, I provide the steps I took below. 

I already thought that somehow streaming the fallback ?too fast? and thus filling up a buffer might have been the issue, however, as I am pretty new to this, your advice was very helpful: the idea of _streaming_ the fallback via ezstream on the very server that icecast is running on. (My second guess was that icecast might not be checking often enough, as there is a corresponding option for relay streams, however, this obviously wasn?t the issue in my case.)

Thanks again,
Lorenz

The steps I took on my Ubuntu server:

1. "apt install ezstream"

2. Write a very simple ezstream.xml with the following contents:

<ezstream>
<servers>
<server>
<protocol>HTTP</protocol>
<hostname>127.0.0.1</hostname>
<port>8000</port>
<password>hackme</password>
</server>
</servers>
<streams>
<stream>
<mountpoint>fallback</mountpoint>
<format>MP3</format>
</stream>
</streams>
<intakes>
<intake>
<type>file</type>
<filename>/path/to/fallback.mp3</filename>
</intake>
</intakes>
</ezstream>

3. Update your icecast.xml like this:

<limits>
<sources>10</sources> <---- increase this value ? at least I ran into problems of not being able to connect with the live stream source with the default limit to 2 ---->
<-- ? -->
</limits>
<-- ? -->
<mount type="normal">
<mount-name>/live</mount-name>
<fallback-mount>/fallback</fallback-mount>
<fallback-override>1</fallback-override>
<fallback-when-full>1</fallback-when-full>
<intro>/live_intro.mp3</intro>
</mount>
<mount type="normal">
<mount-name>/fallback</mount-name>
<fallback-mount>/absolute_fallback.mp3</fallback-mount>  <---- I chose a different track here so I can tell if ezstream is working or not ---->
<fallback-override>1</fallback-override>
<fallback-when-full>1</fallback-when-full>
<intro>/fallback_intro.mp3</intro>
</mount>

4. Add "ezstream -c path/to/ezstream.xml" as a service and start it (I had to write my own ezstream.service and install it via systemctl, but I?m not sure if I am following best practice with it, so I don?t provide it here)

5. When you restart the icecast service, restart the ezstream service, too (some time later) ? else, for me, it stops working ? of course, there might be better/best practice solutions for that

From ervin.bizjak at gmail.com  Sat Feb 27 11:02:15 2021
From: ervin.bizjak at gmail.com (Ervin Bizjak)
Date: Sat, 27 Feb 2021 12:02:15 +0100
Subject: [Icecast] Icecast version
Message-ID: <CABDatAT7ugoMAVGevX3ijc83nRCLxZdMb_BiDMPW=-=4J+G7dw@mail.gmail.com>

Helo,

I looked at Icecast.org and the last version is 2.4.4.

Somebody uses 2.4.99.1. What is this version? See attachment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20210227/61b7fbba/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icecast.jpg
Type: image/jpeg
Size: 15647 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20210227/61b7fbba/attachment.jpg>

From contact+dev at gilouweb.com  Sat Feb 27 17:18:23 2021
From: contact+dev at gilouweb.com (Gilou)
Date: Sat, 27 Feb 2021 18:18:23 +0100
Subject: [Icecast] Icecast version
In-Reply-To: <CABDatAT7ugoMAVGevX3ijc83nRCLxZdMb_BiDMPW=-=4J+G7dw@mail.gmail.com>
References: <CABDatAT7ugoMAVGevX3ijc83nRCLxZdMb_BiDMPW=-=4J+G7dw@mail.gmail.com>
Message-ID: <841f1b31-af6b-4c2f-edc0-8b87bf467e63@gilouweb.com>

Le 27/02/2021 ? 12:02, Ervin Bizjak a ?crit?:
> Helo,
> 
> I looked at Icecast.org and the last version is 2.4.4.
> 
> Somebody uses 2.4.99.1. What is this version? See attachment.

It is not "a version", that's what icecast gives as a version when it's
compiled from the sources!

Gilles



From jordan at coolmic.net  Sun Feb 28 00:34:48 2021
From: jordan at coolmic.net (Jordan Erickson)
Date: Sat, 27 Feb 2021 16:34:48 -0800
Subject: [Icecast] Icecast version
In-Reply-To: <841f1b31-af6b-4c2f-edc0-8b87bf467e63@gilouweb.com>
References: <CABDatAT7ugoMAVGevX3ijc83nRCLxZdMb_BiDMPW=-=4J+G7dw@mail.gmail.com>
 <841f1b31-af6b-4c2f-edc0-8b87bf467e63@gilouweb.com>
Message-ID: <e83c8b62-f102-000c-3521-d3b7256ed18d@coolmic.net>

More specifically, it's the git branch/beta located here:

https://gitlab.xiph.org/xiph/icecast-server/-/tree/release-2.4.99.1


Cheers,
Jordan Erickson

---
On 2/27/21 9:18 AM, Gilou wrote:
> Le 27/02/2021 ? 12:02, Ervin Bizjak a ?crit?:
>> Helo,
>>
>> I looked at Icecast.org and the last version is 2.4.4.
>>
>> Somebody uses 2.4.99.1. What is this version? See attachment.
> 
> It is not "a version", that's what icecast gives as a version when it's
> compiled from the sources!
> 
> Gilles
> 
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
> 


From alfredovillena13 at gmail.com  Sun Feb 28 11:42:18 2021
From: alfredovillena13 at gmail.com (Alfre Villena)
Date: Sun, 28 Feb 2021 12:42:18 +0100
Subject: [Icecast] Publicar
Message-ID: <CABGgmiDYepFDQk=vC+BE6xOe_JdCkhethoqXwmDAmfsNAwLR1w@mail.gmail.com>

Quieropublicar en ice cast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20210228/46b37a96/attachment.htm>

From robinstl68 at icloud.com  Sun Feb 28 17:22:21 2021
From: robinstl68 at icloud.com (Robert Winkelmann)
Date: Sun, 28 Feb 2021 11:22:21 -0600
Subject: [Icecast] Icecast partial crash
Message-ID: <487a6f1b-a5ad-8e82-7050-068a8f072757@icloud.com>

This is the most bizarre thing I've ever seen. Running Ice 2.4.4 on 
Ubuntu 20. Server is set up for both SSL and non SSL ports and runs 
normally for days to weeks on end. All of a sudden without much warning 
the server goes unresponsive and will not accept new connections however 
all my relays connected to this server stay running and connected. 
Attempting to connect to any of the ports loads nothing.

The only error I see in the logs appears over and over again once it 
reaches this point

[2021-02-28? 01:08:24] INFO fserve/fserve_client_create checking for 
file /.xspf (/usr/share/icecast2/web/.xspf)
[2021-02-28? 01:11:09] INFO fserve/fserve_client_create checking for 
file /.xspf (/usr/share/icecast2/web/.xspf)
[2021-02-28? 01:22:54] INFO fserve/fserve_client_create checking for 
file /.xspf (/usr/share/icecast2/web/.xspf)

And while it would make no sense for this to affect the other I also 
notice this in the error logs however it happens quite a bit and could 
either be SAM broadcaster being a pest with the password or I have 
something else hitting for data with the wrong password but this happens 
far outside of the timeframe when the lockup happens. Restart the server 
immediately clears this up however what's odd is the slave servers stay 
connected and operational. The main error matches identically when the 
server stops responding. None of the other five slave servers have the 
same issue.

[2021-02-27? 23:59:56] INFO admin/admin_handle_request Bad or missing 
password on admin command request (command: stats.xml)

Ideas?