From ervin.bizjak at gmail.com  Fri May  8 12:04:10 2020
From: ervin.bizjak at gmail.com (Ervin Bizjak)
Date: Fri, 8 May 2020 14:04:10 +0200
Subject: [Icecast] SSL
Message-ID: <CABDatAQs_JTE7DTU4mVP4UhPj1bEWHxDUm33AYHY0TyZmG+_5A@mail.gmail.com>

Hello!

I'm create free SSL in ZeroSSL. Now download certificate. In zip are:
ca_bundle.crt, certificate.crt and private.key.

How do I now create .pem?

Please help me!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200508/55117438/attachment.htm>

From marius at flage.org  Fri May  8 12:07:22 2020
From: marius at flage.org (Marius Flage)
Date: Fri, 8 May 2020 14:07:22 +0200
Subject: [Icecast] SSL
In-Reply-To: <CABDatAQs_JTE7DTU4mVP4UhPj1bEWHxDUm33AYHY0TyZmG+_5A@mail.gmail.com>
References: <CABDatAQs_JTE7DTU4mVP4UhPj1bEWHxDUm33AYHY0TyZmG+_5A@mail.gmail.com>
Message-ID: <1a750ffc-a352-d6b6-486d-d10e6c0b9372@flage.org>

The .crt file is most likely in the pem format, so just rename (mv
certificate.crt certificate.pem) it if you need it to be .pem. If not
you can simply just use it directly.

--
Marius

On 08.05.2020 14:04, Ervin Bizjak wrote:
> Hello!
>
> I'm create free SSL in ZeroSSL. Now download certificate. In zip are:
> ca_bundle.crt, certificate.crt and private.key.
>
> How do I now create .pem?
>
> Please help me!
>
> _______________________________________________
> 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/20200508/9091f643/attachment.htm>

From webmaster at berean-biblechurch.org  Sun May 10 12:47:31 2020
From: webmaster at berean-biblechurch.org (webmaster at berean-biblechurch.org)
Date: Sun, 10 May 2020 07:47:31 -0500
Subject: [Icecast] default headers
Message-ID: <3895d7be32cc0f7b462e40f5600943cf@berean-biblechurch.org>

It looks like Icecast uses the default and not configurable response
headers of no-cache and no-store.  What is the logic of this?  Aren't
they even incompatible since no-cache allows for caching but no-store
does not? 

I discovered this when I wanted the live stream to not cache in the
browser, so I added the no-store header to the config file.  Then
looking at the XHR to the live stream in the browser's dev tools, I see
no-cache, no-store, and no-store.  That tells me my new header just
added to what must be the default. 

Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200510/8cff2553/attachment.htm>

From pm at nowster.me.uk  Sun May 10 13:10:57 2020
From: pm at nowster.me.uk (Paul Martin)
Date: Sun, 10 May 2020 14:10:57 +0100
Subject: [Icecast] SSL
In-Reply-To: <CABDatAQs_JTE7DTU4mVP4UhPj1bEWHxDUm33AYHY0TyZmG+_5A@mail.gmail.com>
References: <CABDatAQs_JTE7DTU4mVP4UhPj1bEWHxDUm33AYHY0TyZmG+_5A@mail.gmail.com>
Message-ID: <20200510131057.GB498561@thinkpad.nowster.org.uk>

On Fri, May 08, 2020 at 02:04:10PM +0200, Ervin Bizjak wrote:
> Hello!
> 
> I'm create free SSL in ZeroSSL. Now download certificate. In zip are:
> ca_bundle.crt, certificate.crt and private.key.
> 
> How do I now create .pem?

It's probably best to join the files together. Hopefully they're text
files, so just

cat ca_bundle.crt certificate.crt private.key > certificate.pem

(Or use a text editor to copy and paste them together, making sure
nothing extra gets in.)

-- 
Paul Martin <pm at nowster.me.uk>


From googe at googe.tv  Sun May 10 17:43:12 2020
From: googe at googe.tv (Googe)
Date: Sun, 10 May 2020 10:43:12 -0700
Subject: [Icecast] icecast.org?
Message-ID: <f0d1a553-4a6d-89a8-2aa8-09792c06c31c@googe.tv>

An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200510/c964cd6e/attachment.htm>

From ervin.bizjak at gmail.com  Sun May 10 18:35:24 2020
From: ervin.bizjak at gmail.com (Ervin Bizjak)
Date: Sun, 10 May 2020 20:35:24 +0200
Subject: [Icecast] SSL
In-Reply-To: <20200510131057.GB498561@thinkpad.nowster.org.uk>
References: <CABDatAQs_JTE7DTU4mVP4UhPj1bEWHxDUm33AYHY0TyZmG+_5A@mail.gmail.com>
 <20200510131057.GB498561@thinkpad.nowster.org.uk>
Message-ID: <CABDatARzUOweTEm-gX3bxh2fk8xMUspCU9zDkZonZ=Av2UaMqg@mail.gmail.com>

Yes, make for this step, but not work

V V ned., 10. maj 2020 ob 15:11 je oseba Paul Martin <pm at nowster.me.uk>
napisala:

> On Fri, May 08, 2020 at 02:04:10PM +0200, Ervin Bizjak wrote:
> > Hello!
> >
> > I'm create free SSL in ZeroSSL. Now download certificate. In zip are:
> > ca_bundle.crt, certificate.crt and private.key.
> >
> > How do I now create .pem?
>
> It's probably best to join the files together. Hopefully they're text
> files, so just
>
> cat ca_bundle.crt certificate.crt private.key > certificate.pem
>
> (Or use a text editor to copy and paste them together, making sure
> nothing extra gets in.)
>
> --
> Paul Martin <pm at nowster.me.uk>
> _______________________________________________
> 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/20200510/9e2f3a09/attachment.htm>

From jordan at coolmic.net  Sun May 10 23:00:10 2020
From: jordan at coolmic.net (Jordan Erickson)
Date: Sun, 10 May 2020 16:00:10 -0700
Subject: [Icecast] icecast.org?
In-Reply-To: <f0d1a553-4a6d-89a8-2aa8-09792c06c31c@googe.tv>
References: <f0d1a553-4a6d-89a8-2aa8-09792c06c31c@googe.tv>
Message-ID: <12312484-e8dc-e657-7a56-a093c59e34f7@coolmic.net>

Hi, yes the server that hosts icecast.org and some other Xiph resources
is currently being "upgraded" AFAIK (some server hardware failure).


Cheers,
Jordan


On 5/10/20 10:43 AM, Googe wrote:
> Is icecast.org web site being upgraded?
> 
> Getting this message from Firefox:
> 
> Websites prove their identity via certificates. Firefox does not trust
> this site because it uses a certificate that is not valid for
> icecast.org. The certificate is only valid for the following names:
> catfish.xiph.org, wiki.xiph.org
> ?
> Error code: SSL_ERROR_BAD_CERT_DOMAIN
> 
> 
> 
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
> 


From sm at noisynotes.com  Mon May 11 18:44:36 2020
From: sm at noisynotes.com (Steve Matzura)
Date: Mon, 11 May 2020 14:44:36 -0400
Subject: [Icecast] Mystery Song Artist Shows in Listener Stats
Message-ID: <64401a8a-9cce-6c38-0d40-e947af250eee@noisynotes.com>

For a very long time--years in fact--I have had a problem with one of 
the replays on the server I manage. For this one replay only, which is a 
program of two hours duration, the bottom of the statistics table for 
the stream says the current song is xxx/the-show-name, and the 'xxx' in 
question bears no relation to the current song. In fact, there *is* no 
currents song--the file that's playing has no other metadata in it 
except the name of the program in the MP3 title field, and the name of 
the presenter in the MP3 artist field. What could be causing this? Where 
does this "current song" data come from?




From phschafft at de.loewenfelsen.net  Tue May 12 10:28:28 2020
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Tue, 12 May 2020 10:28:28 +0000
Subject: [Icecast] Mystery Song Artist Shows in Listener Stats
In-Reply-To: <64401a8a-9cce-6c38-0d40-e947af250eee@noisynotes.com>
References: <64401a8a-9cce-6c38-0d40-e947af250eee@noisynotes.com>
Message-ID: <1589279308.1915.17.camel@de.loewenfelsen.net>

Good morning,

On Mon, 2020-05-11 at 14:44 -0400, Steve Matzura wrote:
> For a very long time--years in fact--I have had a problem with one of 
> the replays on the server I manage. For this one replay only, which is a 
> program of two hours duration, the bottom of the statistics table for 
> the stream says the current song is xxx/the-show-name, and the 'xxx' in 
> question bears no relation to the current song. In fact, there *is* no 
> currents song--the file that's playing has no other metadata in it 
> except the name of the program in the MP3 title field, and the name of 
> the presenter in the MP3 artist field. What could be causing this?

> Where 
> does this "current song" data come from?

Metadata are in the responsibility of the source client. So please check
that your source client doesn't have the additional text configured in
some way.

Also make sure there are only one source running per mount. Sometime
broken source clients keep trying to update metadata even when not
successfully connected to the mount point.

With best regards,

-- 
Philipp Schafft (CEO/Gesch?ftsf?hrer) 
Telephon: +49.3535 490 17 92

L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
Bickinger Stra?e 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200512/930985d8/attachment.sig>

From sm at noisynotes.com  Tue May 12 21:39:39 2020
From: sm at noisynotes.com (Steve Matzura)
Date: Tue, 12 May 2020 17:39:39 -0400
Subject: [Icecast] Mystery Song Artist Shows in Listener Stats
In-Reply-To: <1589279308.1915.17.camel@de.loewenfelsen.net>
References: <64401a8a-9cce-6c38-0d40-e947af250eee@noisynotes.com>
 <1589279308.1915.17.camel@de.loewenfelsen.net>
Message-ID: <94874727-936c-943c-5dab-70d4b76d2a73@noisynotes.com>

It took some real deep digging, but I figured out what's going on. It's 
an EZStream problem. Or maybe not. Here's what's going on. The song name 
that's wrong comes from a three-second file that streams immediately 
before the main program. This file contains someone saying "The 
following program is broadcast in German." It seems that when the next 
file streams, only some of the metadata updates Listener Stats shows the 
correct program name, but the last line--Current song--gets held over 
from that short file that streams first.


On 5/12/2020 6:28 AM, Philipp Schafft wrote:
> Good morning,
>
> On Mon, 2020-05-11 at 14:44 -0400, Steve Matzura wrote:
>> For a very long time--years in fact--I have had a problem with one of
>> the replays on the server I manage. For this one replay only, which is a
>> program of two hours duration, the bottom of the statistics table for
>> the stream says the current song is xxx/the-show-name, and the 'xxx' in
>> question bears no relation to the current song. In fact, there *is* no
>> currents song--the file that's playing has no other metadata in it
>> except the name of the program in the MP3 title field, and the name of
>> the presenter in the MP3 artist field. What could be causing this?
>> Where
>> does this "current song" data come from?
> Metadata are in the responsibility of the source client. So please check
> that your source client doesn't have the additional text configured in
> some way.
>
> Also make sure there are only one source running per mount. Sometime
> broken source clients keep trying to update metadata even when not
> successfully connected to the mount point.
>
> With best regards,
>
>
> _______________________________________________
> 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/20200512/9f86aab4/attachment.htm>

From mjbrenegan at yahoo.com  Wed May 13 11:01:53 2020
From: mjbrenegan at yahoo.com (Michael Brenegan)
Date: Wed, 13 May 2020 11:01:53 +0000 (UTC)
Subject: [Icecast] Icecast and Ices logrotate
In-Reply-To: <1589279308.1915.17.camel@de.loewenfelsen.net>
References: <64401a8a-9cce-6c38-0d40-e947af250eee@noisynotes.com>
 <1589279308.1915.17.camel@de.loewenfelsen.net>
Message-ID: <2120443249.243694.1589367713324@mail.yahoo.com>

I don';t know if this is the proper place to ask this, but here goes.
I've been running icecast with ices for quite some time, and my log files are growing quite large.? (/var/log/icecast/access.log and /var/log/icecast/error.log as well as (/usr/local/icecast/var/ices.log).? I am having some trouble properly setting up the three logs under logrotate.
I seem to remember having this all set up back when I started with icecast/ices under Redhat 7.3 or so, and now, I'm streaming under Fedora 32.? It must have fallen out of configuration during one of the many software or hardware upgrades and migrations I have done.
Can anybody give me a push in the right direction?
Many thanks,

