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?