From marek at eclipse-streaming.co.za  Mon Sep  2 10:19:43 2024
From: marek at eclipse-streaming.co.za (Marek Dziembowski)
Date: Mon, 2 Sep 2024 10:19:43 +0000
Subject: [Icecast] Strange behaviour with admin/stats.xsl disappearing
Message-ID: <DU2PR07MB82551E6B91DB2EAB488D6DC2A9922@DU2PR07MB8255.eurprd07.prod.outlook.com>

Greetings icecasting amigos!


I?ve had an incredibly frustrating journey getting a new icecast origin server going to supplant an older machine set for retirement.

The setup is relatively simple ? a beefy Debian bookworm host running icecast as a relaying slave pulling the streamlist from an icecast2 2.4.4 ingest server, for mass distribution.
The ingest / origin server runs fine.

I opted for compiling the latest icecast-kh for the slave, but ran into issues with the host unable to fetch the master streamlist to relay. (I think due to compiling without explicitly including libcurl?)

I then got the prior icecast-kh compiled and it relayed fine, but then I ran into rather bizarre problems consistently displaying the admin/stats.xsl web interface?
I then tried with icecast2 installed from Debian dpkg, but got annoyed with ssl shortcomings, going back to latest icecast-kh - now with libcurl - and got the relaying working fine with ssl sorted.

But the same issue with the adminpages persist:

After starting the icecast service, the admin/stats.xsl displays as a webpage perfectly, as does /index.html. When trying to open a bogus path that doesn?t exist, the page with text ?The file you requested could not be found? is returned as expected.
When opening any bogus after /admin in the path eg. /admin/statserf, the <icestats> xml is returned.

All fine after startup / restart - but it doesn?t function correctly this way for very long.

After an indeterminate while the admin/stats.xsl and index pages start to return browser?s 404 not found.  (not the page with text ?The file you requested could not be found? as above)
However the icecast xml versions are returned fine.
And any bogus url ? random path will return the expected /admin/stats.xml

Nothing I do can restore the normal admin web pages until I restart the icecast service!!

And just as luck of murphy would have it ?I cant replicate the problem this morning and it seems to be working normally so far?. But why / how did icecast behave that way before ? and how to address the issue if it occurs again?
I cant just continually restart icecast and kick hundreds of listeners off every time!

Any insight / advise would be greatly appreciated!

Oh and PS: little to nothing substantial to be found in the error.log ?

Thanks!
Marek







[cid:image001.jpg at 01DAFD29.32B218F0]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20240902/6083cbbc/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 180354 bytes
Desc: image001.jpg
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20240902/6083cbbc/attachment.jpg>

From epirat07 at gmail.com  Mon Sep  2 11:31:02 2024
From: epirat07 at gmail.com (epirat07 at gmail.com)
Date: Mon, 02 Sep 2024 13:31:02 +0200
Subject: [Icecast] Strange behaviour with admin/stats.xsl disappearing
In-Reply-To: <DU2PR07MB82551E6B91DB2EAB488D6DC2A9922@DU2PR07MB8255.eurprd07.prod.outlook.com>
References: <DU2PR07MB82551E6B91DB2EAB488D6DC2A9922@DU2PR07MB8255.eurprd07.prod.outlook.com>
Message-ID: <C566FDE3-25E0-4C41-93FD-CF758E4CEBCD@gmail.com>

Hi,

On 2 Sep 2024, at 12:19, Marek Dziembowski wrote:

> Greetings icecasting amigos!
>
>
> I?ve had an incredibly frustrating journey getting a new icecast origin server going to supplant an older machine set for retirement.
>
> The setup is relatively simple ? a beefy Debian bookworm host running icecast as a relaying slave pulling the streamlist from an icecast2 2.4.4 ingest server, for mass distribution.
> The ingest / origin server runs fine.
>
> I opted for compiling the latest icecast-kh for the slave, but ran into issues with the host unable to fetch the master streamlist to relay. (I think due to compiling without explicitly including libcurl?)

This list is not for Icecast-kh related matters, at this point Icecast-kh is quite diverged from Xiphs Icecast.

If you need help with that, you should seek it elsewhere, where people are more familiar with that, not on the
Xiph Icecast support list.