Michael J. Brenegan 
USAR, Retired 
Clinical Engineering 
Yale/New Haven Hospital 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200513/c2838d72/attachment.htm>

From kitwithnail at mailbox.org  Wed May 13 11:53:01 2020
From: kitwithnail at mailbox.org (Kit)
Date: Wed, 13 May 2020 12:53:01 +0100
Subject: [Icecast] IceS segfault assistance
Message-ID: <E8AC179E-D5D0-4119-BF80-B039E844B463@mailbox.org>

Can I ask if this is an appropriate place to ask for assistance with an IceS issue, namely a segfault? 
If not, please could I ask to be directed to a more appropriate place for this?

Many thanks.

From pm at nowster.me.uk  Wed May 13 16:59:17 2020
From: pm at nowster.me.uk (Paul Martin)
Date: Wed, 13 May 2020 17:59:17 +0100
Subject: [Icecast] SSL
In-Reply-To: <CABDatARzUOweTEm-gX3bxh2fk8xMUspCU9zDkZonZ=Av2UaMqg@mail.gmail.com>
References: <CABDatAQs_JTE7DTU4mVP4UhPj1bEWHxDUm33AYHY0TyZmG+_5A@mail.gmail.com>
 <20200510131057.GB498561@thinkpad.nowster.org.uk>
 <CABDatARzUOweTEm-gX3bxh2fk8xMUspCU9zDkZonZ=Av2UaMqg@mail.gmail.com>
Message-ID: <20200513165917.GC647577@thinkpad.nowster.org.uk>

On Sun, May 10, 2020 at 08:35:24PM +0200, Ervin Bizjak wrote:
> Yes, make for this step, but not work

Are the certificate/key files plain text? eg.

-----BEGIN CERTIFICATE-----
sxsCAwEAAaOCAsUwggLBMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEF
...
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
5Cja8EgPeEL8HEGYhGrTD+xjag21cYC2SPgXkG0HIEdiX9LTYpEF7ADcuyjtgSYw
...
-----END CERTIFICATE-----

-----BEGIN PRIVATE KEY-----
Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWA
...
-----END PRIVATE KEY-----

If not you'll need to convert them.

-- 
Paul Martin <pm at nowster.me.uk>


From florianreiterer at gmx.de  Wed May 13 17:57:11 2020
From: florianreiterer at gmx.de (Florian Reiterer)
Date: Wed, 13 May 2020 19:57:11 +0200
Subject: [Icecast] FLAC streaming: mpd clients stop at each track
Message-ID: <b7958f72-23f6-f713-ef4e-8cbc129450b1@gmx.de>

Hi all,

i have a liquidsoap-to-icecast stream of FLAC files that makes mpd
applications stop at each track.

Liquidsoap/1.5.0+git at 4b72b518 (Unix; OCaml 4.08.0); Icecast 2.4.4
(compiled with curl and ssl)

server_type ??? application/ogg

Is this a known problem, is there something i need to tell liquidsoap or
icecast that one knows of?

thanks,

Florian

icecast3.streamserver24.com:18800 - the icecast server status page

motherearthradio.de



From webmaster at berean-biblechurch.org  Thu May 14 02:42:05 2020
From: webmaster at berean-biblechurch.org (webmaster at berean-biblechurch.org)
Date: Wed, 13 May 2020 21:42:05 -0500
Subject: [Icecast] can't stream Opus in CAF format
Message-ID: <9d3b45dd8d9c3800faaa312e124e6a2b@berean-biblechurch.org>

Using FFmpeg, I can stream to a file on disk okay:
    c:\apps\ffmpeg\bin\ffmpeg.exe -f dshow -i audio="Line In (Realtek
High Definition Audio)" -c:a libopus -ac 1 -b:a 32000 live.caf

But, if I add Icey metadata, FFmpeg throws errors: 
    c:\apps\ffmpeg\bin\ffmpeg.exe -f dshow -i audio="Line In (Realtek
High Definition Audio)" -c:a libopus -ac 1 -b:a 32000^
 -ice_name "live broadcast" -ice_description "desc"^
 -ice_genre "genre" -ice_url "https://stream.example.org/live.caf"
-user_agent "agent" -content_type "audio/x-caf"^
 icecast://source:hackme at localhost:8000/live.caf 
[caf @ 00000204b419ac80] Muxing variable packet size not supported on
non seekable output
Could not write header for output file #0 (incorrect codec parameters
?): Invalid data found when processing input
Error initializing output stream 0:0 -- 

Any idea why the destination of Icecast makes a difference?  Is there
something I can adjust in Icecast to make it work? 

Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200513/412b072c/attachment.htm>

From ervin.bizjak at gmail.com  Thu May 14 05:53:58 2020
From: ervin.bizjak at gmail.com (Ervin Bizjak)
Date: Thu, 14 May 2020 07:53:58 +0200
Subject: [Icecast] SSL
In-Reply-To: <20200513165917.GC647577@thinkpad.nowster.org.uk>
References: <CABDatAQs_JTE7DTU4mVP4UhPj1bEWHxDUm33AYHY0TyZmG+_5A@mail.gmail.com>
 <20200510131057.GB498561@thinkpad.nowster.org.uk>
 <CABDatARzUOweTEm-gX3bxh2fk8xMUspCU9zDkZonZ=Av2UaMqg@mail.gmail.com>
 <20200513165917.GC647577@thinkpad.nowster.org.uk>
Message-ID: <CABDatARvzGX5YX3RnUszGq-HqW8ELEbFwHVRtjrFb1eTh5rDcg@mail.gmail.com>

Thank you for help

V V sre., 13. maj 2020 ob 18:59 je oseba Paul Martin <pm at nowster.me.uk>
napisala:

> On Sun, May 10, 2020 at 08:35:24PM +0200, Ervin Bizjak wrote:
> > Yes, make for this step, but not work
>
> Are the certificate/key files plain text? eg.
>
> -----BEGIN CERTIFICATE-----
> sxsCAwEAAaOCAsUwggLBMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEF
> ...
> -----END CERTIFICATE-----
>
> -----BEGIN CERTIFICATE-----
> 5Cja8EgPeEL8HEGYhGrTD+xjag21cYC2SPgXkG0HIEdiX9LTYpEF7ADcuyjtgSYw
> ...
> -----END CERTIFICATE-----
>
> -----BEGIN PRIVATE KEY-----
> Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWA
> ...
> -----END PRIVATE KEY-----
>
> If not you'll need to convert them.
>
> --
> Paul Martin <pm at nowster.me.uk>
> _______________________________________________
> 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/20200514/0b98b212/attachment.htm>

From epirat07 at gmail.com  Thu May 14 06:06:03 2020
From: epirat07 at gmail.com (Marvin Scholz)
Date: Thu, 14 May 2020 08:06:03 +0200
Subject: [Icecast] can't stream Opus in CAF format
In-Reply-To: <9d3b45dd8d9c3800faaa312e124e6a2b@berean-biblechurch.org>
References: <9d3b45dd8d9c3800faaa312e124e6a2b@berean-biblechurch.org>
Message-ID: <B3E9C9EC-6BD5-47B2-A527-4DD88C9819BF@gmail.com>

Hi,

the CAF format is not stremable due to the way the format works.

On 14 May 2020, at 4:42, webmaster at berean-biblechurch.org wrote:

> Using FFmpeg, I can stream to a file on disk okay:
>     c:\apps\ffmpeg\bin\ffmpeg.exe -f dshow -i audio="Line In (Realtek
> High Definition Audio)" -c:a libopus -ac 1 -b:a 32000 live.caf
>
> But, if I add Icey metadata, FFmpeg throws errors:
>     c:\apps\ffmpeg\bin\ffmpeg.exe -f dshow -i audio="Line In (Realtek
> High Definition Audio)" -c:a libopus -ac 1 -b:a 32000^
>  -ice_name "live broadcast" -ice_description "desc"^
>  -ice_genre "genre" -ice_url "https://stream.example.org/live.caf"
> -user_agent "agent" -content_type "audio/x-caf"^
>  icecast://source:hackme at localhost:8000/live.caf
> [caf @ 00000204b419ac80] Muxing variable packet size not supported on
> non seekable output
> Could not write header for output file #0 (incorrect codec parameters
> ?): Invalid data found when processing input
> Error initializing output stream 0:0 --
>
> Any idea why the destination of Icecast makes a difference?  Is there
> something I can adjust in Icecast to make it work?
>
> Justin_______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast


From pm at nowster.me.uk  Fri May 15 18:11:39 2020
From: pm at nowster.me.uk (Paul Martin)
Date: Fri, 15 May 2020 19:11:39 +0100
Subject: [Icecast] FLAC streaming: mpd clients stop at each track
In-Reply-To: <b7958f72-23f6-f713-ef4e-8cbc129450b1@gmx.de>
References: <b7958f72-23f6-f713-ef4e-8cbc129450b1@gmx.de>
Message-ID: <20200515181139.GB31823@thinkpad.nowster.org.uk>

On Wed, May 13, 2020 at 07:57:11PM +0200, Florian Reiterer wrote:
> i have a liquidsoap-to-icecast stream of FLAC files that makes mpd
> applications stop at each track.

Many players incorrectly stop when the metadata changes and one
logical bitstream in the Ogg container changes to the next.

-- 
Paul Martin <pm at nowster.me.uk>


From webmaster at berean-biblechurch.org  Sat May 16 01:23:33 2020
From: webmaster at berean-biblechurch.org (webmaster at berean-biblechurch.org)
Date: Fri, 15 May 2020 20:23:33 -0500
Subject: [Icecast] can't stream Opus in CAF format
In-Reply-To: <B3E9C9EC-6BD5-47B2-A527-4DD88C9819BF@gmail.com>
References: <9d3b45dd8d9c3800faaa312e124e6a2b@berean-biblechurch.org>
 <B3E9C9EC-6BD5-47B2-A527-4DD88C9819BF@gmail.com>
Message-ID: <c2621cfed3952478edf4b12f0ce6e0e5@berean-biblechurch.org>

Thank you.

On 2020-05-14 01:06, Marvin Scholz wrote:
> Hi,
> 
> the CAF format is not stremable due to the way the format works.
> 
> On 14 May 2020, at 4:42, webmaster at berean-biblechurch.org wrote:
> 
>> Using FFmpeg, I can stream to a file on disk okay:
>>     c:\apps\ffmpeg\bin\ffmpeg.exe -f dshow -i audio="Line In (Realtek
>> High Definition Audio)" -c:a libopus -ac 1 -b:a 32000 live.caf
>> 
>> But, if I add Icey metadata, FFmpeg throws errors:
>>     c:\apps\ffmpeg\bin\ffmpeg.exe -f dshow -i audio="Line In (Realtek
>> High Definition Audio)" -c:a libopus -ac 1 -b:a 32000^
>>  -ice_name "live broadcast" -ice_description "desc"^
>>  -ice_genre "genre" -ice_url "https://stream.example.org/live.caf"
>> -user_agent "agent" -content_type "audio/x-caf"^
>>  icecast://source:hackme at localhost:8000/live.caf
>> [caf @ 00000204b419ac80] Muxing variable packet size not supported on
>> non seekable output
>> Could not write header for output file #0 (incorrect codec parameters
>> ?): Invalid data found when processing input
>> Error initializing output stream 0:0 --
>> 
>> Any idea why the destination of Icecast makes a difference?  Is there
>> something I can adjust in Icecast to make it work?
>> 
>> Justin_______________________________________________
>> 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 kitwithnail at mailbox.org  Sat May 16 14:52:40 2020
From: kitwithnail at mailbox.org (Kit)
Date: Sat, 16 May 2020 15:52:40 +0100
Subject: [Icecast] IceS segmentation fault
Message-ID: <C2E84E05-486B-4981-947D-C6DCEB0A27F6@mailbox.org>

I get a segmentation fault when starting the IceS encoder on a Linux-based QNAP NAS.

I'm trying to set up IceS to stream an ALSA input to Icecast. Icecast works well and confirms when I stream using other things to it. However IceS hits a segmentation fault immediately after starting the encoder.
The IceS log is:

[~] # sudo ices /etc/ices.xml
[2020-05-11  19:24:34] INFO ices-core/main IceS 2.0.2 started...
[2020-05-11  19:24:34] INFO input-alsa/alsa_open_module Opened audio device hw:0,0
[2020-05-11  19:24:34] INFO input-alsa/alsa_open_module using 2 channel(s), 48000 Hz, buffer 341 ms 
[2020-05-11  19:24:34] INFO input-alsa/alsa_open_module Starting metadata update thread
[2020-05-11  19:24:34] INFO signals/signal_usr1_handler Metadata update requested
[2020-05-11  19:24:34] INFO encode/encode_initialise Encoder initialising with bitrate management: 2 channels, 48000 Hz, minimum bitrate 256000, nominal 320000, maximum 320000
Segmentation fault
The IceS config file looks like this:

<?xml version="1.0"?>
<ices>

<background>0</background>
<logpath>/share/4a Downloads temporary</logpath>
<logfile>ices.log</logfile>
<logsize>10000</logsize>
<loglevel>4</loglevel>
<consolelog>1</consolelog>
<!-- <pidfile>/share/4a Downloads temporary/ices.pid</pidfile> -->

<stream>
        <metadata>
                <name>Roon</name>
                <genre>Avant-garde</genre>
                <description>Roon Icecast stream</description>
        </metadata>

        <input>
        <module>alsa</module>
                <param name="rate">48000</param>
                <param name="channels">2</param>
                <param name="device">hw:0</param>
                <param name="periods">2</param>
                <param name="buffer-time">1000</param>
                <!-- <param name="metadata">1</param>
                <param name="metadatafilename">/home/ices/metadata</param> -->
        </input>

        <instance>
                <hostname>localhost</hostname>
                <port>8000</port>
                <password>mirror</password>
                <mount>/test.ogg</mount>
                <encode>
                        <quality>10</quality>-->
                        <nominal-bitrate>320000</nominal-bitrate>
                        <maximum-bitrate>320000</maximum-bitrate>
                        <minimum-bitrate>256000</minimum-bitrate>-->
                        <managed>1</managed>
                        <samplerate>48000</samplerate>
                        <channels>2</channels>
                        <flush-samples>48000</flush-samples>
                </encode>
        </instance>
</stream>

</ices>
I've changed nearly every parameter in it to see if I can get round it, but all I am able to achieve is causing a crash sooner than the segfault. I've also got no more logging than this - level 4 is max anyway - so I can only assume the fault is in the encoder. libvorbis and libogg are both installed. I don't know of any way to use an external encoder or I'd be using that... can anyone help with what might be causing this segfault?

Thanks!



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200516/6b4efb58/attachment.htm>

From epirat07 at gmail.com  Sat May 16 15:49:08 2020
From: epirat07 at gmail.com (Marvin Scholz)
Date: Sat, 16 May 2020 17:49:08 +0200
Subject: [Icecast] IceS segmentation fault
In-Reply-To: <C2E84E05-486B-4981-947D-C6DCEB0A27F6@mailbox.org>
References: <C2E84E05-486B-4981-947D-C6DCEB0A27F6@mailbox.org>
Message-ID: <F67E2F54-C49E-4102-912E-80D61BFF4062@gmail.com>

Please obtain a stacktrace as the log seems not very
helpful in this case to figure out what went wrong.

On 16 May 2020, at 16:52, Kit wrote:

> I get a segmentation fault when starting the IceS encoder on a 
> Linux-based QNAP NAS.
>
> I'm trying to set up IceS to stream an ALSA input to Icecast. Icecast 
> works well and confirms when I stream using other things to it. 
> However IceS hits a segmentation fault immediately after starting the 
> encoder.
> The IceS log is:
>
> [~] # sudo ices /etc/ices.xml
> [2020-05-11  19:24:34] INFO ices-core/main IceS 2.0.2 started...
> [2020-05-11  19:24:34] INFO input-alsa/alsa_open_module Opened audio 
> device hw:0,0
> [2020-05-11  19:24:34] INFO input-alsa/alsa_open_module using 2 
> channel(s), 48000 Hz, buffer 341 ms
> [2020-05-11  19:24:34] INFO input-alsa/alsa_open_module Starting 
> metadata update thread
> [2020-05-11  19:24:34] INFO signals/signal_usr1_handler Metadata 
> update requested
> [2020-05-11  19:24:34] INFO encode/encode_initialise Encoder 
> initialising with bitrate management: 2 channels, 48000 Hz, minimum 
> bitrate 256000, nominal 320000, maximum 320000
> Segmentation fault
> The IceS config file looks like this:
>
> <?xml version="1.0"?>
> <ices>
>
> <background>0</background>
> <logpath>/share/4a Downloads temporary</logpath>
> <logfile>ices.log</logfile>
> <logsize>10000</logsize>
> <loglevel>4</loglevel>
> <consolelog>1</consolelog>
> <!-- <pidfile>/share/4a Downloads temporary/ices.pid</pidfile> -->
>
> <stream>
>         <metadata>
>                 <name>Roon</name>
>                 <genre>Avant-garde</genre>
>                 <description>Roon Icecast stream</description>
>         </metadata>
>
>         <input>
>         <module>alsa</module>
>                 <param name="rate">48000</param>
>                 <param name="channels">2</param>
>                 <param name="device">hw:0</param>
>                 <param name="periods">2</param>
>                 <param name="buffer-time">1000</param>
>                 <!-- <param name="metadata">1</param>
>                 <param 
> name="metadatafilename">/home/ices/metadata</param> -->
>         </input>
>
>         <instance>
>                 <hostname>localhost</hostname>
>                 <port>8000</port>
>                 <password>mirror</password>
>                 <mount>/test.ogg</mount>
>                 <encode>
>                         <quality>10</quality>-->
>                         <nominal-bitrate>320000</nominal-bitrate>
>                         <maximum-bitrate>320000</maximum-bitrate>
>                         <minimum-bitrate>256000</minimum-bitrate>-->
>                         <managed>1</managed>
>                         <samplerate>48000</samplerate>
>                         <channels>2</channels>
>                         <flush-samples>48000</flush-samples>
>                 </encode>
>         </instance>
> </stream>
>
> </ices>
> I've changed nearly every parameter in it to see if I can get round 
> it, but all I am able to achieve is causing a crash sooner than the 
> segfault. I've also got no more logging than this - level 4 is max 
> anyway - so I can only assume the fault is in the encoder. libvorbis 
> and libogg are both installed. I don't know of any way to use an 
> external encoder or I'd be using that... can anyone help with what 
> might be causing this segfault?
>
> Thanks!


> _______________________________________________
> 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/20200516/c2c78a44/attachment.htm>

From aktrapper2000 at gmail.com  Sat May 16 18:42:16 2020
From: aktrapper2000 at gmail.com (Greg Jetter)
Date: Sat, 16 May 2020 10:42:16 -0800
Subject: [Icecast] IceS segmentation fault
In-Reply-To: <F67E2F54-C49E-4102-912E-80D61BFF4062@gmail.com>
References: <C2E84E05-486B-4981-947D-C6DCEB0A27F6@mailbox.org>
 <F67E2F54-C49E-4102-912E-80D61BFF4062@gmail.com>
Message-ID: <0A31F27D-3935-4254-9E52-5418592585D3@gmail.com>

A quick look at your xml code , reveals several  errors in format  , your  xml needs to be well formed and correct  or the  interpreter  will  puke .  this mite not be your problem but you should fix it first .

>  <encode>
>                   ****  <quality>10</quality>?>  ****
>                         <nominal-bitrate>320000</nominal-bitrate>
>                         <maximum-bitrate>320000</maximum-bitrate>
>                  *****  <minimum-bitrate>256000</minimum-bitrate>?> *****
>                         <managed>1</managed>
>                         <samplerate>48000</samplerate>
>                         <channels>2</channels>
>                         <flush-samples>48000</flush-samples>
>                 </encode>

Neither a comment outed  line of code  nor a well formed xml  tag.
also take a look at your system log  for the time frame your  launching  the application , it may reveal what?s causing the segmentation fault.


> On May 16, 2020, at 7:49 AM, Marvin Scholz <epirat07 at gmail.com <mailto:epirat07 at gmail.com>> wrote:
> 
> Please obtain a stacktrace as the log seems not very
> helpful in this case to figure out what went wrong.
> 
> On 16 May 2020, at 16:52, Kit wrote:
> 
> I get a segmentation fault when starting the IceS encoder on a Linux-based QNAP NAS.
> 
> I'm trying to set up IceS to stream an ALSA input to Icecast. Icecast works well and confirms when I stream using other things to it. However IceS hits a segmentation fault immediately after starting the encoder.
> The IceS log is:
> 
> [~] # sudo ices /etc/ices.xml
> [2020-05-11  19:24:34] INFO ices-core/main IceS 2.0.2 started...
> [2020-05-11  19:24:34] INFO input-alsa/alsa_open_module Opened audio device hw:0,0
> [2020-05-11  19:24:34] INFO input-alsa/alsa_open_module using 2 channel(s), 48000 Hz, buffer 341 ms 
> [2020-05-11  19:24:34] INFO input-alsa/alsa_open_module Starting metadata update thread
> [2020-05-11  19:24:34] INFO signals/signal_usr1_handler Metadata update requested
> [2020-05-11  19:24:34] INFO encode/encode_initialise Encoder initialising with bitrate management: 2 channels, 48000 Hz, minimum bitrate 256000, nominal 320000, maximum 320000
> Segmentation fault
> The IceS config file looks like this:
> 
> <?xml version="1.0"?>
> <ices>
> 
> <background>0</background>
> <logpath>/share/4a Downloads temporary</logpath>
> <logfile>ices.log</logfile>
> <logsize>10000</logsize>
> <loglevel>4</loglevel>
> <consolelog>1</consolelog>
> <!-- <pidfile>/share/4a Downloads temporary/ices.pid</pidfile> -->
> 
> <stream>
>         <metadata>
>                 <name>Roon</name>
>                 <genre>Avant-garde</genre>
>                 <description>Roon Icecast stream</description>
>         </metadata>
> 
>         <input>
>         <module>alsa</module>
>                 <param name="rate">48000</param>
>                 <param name="channels">2</param>
>                 <param name="device">hw:0</param>
>                 <param name="periods">2</param>
>                 <param name="buffer-time">1000</param>
>                 <!-- <param name="metadata">1</param>
>                 <param name="metadatafilename">/home/ices/metadata</param> -->
>         </input>
> 
>         <instance>
>                 <hostname>localhost</hostname>
>                 <port>8000</port>
>                 <password>mirror</password>
>                 <mount>/test.ogg</mount>
>                 <encode>
>                         <quality>10</quality>-->
>                         <nominal-bitrate>320000</nominal-bitrate>
>                         <maximum-bitrate>320000</maximum-bitrate>
>                         <minimum-bitrate>256000</minimum-bitrate>-->
>                         <managed>1</managed>
>                         <samplerate>48000</samplerate>
>                         <channels>2</channels>
>                         <flush-samples>48000</flush-samples>
>                 </encode>
>         </instance>
> </stream>
> 
> </ices>
> I've changed nearly every parameter in it to see if I can get round it, but all I am able to achieve is causing a crash sooner than the segfault. I've also got no more logging than this - level 4 is max anyway - so I can only assume the fault is in the encoder. libvorbis and  libogg are both installed. I don't know of any way to use an external encoder or I'd be using that... can anyone help with what might be causing this segfault?
> 
> Thanks!
> 
> 
> 
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org <mailto:Icecast at xiph.org>
> http://lists.xiph.org/mailman/listinfo/icecast <http://lists.xiph.org/mailman/listinfo/icecast>_______________________________________________
> Icecast mailing list
> Icecast at xiph.org <mailto:Icecast at xiph.org>
> http://lists.xiph.org/mailman/listinfo/icecast <http://lists.xiph.org/mailman/listinfo/icecast>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200516/5ae8c178/attachment.htm>

From that.jack.elliott at gmail.com  Sat May 16 19:30:59 2020
From: that.jack.elliott at gmail.com (Jack Elliott)
Date: Sat, 16 May 2020 12:30:59 -0700
Subject: [Icecast] Add metadata to fallback mount?
Message-ID: <aed5b87d-4dda-2802-d5cb-87f52c5c71c4@kpov.org>