>
> I then got the prior icecast-kh compiled and it relayed fine, but then I ran into rather bizarre problems consistently displaying the admin/stats.xsl web interface?
> I then tried with icecast2 installed from Debian dpkg, but got annoyed with ssl shortcomings, going back to latest icecast-kh - now with libcurl - and got the relaying working fine with ssl sorted.
>
> But the same issue with the adminpages persist:
>
> After starting the icecast service, the admin/stats.xsl displays as a webpage perfectly, as does /index.html. When trying to open a bogus path that doesn?t exist, the page with text ?The file you requested could not be found? is returned as expected.
> When opening any bogus after /admin in the path eg. /admin/statserf, the <icestats> xml is returned.
>
> All fine after startup / restart - but it doesn?t function correctly this way for very long.
>
> After an indeterminate while the admin/stats.xsl and index pages start to return browser?s 404 not found.  (not the page with text ?The file you requested could not be found? as above)
> However the icecast xml versions are returned fine.
> And any bogus url ? random path will return the expected /admin/stats.xml
>
> Nothing I do can restore the normal admin web pages until I restart the icecast service!!

Are you sure you do not have multiple things listening on the same port, possibly one for IPv4 and the
other with IPv6 or your OS set in a way that it would permit multiple listening processed on the same port?

Make sure you actually see the request for which you get the unexpected response in the Icecast access log,
if you do not, it never gets to Icecast in the first place.

>
> And just as luck of murphy would have it ?I cant replicate the problem this morning and it seems to be working normally so far?. But why / how did icecast behave that way before ? and how to address the issue if it occurs again?
> I cant just continually restart icecast and kick hundreds of listeners off every time!
>
> Any insight / advise would be greatly appreciated!
>
> Oh and PS: little to nothing substantial to be found in the error.log ?
>
> Thanks!
> Marek
>
>
>
>
>
>
>
> [cid:image001.jpg at 01DAFD29.32B218F0]
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast


From ross at stationplaylist.com  Mon Sep  2 11:22:21 2024
From: ross at stationplaylist.com (Ross Levis)
Date: Mon, 2 Sep 2024 23:22:21 +1200
Subject: [Icecast] Strange behaviour with admin/stats.xsl disappearing
In-Reply-To: <DU2PR07MB82551E6B91DB2EAB488D6DC2A9922@DU2PR07MB8255.eurprd07.prod.outlook.com>
References: <DU2PR07MB82551E6B91DB2EAB488D6DC2A9922@DU2PR07MB8255.eurprd07.prod.outlook.com>
Message-ID: <002901dafd2a$625c7090$271551b0$@com>

No one on this list can support Icecast KH unfortunately.  You will need to talk with Karl Heyes.

 

From: Icecast [mailto:icecast-bounces at xiph.org] On Behalf Of Marek Dziembowski
Sent: Monday, 2 September 2024 10:20 pm
To: Icecast streaming server user discussions
Cc: Louis De Villiers
Subject: [Icecast] Strange behaviour with admin/stats.xsl disappearing

 

Greetings icecasting amigos!

 

 

I?ve had an incredibly frustrating journey getting a new icecast origin server going to supplant an older machine set for retirement.

 

The setup is relatively simple ? a beefy Debian bookworm host running icecast as a relaying slave pulling the streamlist from an icecast2 2.4.4 ingest server, for mass distribution.

The ingest / origin server runs fine.

 

I opted for compiling the latest icecast-kh for the slave, but ran into issues with the host unable to fetch the master streamlist to relay. (I think due to compiling without explicitly including libcurl?)

 

I then got the prior icecast-kh compiled and it relayed fine, but then I ran into rather bizarre problems consistently displaying the admin/stats.xsl web interface?

I then tried with icecast2 installed from Debian dpkg, but got annoyed with ssl shortcomings, going back to latest icecast-kh - now with libcurl - and got the relaying working fine with ssl sorted.

 

But the same issue with the adminpages persist:

 

After starting the icecast service, the admin/stats.xsl displays as a webpage perfectly, as does /index.html. When trying to open a bogus path that doesn?t exist, the page with text ?The file you requested could not be found? is returned as expected.

When opening any bogus after /admin in the path eg. /admin/statserf, the <icestats> xml is returned.  

 

All fine after startup / restart - but it doesn?t function correctly this way for very long.

 

After an indeterminate while the admin/stats.xsl and index pages start to return browser?s 404 not found.  (not the page with text ?The file you requested could not be found? as above)

However the icecast xml versions are returned fine. 

And any bogus url ? random path will return the expected /admin/stats.xml

 

Nothing I do can restore the normal admin web pages until I restart the icecast service!!

 

And just as luck of murphy would have it ?I cant replicate the problem this morning and it seems to be working normally so far?. But why / how did icecast behave that way before ? and how to address the issue if it occurs again?

I cant just continually restart icecast and kick hundreds of listeners off every time!

 

Any insight / advise would be greatly appreciated!

 

Oh and PS: little to nothing substantial to be found in the error.log ?

 

Thanks!

Marek

 

                

 

 

 

 

 



 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20240902/bb7df26d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 20517 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20240902/bb7df26d/attachment.jpg>

From marek at eclipse-streaming.co.za  Mon Sep  2 19:55:01 2024
From: marek at eclipse-streaming.co.za (Marek Dziembowski)
Date: Mon, 2 Sep 2024 19:55:01 +0000
Subject: [Icecast] Strange behaviour with admin/stats.xsl disappearing
In-Reply-To: <C566FDE3-25E0-4C41-93FD-CF758E4CEBCD@gmail.com>
References: <DU2PR07MB82551E6B91DB2EAB488D6DC2A9922@DU2PR07MB8255.eurprd07.prod.outlook.com>
 <C566FDE3-25E0-4C41-93FD-CF758E4CEBCD@gmail.com>
Message-ID: <DU2PR07MB82556254D9033F83A8AB0E70A9922@DU2PR07MB8255.eurprd07.prod.outlook.com>

Greetings with apologies for posting on icecast-kh!  I wasn?t aware about this until now. 

> Are you sure you do not have multiple things listening on the same port, possibly one for IPv4 and the other with IPv6 or your OS set in a way that it would permit multiple listening processed on the same port?
Yes there's only iceast (kh) listening exclusively on its own ip.

> Make sure you actually see the request for which you get the unexpected response in the Icecast access log, if you do not, it never gets to Icecast in the first place.
Thanks will do so!

I've subsequently found these entries in the kern.log:
TCP: request_sock_TCP: Possible SYN flooding on port 8000. Sending cookies.  Check SNMP counters.
Oopsie~! That looks like a DDOS of sorts... and jeepers I have lots to learn still...

BTW - I've not been able to find a list of differences between iceast2 & iceacast-kh yet.
My preference would be to use icecast2 as it's available to Debian dpkg, yet I'm not sure how to go about enabling full ssl support using the chained pem cert that's working fine with icecast-kh.
Can you perhaps point me to a reference describing how to use ssl with icecast2 please?

Is icecast2 more stable than icecast-kh - or what are the advantages of using icecast2 over icecast-kh?

My sincere apologies if this is a tired out question....

I just want things to run smoothly with max stability and enjoy the peace of mind that brings! ?

Appreciate your response with gratitude. 

Marek

-----Original Message-----
From: Icecast <icecast-bounces at xiph.org> On Behalf Of epirat07 at gmail.com
Sent: Monday, September 2, 2024 1:31 PM
To: Icecast streaming server user discussions <icecast at xiph.org>
Subject: Re: [Icecast] Strange behaviour with admin/stats.xsl disappearing

Hi,

On 2 Sep 2024, at 12:19, Marek Dziembowski wrote:

> Greetings icecasting amigos!
>
>
> I?ve had an incredibly frustrating journey getting a new icecast origin server going to supplant an older machine set for retirement.
>
> The setup is relatively simple ? a beefy Debian bookworm host running icecast as a relaying slave pulling the streamlist from an icecast2 2.4.4 ingest server, for mass distribution.
> The ingest / origin server runs fine.
>
> I opted for compiling the latest icecast-kh for the slave, but ran 
> into issues with the host unable to fetch the master streamlist to 
> relay. (I think due to compiling without explicitly including 
> libcurl?)

This list is not for Icecast-kh related matters, at this point Icecast-kh is quite diverged from Xiphs Icecast.

If you need help with that, you should seek it elsewhere, where people are more familiar with that, not on the Xiph Icecast support list.