Hi, I'm pretty sure this isn't going to be possible, but I'll ask. I'd 
like to add a <stream-title> to my fallback mount so when the main 
stream mount drops and the fallback kicks in, that the connected player 
shows a different title.

Then back again, of course.

Thank you!

-- 
That Jack Elliott
Director of Classical Music Programming
KPOV 88.9 FM High Desert Community radio
(541) 848 7021



From webmaster at berean-biblechurch.org  Sun May 17 18:49:16 2020
From: webmaster at berean-biblechurch.org (webmaster at berean-biblechurch.org)
Date: Sun, 17 May 2020 13:49:16 -0500
Subject: [Icecast] how to remove no-cache header
Message-ID: <cb9c8363fca145c1332cc15fdd255157@berean-biblechurch.org>

Is it possible to remove or negate the _no-cache_ header Icecast returns
to the client?  I don't want the live stream audio to be cached.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200517/7f8fea10/attachment.htm>

From kitwithnail at mailbox.org  Mon May 18 09:28:00 2020
From: kitwithnail at mailbox.org (Kit)
Date: Mon, 18 May 2020 10:28:00 +0100
Subject: [Icecast] IceS segmentation fault
In-Reply-To: <F67E2F54-C49E-4102-912E-80D61BFF4062@gmail.com>
References: <C2E84E05-486B-4981-947D-C6DCEB0A27F6@mailbox.org>
 <F67E2F54-C49E-4102-912E-80D61BFF4062@gmail.com>
Message-ID: <9B4B9106-2951-41CF-874A-3311D0AD556D@mailbox.org>

Thank you for this and for XML advice (I?ve cleaned it up and same issue remains). 
How do I obtain a stacktrace?

Thanks,

Kit


> On 16 May 2020, at 16:49, Marvin Scholz <epirat07 at gmail.com> wrote:
> 
> Please obtain a stacktrace as the log seems not very
> helpful in this case to figure out what went wrong.
> 
> On 16 May 2020, at 16:52, Kit wrote:
> 
> I get a segmentation fault when starting the IceS encoder on a Linux-based QNAP NAS.
> 
> I'm trying to set up IceS to stream an ALSA input to Icecast. Icecast works well and confirms when I stream using other things to it. However IceS hits a segmentation fault immediately after starting the encoder.
> The IceS log is:
> 
> [~] # sudo ices /etc/ices.xml
> [2020-05-11  19:24:34] INFO ices-core/main IceS 2.0.2 started...
> [2020-05-11  19:24:34] INFO input-alsa/alsa_open_module Opened audio device hw:0,0
> [2020-05-11  19:24:34] INFO input-alsa/alsa_open_module using 2 channel(s), 48000 Hz, buffer 341 ms 
> [2020-05-11  19:24:34] INFO input-alsa/alsa_open_module Starting metadata update thread
> [2020-05-11  19:24:34] INFO signals/signal_usr1_handler Metadata update requested
> [2020-05-11  19:24:34] INFO encode/encode_initialise Encoder initialising with bitrate management: 2 channels, 48000 Hz, minimum bitrate 256000, nominal 320000, maximum 320000
> Segmentation fault
> The IceS config file looks like this:
> 
> <?xml version="1.0"?>
> <ices>
> 
> <background>0</background>
> <logpath>/share/4a Downloads temporary</logpath>
> <logfile>ices.log</logfile>
> <logsize>10000</logsize>
> <loglevel>4</loglevel>
> <consolelog>1</consolelog>
> <!-- <pidfile>/share/4a Downloads temporary/ices.pid</pidfile> -->
> 
> <stream>
>         <metadata>
>                 <name>Roon</name>
>                 <genre>Avant-garde</genre>
>                 <description>Roon Icecast stream</description>
>         </metadata>
> 
>         <input>
>         <module>alsa</module>
>                 <param name="rate">48000</param>
>                 <param name="channels">2</param>
>                 <param name="device">hw:0</param>
>                 <param name="periods">2</param>
>                 <param name="buffer-time">1000</param>
>                 <!-- <param name="metadata">1</param>
>                 <param name="metadatafilename">/home/ices/metadata</param> -->
>         </input>
> 
>         <instance>
>                 <hostname>localhost</hostname>
>                 <port>8000</port>
>                 <password>mirror</password>
>                 <mount>/test.ogg</mount>
>                 <encode>
>                         <quality>10</quality>-->
>                         <nominal-bitrate>320000</nominal-bitrate>
>                         <maximum-bitrate>320000</maximum-bitrate>
>                         <minimum-bitrate>256000</minimum-bitrate>-->
>                         <managed>1</managed>
>                         <samplerate>48000</samplerate>
>                         <channels>2</channels>
>                         <flush-samples>48000</flush-samples>
>                 </encode>
>         </instance>
> </stream>
> 
> </ices>
> I've changed nearly every parameter in it to see if I can get round it, but all I am able to achieve is causing a crash sooner than the segfault. I've also got no more logging than this - level 4 is max anyway - so I can only assume the fault is in the encoder. libvorbis and libogg are both installed. I don't know of any way to use an external encoder or I'd be using that... can anyone help with what might be causing this segfault?
> 
> Thanks!
> 
> 
> 
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast <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/20200518/065162b3/attachment.htm>

From gavin at stephens.net.nz  Wed May 20 15:17:22 2020
From: gavin at stephens.net.nz (Gavin Stephens)
Date: Thu, 21 May 2020 03:17:22 +1200
Subject: [Icecast] Clients, not always connecting since about 2.4.1, 2.4.2.
Message-ID: <19792852-9ad5-74c4-c9aa-9b31f815b41c@stephens.net.nz>

I'll get around to putting Wireshark on and seeing what's going on, 
perhaps someone else has already noticed this:

Since I upgraded to 2.4.2 Win32 (used to use a kh branch version 
previously) and then on to 2.4.4 Win32, I've been noticing clients don't 
always connect successfully. VLC or Muses player does this out of every 
dozen connection attempts, sometimes as few as 2 or 3. I've double 
checked firewalls on the server and on the NAT router and everything 
seems okay. The same issue happens internally on LAN IP's from another 
LAN client.

Normally I don't worry about it, but I had some comments about how long 
the stream I have was taking to buffer. I later put it down to 
re-connection attempts by the web player I'm using so have started to 
re-investigate this.

So I hunted out a 2.4.0 kh8 server found here 
http://radionz-ice.streamguys.com/ (don't know what OS) and these 
streams switch seamlessly without any connection problems. No matter how 
many times I re-start the stream. So if I go clean out the 2.4.4 files 
and directory and install 2.4.0 kh8 on the server here, the problem goes 
away.