>
> I then got the prior icecast-kh compiled and it relayed fine, but then 
> I ran into rather bizarre problems consistently displaying the admin/stats.xsl web interface? I then tried with icecast2 installed from Debian dpkg, but got annoyed with ssl shortcomings, going back to latest icecast-kh - now with libcurl - and got the relaying working fine with ssl sorted.
>
> But the same issue with the adminpages persist:
>
> After starting the icecast service, the admin/stats.xsl displays as a webpage perfectly, as does /index.html. When trying to open a bogus path that doesn?t exist, the page with text ?The file you requested could not be found? is returned as expected.
> When opening any bogus after /admin in the path eg. /admin/statserf, the <icestats> xml is returned.
>
> All fine after startup / restart - but it doesn?t function correctly this way for very long.
>
> After an indeterminate while the admin/stats.xsl and index pages start 
> to return browser?s 404 not found.  (not the page with text ?The file you requested could not be found? as above) However the icecast xml versions are returned fine.
> And any bogus url ? random path will return the expected 
> /admin/stats.xml
>
> Nothing I do can restore the normal admin web pages until I restart the icecast service!!

Are you sure you do not have multiple things listening on the same port, possibly one for IPv4 and the other with IPv6 or your OS set in a way that it would permit multiple listening processed on the same port?

Make sure you actually see the request for which you get the unexpected response in the Icecast access log, if you do not, it never gets to Icecast in the first place.

>
> And just as luck of murphy would have it ?I cant replicate the problem this morning and it seems to be working normally so far?. But why / how did icecast behave that way before ? and how to address the issue if it occurs again?
> I cant just continually restart icecast and kick hundreds of listeners off every time!
>
> Any insight / advise would be greatly appreciated!
>
> Oh and PS: little to nothing substantial to be found in the error.log 
> ?
>
> Thanks!
> Marek
>
>
>
>
>
>
>
> [cid:image001.jpg at 01DAFD29.32B218F0]
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
_______________________________________________
Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast

From sm at noisynotes.com  Fri Sep  6 18:07:38 2024
From: sm at noisynotes.com (Steve Matzura)
Date: Fri, 6 Sep 2024 14:07:38 -0400
Subject: [Icecast] Building EZStream
Message-ID: <479ca613-0f4c-442a-80ef-6396f25cefd0@noisynotes.com>

After installing some dependencies, some of which had dependencies of 
their own, I'm now attempting to configure EZStream for building. One of 
those dependencies is libtag_c, presumably contained in the LibTag 
package from 
https://www.linuxfromscratch.org/blfs/view/stable-systemd/multimedia/taglib.html 
- is this correct?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20240906/0a0c5fd8/attachment.htm>

From epirat07 at gmail.com  Fri Sep  6 19:49:27 2024
From: epirat07 at gmail.com (epirat07 at gmail.com)
Date: Fri, 06 Sep 2024 21:49:27 +0200
Subject: [Icecast] Building EZStream
In-Reply-To: <479ca613-0f4c-442a-80ef-6396f25cefd0@noisynotes.com>
References: <479ca613-0f4c-442a-80ef-6396f25cefd0@noisynotes.com>
Message-ID: <FC4BEB7E-B6B0-4FF9-AB49-0828D53441DF@gmail.com>

On 6 Sep 2024, at 20:07, Steve Matzura wrote:

> After installing some dependencies, some of which had dependencies of their own, I'm now attempting to configure EZStream for building. One of those dependencies is libtag_c, presumably contained in the LibTag package from https://www.linuxfromscratch.org/blfs/view/stable-systemd/multimedia/taglib.html - is this correct?