I then went looking for a 2.4.2 server (I don't know what OS), and I've 
struck the same problem with connecting to theirs 
http://icecast.mediaworks.nz/. Now I realise this particular server's 
links are mis-configured for port 8000 when the server is on port 80. 
However, this is a known server version I already knew where to find. 
Typing the link in by hand with the correct port works but it doesn't 
always connect, similar to the issue I'm having on 2.4.4 Win32 on the 
server above here.

Has anyone come across this yet? I'm considering rolling back to the 
earlier kh8 Win32 branch like Radio NZ are using above to fix this.


Cheers,

Gavin.




-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



From gavin at stephens.net.nz  Wed May 20 15:49:21 2020
From: gavin at stephens.net.nz (Gavin Stephens)
Date: Thu, 21 May 2020 03:49:21 +1200
Subject: [Icecast] Clients, not always connecting since about 2.4.1,
 2.4.2.
In-Reply-To: <19792852-9ad5-74c4-c9aa-9b31f815b41c@stephens.net.nz>
References: <19792852-9ad5-74c4-c9aa-9b31f815b41c@stephens.net.nz>
Message-ID: <5e6909ee-7dc2-d34d-246b-e3bd02edd9e6@stephens.net.nz>

I can confirm it doesn't happen on kh13 Win32 build either. I think it 
was introduced about 2.4.1/2 in the normal version.

On 21/05/2020 3:17 am, Gavin Stephens wrote:
> I'll get around to putting Wireshark on and seeing what's going on, 
> perhaps someone else has already noticed this:
>
> Since I upgraded to 2.4.2 Win32 (used to use a kh branch version 
> previously) and then on to 2.4.4 Win32, I've been noticing clients 
> don't always connect successfully. VLC or Muses player does this out 
> of every dozen connection attempts, sometimes as few as 2 or 3. I've 
> double checked firewalls on the server and on the NAT router and 
> everything seems okay. The same issue happens internally on LAN IP's 
> from another LAN client.
>
> Normally I don't worry about it, but I had some comments about how 
> long the stream I have was taking to buffer. I later put it down to 
> re-connection attempts by the web player I'm using so have started to 
> re-investigate this.
>
> So I hunted out a 2.4.0 kh8 server found here 
> http://radionz-ice.streamguys.com/ (don't know what OS) and these 
> streams switch seamlessly without any connection problems. No matter 
> how many times I re-start the stream. So if I go clean out the 2.4.4 
> files and directory and install 2.4.0 kh8 on the server here, the 
> problem goes away.
>
> I then went looking for a 2.4.2 server (I don't know what OS), and 
> I've struck the same problem with connecting to theirs 
> http://icecast.mediaworks.nz/. Now I realise this particular server's 
> links are mis-configured for port 8000 when the server is on port 80. 
> However, this is a known server version I already knew where to find. 
> Typing the link in by hand with the correct port works but it doesn't 
> always connect, similar to the issue I'm having on 2.4.4 Win32 on the 
> server above here.
>
> Has anyone come across this yet? I'm considering rolling back to the 
> earlier kh8 Win32 branch like Radio NZ are using above to fix this.
>
>
> Cheers,
>
> Gavin.
>
>
>
>

-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



From phschafft at de.loewenfelsen.net  Thu May 21 08:07:23 2020
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Thu, 21 May 2020 08:07:23 +0000
Subject: [Icecast] Clients, not always connecting since about 2.4.1,
 2.4.2.
In-Reply-To: <5e6909ee-7dc2-d34d-246b-e3bd02edd9e6@stephens.net.nz>
References: <19792852-9ad5-74c4-c9aa-9b31f815b41c@stephens.net.nz>
 <5e6909ee-7dc2-d34d-246b-e3bd02edd9e6@stephens.net.nz>
Message-ID: <1590048443.1915.122.camel@de.loewenfelsen.net>

Good morning,


On Thu, 2020-05-21 at 03:49 +1200, Gavin Stephens wrote:
> I can confirm it doesn't happen on kh13 Win32 build either. I think it 
> was introduced about 2.4.1/2 in the normal version.

First of all, please note that there is no such thing as a "kh branch".
The Icecast-kh software is a different software by a different vendor.
It's not part of the Icecast project. Also it can hardly compared to
Icecast when it comes to bugs as the codebase is a different one.


About your problem:
I'm not aware of anything like this. What is the error returned by the
player? what is in the access.log and the error.log about those connect
attempts?

Also, is your stream publicly accessible? Would allow us to have a look
and maybe find something.

It might also be wise to post your config file with *only* the passwords
removed.

With best regards,


> On 21/05/2020 3:17 am, Gavin Stephens wrote:
> > I'll get around to putting Wireshark on and seeing what's going on, 
> > perhaps someone else has already noticed this:
> >
> > Since I upgraded to 2.4.2 Win32 (used to use a kh branch version 
> > previously) and then on to 2.4.4 Win32, I've been noticing clients 
> > don't always connect successfully. VLC or Muses player does this out 
> > of every dozen connection attempts, sometimes as few as 2 or 3. I've 
> > double checked firewalls on the server and on the NAT router and 
> > everything seems okay. The same issue happens internally on LAN IP's 
> > from another LAN client.
> >
> > Normally I don't worry about it, but I had some comments about how 
> > long the stream I have was taking to buffer. I later put it down to 
> > re-connection attempts by the web player I'm using so have started to 
> > re-investigate this.
> >
> > So I hunted out a 2.4.0 kh8 server found here 
> > http://radionz-ice.streamguys.com/ (don't know what OS) and these 
> > streams switch seamlessly without any connection problems. No matter 
> > how many times I re-start the stream. So if I go clean out the 2.4.4 
> > files and directory and install 2.4.0 kh8 on the server here, the 
> > problem goes away.
> >
> > I then went looking for a 2.4.2 server (I don't know what OS), and 
> > I've struck the same problem with connecting to theirs 
> > http://icecast.mediaworks.nz/. Now I realise this particular server's 
> > links are mis-configured for port 8000 when the server is on port 80. 
> > However, this is a known server version I already knew where to find. 
> > Typing the link in by hand with the correct port works but it doesn't 
> > always connect, similar to the issue I'm having on 2.4.4 Win32 on the 
> > server above here.
> >
> > Has anyone come across this yet? I'm considering rolling back to the 
> > earlier kh8 Win32 branch like Radio NZ are using above to fix this.


-- 
Philipp Schafft (CEO/Gesch?ftsf?hrer) 
Telephon: +49.3535 490 17 92

L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
Bickinger Stra?e 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200521/aaaad162/attachment.sig>

From phschafft at de.loewenfelsen.net  Thu May 21 08:10:34 2020
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Thu, 21 May 2020 08:10:34 +0000
Subject: [Icecast] Add metadata to fallback mount?
In-Reply-To: <aed5b87d-4dda-2802-d5cb-87f52c5c71c4@kpov.org>
References: <aed5b87d-4dda-2802-d5cb-87f52c5c71c4@kpov.org>
Message-ID: <1590048634.1915.125.camel@de.loewenfelsen.net>

Good morning,

On Sat, 2020-05-16 at 12:30 -0700, Jack Elliott wrote:
> Hi, I'm pretty sure this isn't going to be possible, but I'll ask. I'd 
> like to add a <stream-title> to my fallback mount so when the main 
> stream mount drops and the fallback kicks in, that the connected player 
> shows a different title.
> 
> Then back again, of course.

The metadata data is in the responsibility of the source client. Icecast
just relays that information. As soon as the client hits the fallback
stream the metadata of the fallback stream is sent to the client.

So, best advice would be to check the configuration of the fallback's
source client.

With best regards,

-- 
Philipp Schafft (CEO/Gesch?ftsf?hrer) 
Telephon: +49.3535 490 17 92

L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
Bickinger Stra?e 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200521/4b7a9dec/attachment.sig>

From that.jack.elliott at gmail.com  Fri May 22 12:52:03 2020
From: that.jack.elliott at gmail.com (Jack Elliott)
Date: Fri, 22 May 2020 05:52:03 -0700
Subject: [Icecast] Add metadata to fallback mount?
In-Reply-To: <1590048634.1915.125.camel@de.loewenfelsen.net>
References: <aed5b87d-4dda-2802-d5cb-87f52c5c71c4@kpov.org>
 <1590048634.1915.125.camel@de.loewenfelsen.net>
Message-ID: <35f36800-377f-d3c3-217e-5acf2c08f99f@kpov.org>


On 5/21/2020 1:10 AM, Philipp Schafft wrote:

> Good morning,
>
> On Sat, 2020-05-16 at 12:30 -0700, Jack Elliott wrote:
>> Hi, I'm pretty sure this isn't going to be possible, but I'll ask. I'd
>> like to add a <stream-title> to my fallback mount so when the main
>> stream mount drops and the fallback kicks in, that the connected player
>> shows a different title.
>>
>> Then back again, of course.
> The metadata data is in the responsibility of the source client. Icecast
> just relays that information. As soon as the client hits the fallback
> stream the metadata of the fallback stream is sent to the client.
>
> So, best advice would be to check the configuration of the fallback's
> source client.
>
> With best regards,
>

Thank you.

In our case, the fallback is an mp3 file. Is there a specific metadata 
"tag" I should use for the identifying string?

-- 
That Jack Elliott
Director of Classical Music Programming
KPOV 88.9 FM High Desert Community radio
(541) 848 7021



From gavin at stephens.net.nz  Fri May 22 18:22:09 2020
From: gavin at stephens.net.nz (Gavin Stephens)
Date: Sat, 23 May 2020 06:22:09 +1200
Subject: [Icecast] Clients, not always connecting since about 2.4.1,
 2.4.2.
Message-ID: <18ea829a-3a52-6244-2773-56b01769f5ff@stephens.net.nz>

Hi Philip,

I'll do more testing and logging over the weekend and see how I go.

At the moment I have 2.4.4 Win32 running on port 9000 @ http://radioinvercargill.nz:9000/  I'm not sure how good this will be from overseas as the queue is only about 8 seconds, burst about 4 seconds. It's adequate for xDSL/Fibre and 4G mobile over here and is on a 450Mbps upstream fibre line. I've tried lower bursts and much bigger queues and visa versa but it's a 288Kbps stream so the burst needs to be quite high to avoid any stuttering for the Muses web player while initially connecting. The only change to the config file is limit section:

     <limits>
         <sources>10</sources>
         <workers>10</workers>
         <clients>250</clients>			(because the server is on a 100Mbps port)
         <queue-size>589824</queue-size>
         <burst-on-connect>1</burst-on-connect>
         <burst-size>294912</burst-size>
      </limits>

I'll adjust the logging level in a moment and do more tests.
  
I have kh8 running on port 8000 while I test a few things out more with 2.4.4 on 9000. I can't remember which version of Icecast I was using when I first started noticing these odd weird connects. I'll have to keep rolling back until it goes away again, it was earlier on in 2.4.x or just before it. I initially switched to kh the first time I struck it earlier on in 2.4.x I think, or just before 2.4. Then came back to 2.4.2 recently and on to 2.4.4 but the odd failed connections still persisted even on the LAN, changed switch port, cable, Ethernet adapter etc...

However some developments tonight: In VLC when the initial connection hangs, the network monitor on the test client machine shows the traffic is still moving at 288Kbps (the stream bitrate). The same thing happens from my mobile phone though. This would suggest VLC is the issue, yet it only does this with 2.4.4 not kh8. The connection doesn't finish to the point audio starts in VLC or the duration timer starts. About every handful of connects. In Muses player though, it simply reports Network Error now and then while trying connect (even on the LAN), disconnects and re-tries in 10 seconds or so. The test Muses player for the 2.4.4 server is this page http://radioinvercargill.nz/index4.htm Both of these maybe client issues and nothing to do with each other either (I need to keep that in mind). The normal website index page is currently using kh8 on port 8000.

I don't know if this observation has anything to do with it either: The port 8000 server (kh8) bursts it's traffic very high on initial connection. From Icecast 2.4.4 server on port 9000, the burst in-house on the same LAN is much lower, not much more than the stream rate and over a longer period, about 4-5 seconds before the stream rate stabilises @ 288, so I wonder if this is why VLC or Muses is acting strange on some connects. I'll roll back a few Icecast server versions to maybe 2.3.x and do some burst speed observations again on the LAN. When it connects here it runs fine, no hick-ups not even from my 4G mobile on data, although I'll be using a lower rate for mobile phones soon. Great quality and reasonably low latency for online within N.Z.


======================


Good morning,


On Thu, 2020-05-21 at 03:49 +1200, Gavin Stephens wrote:
>/I can confirm it doesn't happen on kh13 Win32 build either. I think it />/was introduced about 2.4.1/2 in the normal version. /
First of all, please note that there is no such thing as a "kh branch".
The Icecast-kh software is a different software by a different vendor.
It's not part of the Icecast project. Also it can hardly compared to
Icecast when it comes to bugs as the codebase is a different one.


About your problem:
I'm not aware of anything like this. What is the error returned by the
player? what is in the access.log and the error.log about those connect
attempts?

Also, is your stream publicly accessible? Would allow us to have a look
and maybe find something.

It might also be wise to post your config file with *only* the passwords
removed.

With best regards,




-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200523/31072e49/attachment.htm>

From gavin at stephens.net.nz  Fri May 22 18:28:36 2020
From: gavin at stephens.net.nz (Gavin Stephens)
Date: Sat, 23 May 2020 06:28:36 +1200
Subject: [Icecast] Clients, not always connecting since about 2.4.1,
 2.4.2.
In-Reply-To: <18ea829a-3a52-6244-2773-56b01769f5ff@stephens.net.nz>
References: <18ea829a-3a52-6244-2773-56b01769f5ff@stephens.net.nz>
Message-ID: <85d54a0c-5632-341b-b592-2927788e1752@stephens.net.nz>

...and of course, password and host. Everything else is the same in the 
config.

On 23/05/2020 6:22 am, Gavin Stephens wrote:
> Hi Philip,
>
> I'll do more testing and logging over the weekend and see how I go.
>
> At the moment I have 2.4.4 Win32 running on port 9000 @http://radioinvercargill.nz:9000/   I'm not sure how good this will be from overseas as the queue is only about 8 seconds, burst about 4 seconds. It's adequate for xDSL/Fibre and 4G mobile over here and is on a 450Mbps upstream fibre line. I've tried lower bursts and much bigger queues and visa versa but it's a 288Kbps stream so the burst needs to be quite high to avoid any stuttering for the Muses web player while initially connecting. The only change to the config file is limit section:
>
>      <limits>
>          <sources>10</sources>
>          <workers>10</workers>
>          <clients>250</clients>			(because the server is on a 100Mbps port)
>          <queue-size>589824</queue-size>
>          <burst-on-connect>1</burst-on-connect>
>          <burst-size>294912</burst-size>
>       </limits>
>
> I'll adjust the logging level in a moment and do more tests.
>   
> I have kh8 running on port 8000 while I test a few things out more with 2.4.4 on 9000. I can't remember which version of Icecast I was using when I first started noticing these odd weird connects. I'll have to keep rolling back until it goes away again, it was earlier on in 2.4.x or just before it. I initially switched to kh the first time I struck it earlier on in 2.4.x I think, or just before 2.4. Then came back to 2.4.2 recently and on to 2.4.4 but the odd failed connections still persisted even on the LAN, changed switch port, cable, Ethernet adapter etc...
>
> However some developments tonight: In VLC when the initial connection hangs, the network monitor on the test client machine shows the traffic is still moving at 288Kbps (the stream bitrate). The same thing happens from my mobile phone though. This would suggest VLC is the issue, yet it only does this with 2.4.4 not kh8. The connection doesn't finish to the point audio starts in VLC or the duration timer starts. About every handful of connects. In Muses player though, it simply reports Network Error now and then while trying connect (even on the LAN), disconnects and re-tries in 10 seconds or so. The test Muses player for the 2.4.4 server is this pagehttp://radioinvercargill.nz/index4.htm  Both of these maybe client issues and nothing to do with each other either (I need to keep that in mind). The normal website index page is currently using kh8 on port 8000.
>
> I don't know if this observation has anything to do with it either: The port 8000 server (kh8) bursts it's traffic very high on initial connection. From Icecast 2.4.4 server on port 9000, the burst in-house on the same LAN is much lower, not much more than the stream rate and over a longer period, about 4-5 seconds before the stream rate stabilises @ 288, so I wonder if this is why VLC or Muses is acting strange on some connects. I'll roll back a few Icecast server versions to maybe 2.3.x and do some burst speed observations again on the LAN. When it connects here it runs fine, no hick-ups not even from my 4G mobile on data, although I'll be using a lower rate for mobile phones soon. Great quality and reasonably low latency for online within N.Z.
>
>
> ======================
>
>
> Good morning,
>
>
> On Thu, 2020-05-21 at 03:49 +1200, Gavin Stephens wrote:
> >/I can confirm it doesn't happen on kh13 Win32 build either. I think it />/was introduced about 2.4.1/2 in the normal version. /
> First of all, please note that there is no such thing as a "kh branch".
> The Icecast-kh software is a different software by a different vendor.
> It's not part of the Icecast project. Also it can hardly compared to
> Icecast when it comes to bugs as the codebase is a different one.
>
>
> About your problem:
> I'm not aware of anything like this. What is the error returned by the
> player? what is in the access.log and the error.log about those connect
> attempts?
>
> Also, is your stream publicly accessible? Would allow us to have a look
> and maybe find something.
>
> It might also be wise to post your config file with *only* the passwords
> removed.
>
> With best regards,
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
> 	Virus-free. www.avast.com 
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast


-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200523/8e1bc3ad/attachment.htm>

From gavin at stephens.net.nz  Sat May 23 08:22:44 2020
From: gavin at stephens.net.nz (Gavin Stephens)
Date: Sat, 23 May 2020 20:22:44 +1200
Subject: [Icecast] Clients, not always connecting since about 2.4.1,
 2.4.2.
In-Reply-To: <85d54a0c-5632-341b-b592-2927788e1752@stephens.net.nz>
References: <18ea829a-3a52-6244-2773-56b01769f5ff@stephens.net.nz>
 <85d54a0c-5632-341b-b592-2927788e1752@stephens.net.nz>
Message-ID: <e6bf5ca2-c83e-4019-4313-c9bc69a0818e@stephens.net.nz>

Does anyone know what the max burst size is in 2.4.4?

After installing some traffic flow filters on my router I can see that 
2.4.4 is not bursting the 4 seconds I'm asking it too @288Kbps. I think 
this is where the initial connection problems are happening.



On 23/05/2020 6:28 am, Gavin Stephens wrote:
>
> ...and of course, password and host. Everything else is the same in 
> the config.
>
> On 23/05/2020 6:22 am, Gavin Stephens wrote:
>> Hi Philip,
>>
>> I'll do more testing and logging over the weekend and see how I go.
>>
>> At the moment I have 2.4.4 Win32 running on port 9000 @http://radioinvercargill.nz:9000/   I'm not sure how good this will be from overseas as the queue is only about 8 seconds, burst about 4 seconds. It's adequate for xDSL/Fibre and 4G mobile over here and is on a 450Mbps upstream fibre line. I've tried lower bursts and much bigger queues and visa versa but it's a 288Kbps stream so the burst needs to be quite high to avoid any stuttering for the Muses web player while initially connecting. The only change to the config file is limit section:
>>
>>      <limits>
>>          <sources>10</sources>
>>          <workers>10</workers>
>>          <clients>250</clients>			(because the server is on a 100Mbps port)
>>          <queue-size>589824</queue-size>
>>          <burst-on-connect>1</burst-on-connect>
>>          <burst-size>294912</burst-size>
>>       </limits>
>>
>> I'll adjust the logging level in a moment and do more tests.
>>   
>> I have kh8 running on port 8000 while I test a few things out more with 2.4.4 on 9000. I can't remember which version of Icecast I was using when I first started noticing these odd weird connects. I'll have to keep rolling back until it goes away again, it was earlier on in 2.4.x or just before it. I initially switched to kh the first time I struck it earlier on in 2.4.x I think, or just before 2.4. Then came back to 2.4.2 recently and on to 2.4.4 but the odd failed connections still persisted even on the LAN, changed switch port, cable, Ethernet adapter etc...
>>
>> However some developments tonight: In VLC when the initial connection hangs, the network monitor on the test client machine shows the traffic is still moving at 288Kbps (the stream bitrate). The same thing happens from my mobile phone though. This would suggest VLC is the issue, yet it only does this with 2.4.4 not kh8. The connection doesn't finish to the point audio starts in VLC or the duration timer starts. About every handful of connects. In Muses player though, it simply reports Network Error now and then while trying connect (even on the LAN), disconnects and re-tries in 10 seconds or so. The test Muses player for the 2.4.4 server is this pagehttp://radioinvercargill.nz/index4.htm  Both of these maybe client issues and nothing to do with each other either (I need to keep that in mind). The normal website index page is currently using kh8 on port 8000.
>>
>> I don't know if this observation has anything to do with it either: The port 8000 server (kh8) bursts it's traffic very high on initial connection. From Icecast 2.4.4 server on port 9000, the burst in-house on the same LAN is much lower, not much more than the stream rate and over a longer period, about 4-5 seconds before the stream rate stabilises @ 288, so I wonder if this is why VLC or Muses is acting strange on some connects. I'll roll back a few Icecast server versions to maybe 2.3.x and do some burst speed observations again on the LAN. When it connects here it runs fine, no hick-ups not even from my 4G mobile on data, although I'll be using a lower rate for mobile phones soon. Great quality and reasonably low latency for online within N.Z.
>>
>>
>> ======================
>>
>>
>> Good morning,
>>
>>
>> On Thu, 2020-05-21 at 03:49 +1200, Gavin Stephens wrote:
>> >/I can confirm it doesn't happen on kh13 Win32 build either. I think it />/was introduced about 2.4.1/2 in the normal version. /
>> First of all, please note that there is no such thing as a "kh branch".
>> The Icecast-kh software is a different software by a different vendor.
>> It's not part of the Icecast project. Also it can hardly compared to
>> Icecast when it comes to bugs as the codebase is a different one.
>>
>>
>> About your problem:
>> I'm not aware of anything like this. What is the error returned by the
>> player? what is in the access.log and the error.log about those connect
>> attempts?
>>
>> Also, is your stream publicly accessible? Would allow us to have a look
>> and maybe find something.
>>
>> It might also be wise to post your config file with *only* the passwords
>> removed.
>>
>> With best regards,
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>> 	Virus-free. www.avast.com 
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>>
>>
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> _______________________________________________
>> 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


-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200523/3e8c97fc/attachment.htm>

From mustafejen at gmail.com  Tue May 26 05:10:17 2020
From: mustafejen at gmail.com (Per Gunnarsson)
Date: Tue, 26 May 2020 07:10:17 +0200
Subject: [Icecast] problem creating a systemd service
Message-ID: <d3a60c16-fc2e-9c5e-22cd-766281f5ffa3@gmail.com>

Hello!

Icecast behaves oddly for me in debian testing, somehow the permissions
on my log file directory was set to root:adm if I remember things right.

Also there was no systemd service starting when I tried to start from
/etc/init.d,
somehow init services refer to systemd services nowadays whether they exist
or not.

I tried to create a systemd service looking like this:

[Unit]
Description=icecast2 streaming server
After=network.target tor at default.service
Documentation=http://liquidsoap.fm/

[Service]
Type=forking
User=icecast2
Group=icecast
ExecStart=/usr/local/bin/icecast -c /etc/icecast2/icecast.xml
Restart=on-failure

[Install]
WantedBy=multi-user.target
Alias=icecast2.service




I have this in my icecast log file (both with the debian testing package
and built from source),

[2020-05-26? 06:44:21] INFO main/_server_proc Caught halt request,
shutting down...
[2020-05-26? 06:44:21] INFO main/main Shutting down
[2020-05-26? 06:44:21] INFO fserve/fserve_shutdown file serving stopped
[2020-05-26? 06:44:22] INFO slave/_slave_thread shutting down current relays
[2020-05-26? 06:44:22] INFO slave/_slave_thread Slave thread shutdown
complete
[2020-05-26? 06:44:22] INFO auth/auth_shutdown Auth shutdown
[2020-05-26? 06:44:22] INFO yp/yp_shutdown YP thread down
[2020-05-26? 06:44:22] INFO stats/stats_shutdown stats thread finished
[2020-05-26? 06:44:22] INFO main/main Icecast 2.4.4 server started
[2020-05-26? 06:44:22] INFO yp/yp_recheck_config Adding new YP server
"http://dir.xiph.org/cgi-bin/yp-cgi" (timeout 6s, default interval 30s)
[2020-05-26? 06:44:22] INFO yp/yp_recheck_config Adding new YP server
"http://yp.shoutcast.com" (timeout 6s, default interval 30s)
[2020-05-26? 06:44:22] INFO yp/yp_recheck_config Adding new YP server
"http://icecast-yp.internet-radio.com" (timeout 6s, default interval 30s)
[2020-05-26? 06:44:22] INFO yp/yp_update_thread YP update thread started
[2020-05-26? 06:44:22] INFO connection/get_ssl_certificate SSL
certificate found at /etc/icecast2/icecast.pem
[2020-05-26? 06:44:22] INFO connection/get_ssl_certificate SSL using
ciphers
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
?

In my liquidsoap log file, I have these things.

2020/05/26 06:21:43 [Verket_opus:2] Connection failed: bad answer:
scanf: bad input at char number 0: looking for 'H', found '\021'


2020/05/26 06:48:12 [Verket_opus:3] Connecting mount verket.opus for
source at mustafejen.se...
2020/05/26 06:48:12 [Verket_opus:2] Connection failed: could not read
data from host: Connection reset by peer in read()

2020/05/26 06:47:58 [clock.wallclock_main:2] Error when starting
Verket_opus: File "request.ml", line 507, characters 2-8: Assertion failed!





<icecast>
    <!-- location and admin are two arbitrary strings that are e.g. visible
         on the server info page of the icecast web interface
         (server_version.xsl). -->
    <location>Ersboda</location>
    <admin>mustafejen at gmail.com</admin>

    <!-- IMPORTANT!
         Especially for inexperienced users:
         Start out by ONLY changing all passwords and restarting Icecast.
         For detailed setup instructions please refer to the documentation.
         It's also available here: http://icecast.org/docs/
    -->

    <limits>
        <clients>100</clients>
        <sources>20</sources>
        <queue-size>524288</queue-size>
        <client-timeout>30</client-timeout>
        <header-timeout>30</header-timeout>
        <source-timeout>30</source-timeout>
        <!-- If enabled, this will provide a burst of data when a client 
             first connects, thereby significantly reducing the startup 
             time for listeners that do substantial buffering. However,
             it also significantly increases latency between the source
             client and listening client.  For low-latency setups, you
             might want to disable this. -->
        <burst-on-connect>1</burst-on-connect>
        <!-- same as burst-on-connect, but this allows for being more
             specific on how much to burst. Most people won't need to
             change from the default 64k. Applies to all mountpoints  -->
        <burst-size>65535</burst-size>
    </limits>

    <authentication>
        <!-- Sources log in with username 'source' -->
        <source-password>downloaded_smut</source-password>
        <!-- Relays log in with username 'relay' -->
        <relay-password>good_dope</relay-password>

        <!-- Admin logs in with the username given below -->
        <admin-user>admin</admin-user>
        <admin-password>Nikki_Benz</admin-password>
    </authentication>

    <!-- set the mountpoint for a shoutcast source to use, the default if not
         specified is /stream but you can change it here if an alternative is
         wanted or an extension is required
    <shoutcast-mount>/live.nsv</shoutcast-mount>
    -->

    <!-- Uncomment this if you want directory listings -->
    <directory>
        <yp-url-timeout>30</yp-url-timeout>
        <yp-url>http://dir.xiph.org/cgi-bin/yp-cgi</yp-url>
    </directory>

    <directory>
        <yp-url-timeout>30</yp-url-timeout>
        <yp-url>http://yp.shoutcast.com</yp-url>
    </directory>

	<directory>
                <yp-url-timeout>30</yp-url-timeout>
                <yp-url>http://icecast-yp.internet-radio.com</yp-url>
        </directory>


    <!-- This is the hostname other people will use to connect to your server.
         It affects mainly the urls generated by Icecast for playlists and yp
         listings. You MUST configure it properly for YP listings to work!
    -->
    <hostname>mustafejen.se</hostname>

    <!-- You may have multiple <listener> elements -->
    <listen-socket>
        <port>8000</port>
        <!-- <bind-address>127.0.0.1</bind-address> -->
        <!-- <shoutcast-mount>/stream</shoutcast-mount> -->
    </listen-socket>

    <listen-socket>
        <port>8001</port>
    </listen-socket>

    <listen-socket>
        <port>8002</port>
    </listen-socket>



    <!--
    <listen-socket>
        <port>8080</port>
    </listen-socket>
    -->


	<listen-socket>
        <port>8443</port>
	<ssl>1</ssl>
	</listen-socket>

	<listen-socket>
        <port>8444</port>
	<ssl>1</ssl>
	</listen-socket>


    <!-- Global header settings 
         Headers defined here will be returned for every HTTP request to Icecast.

         The ACAO header makes Icecast public content/API by default
         This will make streams easier embeddable (some HTML5 functionality needs it).
         Also it allows direct access to e.g. /status-json.xsl from other sites.
         If you don't want this, comment out the following line or read up on CORS. 
    -->
    <http-headers>
        <header name="Access-Control-Allow-Origin" value="*" />
    </http-headers>

<!--
    Relaying
         You don't need this if you only have one server.
         Please refer to the config for a detailed explanation.
    
    <master-server>10.0.0.3</master-server>
    <master-server-port>8004</master-server-port>
    <master-update-interval>120</master-update-interval>
    <master-password>hackme</master-password>

	relay	-->

<!-- echomoscow 

    <relay>
        <server>ice912.echo.msk.ru</server>
        <port>9120</port>
        <mount>/stream</mount>
        <local-mount>/stream</local-mount>
        <on-demand>0</on-demand>

        <relay-shoutcast-metadata>0</relay-shoutcast-metadata>
    </relay>

	 echomoscow	-->



<!--

    <relay>
        <server>stations.pacifica.org</server>
        <port>8000</port>
        <mount>/kpfa_64</mount>
        <local-mount>/kpfa_64</local-mount>
        <on-demand>0</on-demand>

        <relay-shoutcast-metadata>1</relay-shoutcast-metadata>
    </relay>

	kpfa	-->

    <!-- setting this makes all relays on-demand unless overridden, this is
         useful for master relays which do not have <relay> definitions here.
         The default is 0 -->
    <!--<relays-on-demand>1</relays-on-demand>-->

    <!--
    <relay>
        <server>127.0.0.1</server>
        <port>8080</port>
        <mount>/example.ogg</mount>
        <local-mount>/different.ogg</local-mount>
        <on-demand>0</on-demand>

        <relay-shoutcast-metadata>0</relay-shoutcast-metadata>
    </relay>
    -->


    <!-- Mountpoints
         Only define <mount> sections if you want to use advanced options,
         like alternative usernames or passwords
    -->

    <!-- Default settings for all mounts that don't have a specific <mount type="normal">.
    -->
    <!-- 
    <mount type="default">
        <public>0</public>
        <intro>/server-wide-intro.ogg</intro>
        <max-listener-duration>3600</max-listener-duration>
        <authentication type="url">
                <option name="mount_add" value="http://auth.example.org/stream_start.php"/>
        </authentication>
        <http-headers>
                <header name="foo" value="bar" />
        </http-headers>
    </mount>
    -->

    <!-- Normal mounts -->


    <mount>
        <mount-name>/verketlive.ogg</mount-name>

        <username>source</username>
        <password>Agent_420</password>

        <max-listeners>40</max-listeners>
        <burst-size>65536</burst-size>
        <hidden>0</hidden>
        <no-yp>0</no-yp>
    </mount>


    <mount>
        <mount-name>/fest</mount-name>
        <max-listeners>40</max-listeners>
        <burst-size>65536</burst-size>
        <hidden>0</hidden>
        <no-yp>0</no-yp>
    </mount>


    <mount type="normal">
    <mount-name>/feting</mount-name>
    <public>1</public>
    <stream-name>This stream has moved</stream-name>
    <stream-description>This stream has moved</stream-description>
    <stream-url>http://76qugh5bey5gum7l.onion/geezer</stream-url>
    <genre>silence</genre>
    <bitrate>128</bitrate>
    <type>audio/mpeg</type>
    <hidden>0</hidden>
    <burst-size>65536</burst-size>
    </mount>

    <mount type="normal">
    <mount-name>/pausmusik</mount-name>
    <public>1</public>
    <stream-name>Oh no!</stream-name>
    <stream-description>Something went wrong</stream-description>
    <stream-url>https://mustafejen.se/~per</stream-url>
    <genre>Test stream</genre>
    <bitrate>128</bitrate>
    <type>audio/mpeg</type>
    <hidden>0</hidden>
    <burst-size>65536</burst-size>
    </mount>


    <mount type="normal">
    <mount-name>/stream.opus</mount-name>
    <public>1</public>
    <stream-name>mustafejen opus</stream-name>
    <stream-description>Stream from Ersboda</stream-description>
    <stream-url>https://mustafejen.se/~per</stream-url>
    <genre>Alternative, eclectic</genre>
    <bitrate>32</bitrate>
    <type>audio/ogg</type>
    <subtype>opus</subtype>
    <hidden>0</hidden>
    <burst-size>65536</burst-size>
    </mount>

<!--
    <mount type="normal">
    <mount-name>/stream.opus</mount-name>
    <public>1</public>
    <stream-name>mustafejen opus</stream-name>
    <stream-description>Stream from Ersboda</stream-description>
    <stream-url>https://mustafejen.se/~per</stream-url>
    <genre>Alternative, eclectic</genre>
    <bitrate>32</bitrate>
    <type>audio/opus</type>
    <hidden>0</hidden>
    <burst-size>65536</burst-size>
    </mount>
-->


    <mount type="normal">
    <mount-name>/pausmusik.opus</mount-name>
    <public>1</public>
    <stream-name>Oh no!</stream-name>
    <stream-description>Something went wrong</stream-description>
    <stream-url>https://mustafejen.se/~per</stream-url>
    <genre>Test stream</genre>
    <bitrate>32</bitrate>
    <type>audio/ogg</type>
    <subtype>opus</subtype>
    <hidden>0</hidden>
    <burst-size>65536</burst-size>
    </mount>


    <mount type="normal">
    <mount-name>/verket.opus</mount-name>
    <public>1</public>
    <stream-name>Verket opus</stream-name>
    <stream-description>Bands from Verket</stream-description>
    <stream-url>http://verketumea.se</stream-url>
    <genre>Mainly Punk</genre>
    <bitrate>64</bitrate>
    <type>audio/ogg</type>
    <subtype>opus</subtype>
    <hidden>0</hidden>
    <burst-size>65536</burst-size>
    </mount>

    <mount type="normal">
    <mount-name>/desktop.webm</mount-name>
    <public>1</public>
    <stream-name>penner</stream-name>
    <stream-description>Der Penner</stream-description>
    <stream-url>https://mustafejen.se/~per</stream-url>
    <genre>Domestic</genre>
    <bitrate>1500</bitrate>
    <type>video/webm</type>
    <subtype>webm</subtype>
    <hidden>0</hidden>
    <burst-size>65536</burst-size>
    </mount>


<!--	test	

    <mount>

        <mount-name>/tomte.ogg</mount-name>

<authentication type="htpasswd">
	<option name="filename" value="/etc/icecast2/.htpasswd"/>
	<option name="allow_duplicate_users" value="0"/>
	</authentication>
    <http-headers>
            <header name="Content-Type" value="audio/ogg" status="200" />
    </http-headers>
        <username>source</username>
        <password>Ivar_fultjackar</password>

        <burst-size>65536</burst-size>
        <hidden>0</hidden>
        <no-yp>0</no-yp>
	
    </mount>

-->


    <mount type="normal">
    <mount-name>/darkson.opus</mount-name>
    <public>1</public>
    <stream-name>Dark Sonnet opus</stream-name>
    <stream-description>Dark Sonnets</stream-description>
    <stream-url>Vet ej vilken hemsida</stream-url>
    <genre>Various</genre>
    <bitrate>64</bitrate>
    <type>audio/ogg</type>
    <subtype>opus</subtype>
    <hidden>0</hidden>
    <burst-size>65536</burst-size>
    </mount>

<!--	Dark sonnets klart	-->


<!--	test opus mount	-->

    <mount type="normal">
    <mount-name>/tomte.opus</mount-name>
    <public>1</public>
    <stream-name>test opus</stream-name>
    <stream-description>bara en teststr?m</stream-description>
    <stream-url>Vet ej vilken hemsida</stream-url>
    <genre>Various</genre>
    <bitrate>256</bitrate>
    <type>audio/ogg</type>
    <subtype>opus</subtype>
    <hidden>0</hidden>
    <burst-size>65536</burst-size>
    </mount>

<!--	end test opus mount	-->


    <fileserve>1</fileserve>

    <paths>
        <!-- basedir is only used if chroot is enabled -->
        <basedir>/usr/share/icecast2</basedir>

        <!-- Note that if <chroot> is turned on below, these paths must both
             be relative to the new root, not the original root -->
        <logdir>/var/log/icecast2</logdir>
        <webroot>/usr/share/icecast2/web</webroot>
        <adminroot>/usr/share/icecast2/admin</adminroot>
        <!-- <pidfile>/usr/share/icecast2/icecast.pid</pidfile> -->

        <!-- Aliases: treat requests for 'source' path as being for 'dest' path
             May be made specific to a port or bound address using the "port"
             and "bind-address" attributes.
          -->
        <!--
        <alias source="/foo" destination="/bar"/>
        -->
        <!-- Aliases: can also be used for simple redirections as well,
             this example will redirect all requests for http://server:port/ to
             the status page
        -->
        <alias source="/" destination="/status.xsl"/>


        <ssl-certificate>/etc/icecast2/icecast.pem</ssl-certificate>
	<ssl-allowed-ciphers>ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS</ssl-allowed-ciphers>

    </paths>

    <logging>
        <accesslog>access.log</accesslog>
        <errorlog>error.log</errorlog>
        <!-- <playlistlog>playlist.log</playlistlog> -->
        <loglevel>3</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
        <logsize>10000</logsize> <!-- Max size of a logfile -->
        <!-- If logarchive is enabled (1), then when logsize is reached
             the logfile will be moved to [error|access|playlist].log.DATESTAMP,
             otherwise it will be moved to [error|access|playlist].log.old.
             Default is non-archive mode (i.e. overwrite)
        -->
        <!-- <logarchive>1</logarchive> -->
    </logging>

    <security>
        <chroot>0</chroot>
        <!--
        <changeowner>
            <user>nobody</user>
            <group>nogroup</group>
        </changeowner>
        -->
    </security>
</icecast>







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200526/329cfe8d/attachment.htm>

From dafilez5 at gmail.com  Tue May 26 16:26:49 2020
From: dafilez5 at gmail.com (DA BACKUPZ)
Date: Tue, 26 May 2020 12:26:49 -0400
Subject: [Icecast] Help with Statistical Relay info.
Message-ID: <CAAQ4HpM-hp2eWsbKB+TeOxjiLLA1eH198pXLmJgJSEt3T7bbRg@mail.gmail.com>

Hello,

I am using an external streaming client, known as SAM Broadcaster, and I
would like to set up a statistical relay to "get" or show the number of
listeners. This does not seem to work with the information entered from my
iceast details, does this server, icecast2 (2.4.3), not support statistical
relay "get" info?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200526/effd98a5/attachment.htm>

From pm at nowster.me.uk  Thu May 28 22:34:14 2020
From: pm at nowster.me.uk (Paul Martin)
Date: Thu, 28 May 2020 23:34:14 +0100
Subject: [Icecast] problem creating a systemd service
In-Reply-To: <d3a60c16-fc2e-9c5e-22cd-766281f5ffa3@gmail.com>
References: <d3a60c16-fc2e-9c5e-22cd-766281f5ffa3@gmail.com>
Message-ID: <20200528223414.GA187862@thinkpad.nowster.org.uk>

On Tue, May 26, 2020 at 07:10:17AM +0200, Per Gunnarsson wrote:
> Icecast behaves oddly for me in debian testing, somehow the permissions
> on my log file directory was set to root:adm if I remember things right.

I'm running 2.4.4-3 (unstable/testing) too, and it works fine out of
the box.

/var/log/icecast2 is supposed to be owned by icecast2:adm

> Also there was no systemd service starting when I tried to start from
> /etc/init.d,
> somehow init services refer to systemd services nowadays whether they exist
> or not.

Don't bother with a systemd service file.  It'll be fine with
/etc/init.d/icecast2 for the moment.  Don't forget to edit
/etc/default/icecast2 to enable it.

> In my liquidsoap log file, I have these things.
> 
> 2020/05/26 06:21:43 [Verket_opus:2] Connection failed: bad answer:
> scanf: bad input at char number 0: looking for 'H', found '\021'

You want to point liquidsoap at a non-SSL port.  It doesn't do SSL.

Also, if you're installing from Debian, icecast2's executable is at
/usr/bin/icecast2, not /usr/local/bin/icecast2

-- 
Paul Martin <pm at nowster.me.uk>


From phschafft at de.loewenfelsen.net  Fri May 29 11:40:20 2020
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Fri, 29 May 2020 11:40:20 +0000
Subject: [Icecast] Add metadata to fallback mount?
In-Reply-To: <35f36800-377f-d3c3-217e-5acf2c08f99f@kpov.org>
References: <aed5b87d-4dda-2802-d5cb-87f52c5c71c4@kpov.org>
 <1590048634.1915.125.camel@de.loewenfelsen.net>
 <35f36800-377f-d3c3-217e-5acf2c08f99f@kpov.org>
Message-ID: <1590752420.2378.68.camel@de.loewenfelsen.net>

Good afternoon,

On Fri, 2020-05-22 at 05:52 -0700, Jack Elliott wrote:
> On 5/21/2020 1:10 AM, Philipp Schafft wrote:
> > On Sat, 2020-05-16 at 12:30 -0700, Jack Elliott wrote:
> >> Hi, I'm pretty sure this isn't going to be possible, but I'll ask. I'd
> >> like to add a <stream-title> to my fallback mount so when the main
> >> stream mount drops and the fallback kicks in, that the connected player
> >> shows a different title.
> >>
> >> Then back again, of course.
> > The metadata data is in the responsibility of the source client. Icecast
> > just relays that information. As soon as the client hits the fallback
> > stream the metadata of the fallback stream is sent to the client.
> >
> > So, best advice would be to check the configuration of the fallback's
> > source client.
> >
> > With best regards,
> >
> 
> Thank you.
> 
> In our case, the fallback is an mp3 file. Is there a specific metadata 
> "tag" I should use for the identifying string?

I think there is some misunderstanding here:
When you set a file as fallback Icecast will just send that file as if
serving it by a direct request. This comes with two effects:
      * Icecast will send it as fast as it can. Sending at "the correct
        speed" is not something Icecast manages. It always forwards data
        as fast as it can. Sending at a real time speed is part of the
        source client's work. And as your disk is normally much faster
        than your network connection Icecast will send it with full
        speed.
      * For legacy codecs only: Legacy codecs (that is MP3 and AAC) do
        not implement metadata at all. If stored in a file it ID3 is
        used. ID3 however is a container that contains the actual file.
        Exactly like a Zip file contains other files. However ID3 can
        not be streamed. Trying to do so may or may not break listener
        clients. For streaming Nullsoft invented a, also legacy protocol
        called ICY. Icecast uses this for MP3 and AAC if requested by
        the client. This protocol contains (crippled) metadata. However
        as it is a network protocol it can not be used for storage.

Long story short: It is generally recommended to have a local source
client that serves the fallback. Otherwise timing will break.
For legacy codecs it is also important as there can not be metadata
without a proper source client.


I hope that helps. :)

With best regards,

-- 
Philipp Schafft (CEO/Gesch?ftsf?hrer) 
Telephon: +49.3535 490 17 92

L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
Bickinger Stra?e 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200529/8afd745e/attachment.sig>

From gilliano at tinyworld.co.uk  Fri May 29 15:20:06 2020
From: gilliano at tinyworld.co.uk (Les Durno)
Date: Fri, 29 May 2020 16:20:06 +0100 (BST)
Subject: [Icecast] Icecast Stream Keeps Repeating Sent Friday 29th May 2020
 At: 16.19.hrs. GMT
Message-ID: <897141340.37843.1590765607060@apps.talktalk.co.uk>

Hello Icecast,  

I have successfully done a test audio stream to the free, "Icecast," server.

However, when I stop my audio source, after some seconds, eg, ten, then once that audio stream

has finished, after about six seconds the audio stream repeats playing, then does so after the same

time interval, again for many times. Each time the volume of these repetitions, decreases.

Even when I allow the stream to continue, then the repetitions are heard over the ongoing stream.

I  am using the, "BUTT," encoder, version, 0.1.16. I have muted my mic and tried muting my speakers,

however that has not solved this issue. I am using the newest version of Icecast: 2.4.4.  

Also when I change localhost between the tags, <hostname>localhost</hostname> to another name,

the HTML5 audio player appears on my test web page and then disappears.

When I restore the local host name both in the XML config file and the URL HTML5 source code in my

web page, then the audio player is receiving the stream. My OS is: XP SP3.  

I look forward to your guidance,  

Best regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200529/63cf379b/attachment.htm>

From that.jack.elliott at gmail.com  Fri May 29 16:39:29 2020
From: that.jack.elliott at gmail.com (Jack Elliott)
Date: Fri, 29 May 2020 09:39:29 -0700
Subject: [Icecast] Add metadata to fallback mount?
In-Reply-To: <1590752420.2378.68.camel@de.loewenfelsen.net>
References: <aed5b87d-4dda-2802-d5cb-87f52c5c71c4@kpov.org>
 <1590048634.1915.125.camel@de.loewenfelsen.net>
 <35f36800-377f-d3c3-217e-5acf2c08f99f@kpov.org>
 <1590752420.2378.68.camel@de.loewenfelsen.net>
Message-ID: <8cde6ca7-e593-19c2-1948-2360de9ce7ad@kpov.org>


On 5/29/2020 4:40 AM, Philipp Schafft wrote:
> Good afternoon,
>
> On Fri, 2020-05-22 at 05:52 -0700, Jack Elliott wrote:
>> On 5/21/2020 1:10 AM, Philipp Schafft wrote:
>>> On Sat, 2020-05-16 at 12:30 -0700, Jack Elliott wrote:
>>>> Hi, I'm pretty sure this isn't going to be possible, but I'll ask. I'd
>>>> like to add a <stream-title> to my fallback mount so when the main
>>>> stream mount drops and the fallback kicks in, that the connected player
>>>> shows a different title.
>>>>
>>>> Then back again, of course.
>>> The metadata data is in the responsibility of the source client. Icecast
>>> just relays that information. As soon as the client hits the fallback
>>> stream the metadata of the fallback stream is sent to the client.
>>>
>>> So, best advice would be to check the configuration of the fallback's
>>> source client.
>>>
>>> With best regards,
>>>
>> Thank you.
>>
>> In our case, the fallback is an mp3 file. Is there a specific metadata
>> "tag" I should use for the identifying string?
> I think there is some misunderstanding here:
> When you set a file as fallback Icecast will just send that file as if
> serving it by a direct request. This comes with two effects:
>        * Icecast will send it as fast as it can. Sending at "the correct
>          speed" is not something Icecast manages. It always forwards data
>          as fast as it can. Sending at a real time speed is part of the
>          source client's work. And as your disk is normally much faster
>          than your network connection Icecast will send it with full
>          speed.
>        * For legacy codecs only: Legacy codecs (that is MP3 and AAC) do
>          not implement metadata at all. If stored in a file it ID3 is
>          used. ID3 however is a container that contains the actual file.
>          Exactly like a Zip file contains other files. However ID3 can
>          not be streamed. Trying to do so may or may not break listener
>          clients. For streaming Nullsoft invented a, also legacy protocol
>          called ICY. Icecast uses this for MP3 and AAC if requested by
>          the client. This protocol contains (crippled) metadata. However
>          as it is a network protocol it can not be used for storage.
>
> Long story short: It is generally recommended to have a local source
> client that serves the fallback. Otherwise timing will break.
> For legacy codecs it is also important as there can not be metadata
> without a proper source client.
>
>
> I hope that helps. :)
>
> With best regards,

Thank you.

Perhaps it would be better for me to explain my goal.

Our Icecast server is used by our radio station hosts to send live shows 
from their home studios. Normally they would do their shows from within 
the radio station, but with COVID-19 they are urged to stay home and 
connect to the Icecast server using their personal mixers, encoders, etc.

When a host connects as a source-mount the Icecast server makes their 
stream available on the station's LAN. In the broadcast studio, when it 
is time to broadcast the show, our radio automation software (in our 
case, Rogue Amoeba's "MegaSeg" playout software), connects as a 
listen-client and thereby sends the remote stream to the FM transmitter 
and to our listening audience.

If the source-client is not yet connected (maybe she is late with her 
show), the listen-client still must be able to connect even if there is 
no audio. Else if she comes in a bit later, the listen-client may have 
disconnected.

_So my first question_ is what happens when the listen-client connects 
to the mountpoint when there is no source-client connected. Is there a 
"silent stream", or is there nothing?

We need the stream to be always available for the listen-client to 
connect to, even if there is no source-client mounted, or if the 
source-client disconnects early, possible due to internet congestion.

To assure that there is a stream to connect to I have a silent mp3 as a 
fallback, so even if the source-client is not connected, the 
listen-client still has a stream to connect to.

Is this necessary?

-- 
That Jack Elliott
Director of Classical Music Programming
KPOV 88.9 FM High Desert Community radio
(541) 848 7021

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200529/eb2c5cdf/attachment.htm>

From jordan at coolmic.net  Fri May 29 16:48:23 2020
From: jordan at coolmic.net (Jordan Erickson)
Date: Fri, 29 May 2020 09:48:23 -0700
Subject: [Icecast] Icecast Stream Keeps Repeating Sent Friday 29th May
 2020 At: 16.19.hrs. GMT
In-Reply-To: <897141340.37843.1590765607060@apps.talktalk.co.uk>
References: <897141340.37843.1590765607060@apps.talktalk.co.uk>
Message-ID: <02d18be7-4108-2eaf-785d-7b168664b560@coolmic.net>

Hi,


On 5/29/20 8:20 AM, Les Durno wrote:
> However, when I stop my audio source, after some seconds, eg, ten, then
> once that audio stream has finished, after about six seconds the audio stream repeats playing,
> then does so after the same time interval, again for many times. Each time the volume of these
> repetitions, decreases.

This sounds like a listener client issue. It makes sense to me, it
sounds like you're listening through a browser, is that correct? It is
likely re-playing through the cache it received since the stream stopped
suddenly. The only thing that comes to mind is that your URL should be
unique per every stream instance (like if Icecast stops streaming then
starts again, generate a unique URL.)

Take a look at this:
https://impactjs.com/forums/help/nocache-how-to-force-user-page-to-refresh-in-order-to-load-my-updated-changes/page/1


Cheers,
Jordan


From gilliano at tinyworld.co.uk  Fri May 29 19:54:16 2020
From: gilliano at tinyworld.co.uk (Les Durno)
Date: Fri, 29 May 2020 20:54:16 +0100 (BST)
Subject: [Icecast] Re Jordan's Reply Icecast Stream Keeps Repeating Sent
 Friday 29th May 2020 At: 20.54.hrs GMT
Message-ID: <172509776.43373.1590782056429@apps.talktalk.co.uk>

Hello Jordan,

Many thanks for your prompt reply with your advice.

I created a web page with only an HTML5 audio player, ( The page being on my desktop ),

with the listening URL stream source code. I started a test stream and a few seconds

later the stream was playing on my audio player, on my page, although with the audio repetitions

being heard after about six seconds.So I thought that this issue was because of

some, "Loop," effect on my PC. I then uploaded my test web page to my website host

thinking that this might solve this issue, however this did not work and the audio repetitions

were still being heard. Another thing was, that I sent a link for my test web page to two friends,

however they both stated that they were not receiving my audio stream, from the audio player,

although I could hear my stream, when I had my web page up on my website.

I trust that I can correct this challenge. I am fairly new to streaming. I am very grateful to

you for taking the time to respond with your guidance.

Best regards, Les.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200529/b4caea70/attachment.htm>

From railgun.michael at gmail.com  Sat May 30 08:44:19 2020
From: railgun.michael at gmail.com (Railgun)
Date: Sat, 30 May 2020 10:44:19 +0200
Subject: [Icecast] mounpoint to antoher port
Message-ID: <f79228d2-c939-67cc-c6dc-5f6e3fbc004a@gmail.com>

hi,

because i need a test stream that dosnt show up on main site of icecast
i was thinking about to create a mountpoint to another listen soket,

but i didnt found about it somwhere at the documentation, is this
possible, and when yes how?




From pm at nowster.me.uk  Sun May 31 14:37:22 2020
From: pm at nowster.me.uk (Paul Martin)
Date: Sun, 31 May 2020 15:37:22 +0100
Subject: [Icecast] mounpoint to antoher port
In-Reply-To: <f79228d2-c939-67cc-c6dc-5f6e3fbc004a@gmail.com>
References: <f79228d2-c939-67cc-c6dc-5f6e3fbc004a@gmail.com>
Message-ID: <20200531143722.GB64385@thinkpad.nowster.org.uk>

On Sat, May 30, 2020 at 10:44:19AM +0200, Railgun wrote:
> hi,
> 
> because i need a test stream that dosnt show up on main site of icecast
> i was thinking about to create a mountpoint to another listen soket,
> but i didnt found about it somwhere at the documentation, is this
> possible, and when yes how?

Something like this in icecast.xml?

    <mount type="normal">
      <mount-name>/test-feed-name.ogg</mount-name>
      <public>0</public>
      <hidden>1</hidden>
    </mount>

-- 
Paul Martin <pm at nowster.me.uk>