Yes, that?s TagLib (https://taglib.org)

> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast


From sm at noisynotes.com  Thu Sep 19 20:08:25 2024
From: sm at noisynotes.com (Steve Matzura)
Date: Thu, 19 Sep 2024 16:08:25 -0400
Subject: [Icecast] Strange behavior in Icecast 2.44 startup
Message-ID: <fd5a3d1a-fce4-4df3-ac83-9a5bce6eb478@noisynotes.com>

I have a script that starts Icecast, waits a couple seconds, then starts 
ices. When I installed it all on Ubuntu 20.04, it just worked. Well, it 
still works now, but with a wrinkle. If I execute:


/etc/init.d/icecast2 start


I get:


Starting icecast2 (via systemctl): icecast2.service==== AUTHENTICATING 
FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to start 'icecast2.service'.
Multiple identities can be used for authentication:
 ?1.? Ubuntu (ubuntu)
 ?2.? ,,, (tgvpadmin)
 ?3.? Jackie McBride,,, (abletec)
Choose identity to authenticate as (1-3):


I absolutely did not set this up, nor have I ever seen this kind of 
behavior with Icecast before now. How did it get this way, and how can I 
undo this behavior? Particularly, I'd like tgvpadmin to be able to be 
the only one (except root, of course) to be able to start it.


TIA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20240919/24ef6010/attachment.htm>

From epirat07 at gmail.com  Thu Sep 19 20:32:50 2024
From: epirat07 at gmail.com (epirat07 at gmail.com)
Date: Thu, 19 Sep 2024 22:32:50 +0200
Subject: [Icecast] Strange behavior in Icecast 2.44 startup
In-Reply-To: <fd5a3d1a-fce4-4df3-ac83-9a5bce6eb478@noisynotes.com>
References: <fd5a3d1a-fce4-4df3-ac83-9a5bce6eb478@noisynotes.com>
Message-ID: <CB1433D2-80B3-427D-B808-C1A8001D376D@gmail.com>



On 19 Sep 2024, at 22:08, Steve Matzura wrote:

> I have a script that starts Icecast, waits a couple seconds, then starts ices. When I installed it all on Ubuntu 20.04, it just worked. Well, it still works now, but with a wrinkle. If I execute:
>
>
> /etc/init.d/icecast2 start
>

Hi, as far as I understand ?/etc/init.d/icecast2 start? on your system just dispatches to systemctl so
would be the same as systemctl start icecast2

>
> I get:
>
>
> Starting icecast2 (via systemctl): icecast2.service==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
> Authentication is required to start 'icecast2.service'.
> Multiple identities can be used for authentication:
> ?1.? Ubuntu (ubuntu)
> ?2.? ,,, (tgvpadmin)
> ?3.? Jackie McBride,,, (abletec)
> Choose identity to authenticate as (1-3):
>
>

The prompt means authentication is needed to run the command, hence you are asked to provide it.

This has nothing to do with Icecast itself but with your distribution and service management.

> I absolutely did not set this up, nor have I ever seen this kind of behavior with Icecast before now. How did it get this way, and how can I undo this behavior? Particularly, I'd like tgvpadmin to be able to be the only one (except root, of course) to be able to start it.
>
>
> TIA
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast


From sm at noisynotes.com  Thu Sep 19 21:04:00 2024
From: sm at noisynotes.com (Steve Matzura)
Date: Thu, 19 Sep 2024 17:04:00 -0400
Subject: [Icecast] Strange behavior in Icecast 2.44 startup
In-Reply-To: <CB1433D2-80B3-427D-B808-C1A8001D376D@gmail.com>
References: <fd5a3d1a-fce4-4df3-ac83-9a5bce6eb478@noisynotes.com>
 <CB1433D2-80B3-427D-B808-C1A8001D376D@gmail.com>
Message-ID: <e28096ba-925f-4726-a146-39cc245d9830@noisynotes.com>

I solved it by enabling the icecast2 service. I got this:


icecast2.service is not a native service, redirecting to 
systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable icecast2On 
9/19/2024 4:32 PM, epirat07 at gmail.com wrote:

> Works just fine now. The background process starts at boot time just as I want.

> On 19 Sep 2024, at 22:08, Steve Matzura wrote:
>
>> I have a script that starts Icecast, waits a couple seconds, then starts ices. When I installed it all on Ubuntu 20.04, it just worked. Well, it still works now, but with a wrinkle. If I execute:
>>
>>
>> /etc/init.d/icecast2 start
>>
> Hi, as far as I understand ?/etc/init.d/icecast2 start? on your system just dispatches to systemctl so
> would be the same as systemctl start icecast2
>
>> I get:
>>
>>
>> Starting icecast2 (via systemctl): icecast2.service==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
>> Authentication is required to start 'icecast2.service'.
>> Multiple identities can be used for authentication:
>>  ?1.? Ubuntu (ubuntu)
>>  ?2.? ,,, (tgvpadmin)
>>  ?3.? Jackie McBride,,, (abletec)
>> Choose identity to authenticate as (1-3):
>>
>>
> The prompt means authentication is needed to run the command, hence you are asked to provide it.
>
> This has nothing to do with Icecast itself but with your distribution and service management.
>
>> I absolutely did not set this up, nor have I ever seen this kind of behavior with Icecast before now. How did it get this way, and how can I undo this behavior? Particularly, I'd like tgvpadmin to be able to be the only one (except root, of course) to be able to start it.
>>
>>
>> TIA
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20240919/889f5c73/attachment.htm>

From sm at noisynotes.com  Thu Sep 19 22:14:56 2024
From: sm at noisynotes.com (Steve Matzura)
Date: Thu, 19 Sep 2024 18:14:56 -0400
Subject: [Icecast] EZstream Stream Bit Rate Question
Message-ID: <bf948898-78a2-4646-b62f-8b9438f0e07f@noisynotes.com>

In /usr/share/doc/ezstream/examples/ezstream-full.xml there is a 
directive call stream_bitrate:


<stream_bitrate>16</stream_bitrate>


The example file is for Ogg Vorbis, so what does "16" mean? For MP3 
files, I want to indicate 128kbps. DO I just substitute the 16 with 128? 
I haven't found anything in available documentation to direct me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20240919/2e66305a/attachment.htm>

From sm at noisynotes.com  Thu Sep 19 22:18:45 2024
From: sm at noisynotes.com (Steve Matzura)
Date: Thu, 19 Sep 2024 18:18:45 -0400
Subject: [Icecast] One Last EZstream Problem
Message-ID: <48176e42-69fa-4826-9144-60340a1323ae@noisynotes.com>

I'm noticing that when a streamed program file ends and the next one 
begins, sometimes the next streamed file will play for a second at 
double-speed, and if the previous file doesn't run to the full time for 
which it is scheduled, the stream that's relayed from the backup stream 
to the main one sometimes plays at half speed. I've had this happen 
before, but it somehow worked itself out. It now happens regularly, 
almost predictably on my new server. Did I forget to include something 
in my XML file--i.e., is the Icecast server getting confused about 
declared bitrates or something when files change?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20240919/76ddcef2/attachment.htm>

From sm at noisynotes.com  Fri Sep 20 00:06:03 2024
From: sm at noisynotes.com (Steve Matzura)
Date: Thu, 19 Sep 2024 20:06:03 -0400
Subject: [Icecast] EZstream XML that used to work
Message-ID: <9a76c2fe-f312-49e8-9578-bf759e27bc01@noisynotes.com>

This is about as simple as it can get. It worked earlier today. I added 
a couple lines, like sample rate and channels, it stopped working so I 
took them out, and now when I run it through /usr/bin/ezstream with the 
'-c' option, I get:


ezstream[5609]: ezstream/shout.xml: world readable??? # that's normal
ezstream[5609]: stream: default: no configuration


Here's the XML, with passwords hidden:


<?xml version="1.0" encoding="UTF-8"?>

<ezstream>

 ? <servers>

 ??? <server>
 ????? <hostname>127.0.0.1</hostname>
 ????? <password>****</password>
 ??? </server>

 ? </servers>

 ? <streams>

 ??? <stream>
 ????? <mountpoint>/broadband</mountpoint>
 ????? <format>MP3</format>
 ????? <name>ShoutOut Radio with Andy Shilton? and Steffi Barnett</name>
 ??? </stream>

 ? </streams>

 ? <intakes>

 ??? <intake>
<filename>/home/tgvpadmin/ezstream/shout.m3u</filename>
 ????? <stream_once>Yes</stream_once>
 ??? </intake>

 ? </intakes>

</ezstream>


The problem seems to be with the <name> XML directive. I thought that if 
it is added to the <server> block, the name of the stream could be 
displayed in a player. I think the problem comes up if the contents of 
the server name in that directive is more than one word--i.e., contains 
spaces. I removed it, and the player again shows "no name" where I would 
expect to see one. How then does this work? I want to display my station 
name in this name field like I could with an older version of ezstream.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20240919/6a8dd8b6/attachment.htm>

From geoff at QuiteLikely.com  Fri Sep 20 15:41:44 2024
From: geoff at QuiteLikely.com (Geoff Shang)
Date: Fri, 20 Sep 2024 18:41:44 +0300 (IDT)
Subject: [Icecast] EZstream XML that used to work
In-Reply-To: <9a76c2fe-f312-49e8-9578-bf759e27bc01@noisynotes.com>
References: <9a76c2fe-f312-49e8-9578-bf759e27bc01@noisynotes.com>
Message-ID: <7d7f6872-940b-5648-af9e-012ab539ee6a@QuiteLikely.com>

Hey Steve,

On Thu, 19 Sep 2024, Steve Matzura wrote:

> The problem seems to be with the <name> XML directive. I thought that if it 
> is added to the <server> block, the name of the stream could be displayed in 
> a player. I think the problem comes up if the contents of the server name in 
> that directive is more than one word--i.e., contains spaces. I removed it, 
> and the player again shows "no name" where I would expect to see one. How 
> then does this work? I want to display my station name in this name field 
> like I could with an older version of ezstream.

first of all, this looks like it needs to be within a <stream> tag inside 
a <streams> tag.

The format of the config file has changed a lot since the early days. 
There is a program called ezstream-cfgmigrate which may help if you still 
have your original config file.

>From the ezstream-full.xml file that's in the doc/examples directory of 
version 1.0.2:

   <!--
     Stream configuration
     -->
   <streams>
     <stream>
       <!--
         Identifying name (default: "default")

         NB: Only the "default" stream is supported at this point.
         -->
       <!-- <name>default</name> -->

This seems to indicate that the purpose of this parameter has changed 
(it's been a *very* long time since I looked at this).

It also seems that the default value is "default", which is also the only 
currently supported value.  This would explain the above error message - 
there is no stream labeled "default".

So you can omit this parameter entirely.

What I think you want is <stream_name> which is also in the <stream> 
section.  From further down the same file:

       <!-- Various other informational settings -->
       <stream_name>Test Stream</stream_name>
       <stream_url>http://localhost:8000/</stream_url>
       <stream_genre>Beeps</stream_genre>
       <stream_description>Test tones and noise</stream_description>
       <stream_quality>1.5</stream_quality>
       <stream_bitrate>16</stream_bitrate>
       <stream_samplerate>44100</stream_samplerate>
       <stream_channels>2</stream_channels>
     </stream>
   </streams>

HTH,
Geoff.



From geoff at QuiteLikely.com  Fri Sep 20 15:44:58 2024
From: geoff at QuiteLikely.com (Geoff Shang)
Date: Fri, 20 Sep 2024 18:44:58 +0300 (IDT)
Subject: [Icecast] EZstream Stream Bit Rate Question
In-Reply-To: <bf948898-78a2-4646-b62f-8b9438f0e07f@noisynotes.com>
References: <bf948898-78a2-4646-b62f-8b9438f0e07f@noisynotes.com>
Message-ID: <a91e6271-e50e-d3f0-c8b8-4668ec3eac69@QuiteLikely.com>

On Thu, 19 Sep 2024, Steve Matzura wrote:

> In /usr/share/doc/ezstream/examples/ezstream-full.xml there is a directive 
> call stream_bitrate:
>
>
> <stream_bitrate>16</stream_bitrate>
>
>
> The example file is for Ogg Vorbis, so what does "16" mean? For MP3 files, I 
> want to indicate 128kbps. DO I just substitute the 16 with 128? I haven't 
> found anything in available documentation to direct me.

I belive so, yes.

My reading of this is that these are informational fields which are used 
in stream listings (i.e. they don't actually make a technical difference, 
they only define what is shown in the stream listing).

HTH,
Geoff.



From geoff at QuiteLikely.com  Fri Sep 20 16:02:26 2024
From: geoff at QuiteLikely.com (Geoff Shang)
Date: Fri, 20 Sep 2024 19:02:26 +0300 (IDT)
Subject: [Icecast] One Last EZstream Problem
In-Reply-To: <48176e42-69fa-4826-9144-60340a1323ae@noisynotes.com>
References: <48176e42-69fa-4826-9144-60340a1323ae@noisynotes.com>
Message-ID: <138f8b22-1361-16da-48a3-4fe2efd71402@QuiteLikely.com>

On Thu, 19 Sep 2024, Steve Matzura wrote:

> I'm noticing that when a streamed program file ends and the next one begins, 
> sometimes the next streamed file will play for a second at double-speed, and 
> if the previous file doesn't run to the full time for which it is scheduled, 
> the stream that's relayed from the backup stream to the main one sometimes 
> plays at half speed. I've had this happen before, but it somehow worked 
> itself out. It now happens regularly, almost predictably on my new server. 
> Did I forget to include something in my XML file--i.e., is the Icecast server 
> getting confused about declared bitrates or something when files change?

first, it's worth knowing that MP3 streams don't always cope nicely with 
this sort of thing.

However, I've seen double/half speed things happen when there is a 
mismatch, either with sampling rates or channels.

You will most likely want everything to be 44100 Hz stereo, even if the 
source material is mono.

Make sure that both your main and backup streams are being output in this 
format.

HTH,
Geoff.



From sm at noisynotes.com  Fri Sep 20 20:51:37 2024
From: sm at noisynotes.com (Steve Matzura)
Date: Fri, 20 Sep 2024 16:51:37 -0400
Subject: [Icecast] EZstream XML that used to work
In-Reply-To: <7d7f6872-940b-5648-af9e-012ab539ee6a@QuiteLikely.com>
References: <9a76c2fe-f312-49e8-9578-bf759e27bc01@noisynotes.com>
 <7d7f6872-940b-5648-af9e-012ab539ee6a@QuiteLikely.com>
Message-ID: <6093752b-95d9-4c66-86f2-952fc34afd4a@noisynotes.com>

Geoff,


Great to find you here.


I almost want to cut the rest of this reply off except for the very last 
part, but maybe it'll be useful to some folks.


The bottom line is that you pointed out the stream_name directive in the 
<stream> block, I totally missed that in the two-hundred-plus-line 
ezstream_full.xml file, and it's exactly what I needed to solve the problem.


I did look at ezstream-cfgmigrate, and it works as far as what it's 
supposed to do, but none of the resultant converted files worked, and 
all for the same reason--I get login failures to the Icecast server. 
This is odd because the one and only place there's a password, it's 
correct. I'm not going to pursue why it doesn't work for my files 
because while I was going through all of this, I wrote my own migration 
tool that worked well except for that one item--<sream_name>. I added 
that line to my template, ran 52 files through it, and they all work 
just as they should. If you want to know more about that, we can take it 
up off-list, but otherwise, thank you very much for pointing me in the 
right direction. It taught me to read even more carefully than I thought 
I was doing, and that's always a good thing.


On 9/20/2024 11:41 AM, Geoff Shang wrote:
> Hey Steve,
>
> On Thu, 19 Sep 2024, Steve Matzura wrote:
>
>> The problem seems to be with the <name> XML directive. I thought that 
>> if it is added to the <server> block, the name of the stream could be 
>> displayed in a player. I think the problem comes up if the contents 
>> of the server name in that directive is more than one word--i.e., 
>> contains spaces. I removed it, and the player again shows "no name" 
>> where I would expect to see one. How then does this work? I want to 
>> display my station name in this name field like I could with an older 
>> version of ezstream.
>
> first of all, this looks like it needs to be within a <stream> tag 
> inside a <streams> tag.
>
> The format of the config file has changed a lot since the early days. 
> There is a program called ezstream-cfgmigrate which may help if you 
> still have your original config file.
>
> From the ezstream-full.xml file that's in the doc/examples directory 
> of version 1.0.2:
>
> ? <!--
> ??? Stream configuration
> ??? -->
> ? <streams>
> ??? <stream>
> ????? <!--
> ??????? Identifying name (default: "default")
>
> ??????? NB: Only the "default" stream is supported at this point.
> ??????? -->
> ????? <!-- <name>default</name> -->
>
> This seems to indicate that the purpose of this parameter has changed 
> (it's been a *very* long time since I looked at this).
>
> It also seems that the default value is "default", which is also the 
> only currently supported value.? This would explain the above error 
> message - there is no stream labeled "default".
>
> So you can omit this parameter entirely.
>
> What I think you want is <stream_name> which is also in the <stream> 
> section.? From further down the same file:
>
> ????? <!-- Various other informational settings -->
> ????? <stream_name>Test Stream</stream_name>
> ????? <stream_url>http://localhost:8000/</stream_url>
> ????? <stream_genre>Beeps</stream_genre>
> ????? <stream_description>Test tones and noise</stream_description>
> ????? <stream_quality>1.5</stream_quality>
> ????? <stream_bitrate>16</stream_bitrate>
> ????? <stream_samplerate>44100</stream_samplerate>
> ????? <stream_channels>2</stream_channels>
> ??? </stream>
> ? </streams>
>
> HTH,
> Geoff.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20240920/93fb75ea/attachment.htm>