From mph at emotrics.com  Wed Dec  1 06:08:53 2021
From: mph at emotrics.com (Milton Huang)
Date: Tue, 30 Nov 2021 22:08:53 -0800
Subject: [Icecast] URL authentication failing
Message-ID: <CAKSXWJ6dsHF-mkJM5pHtb=_SkuazVMDKGoDpqpCMjykJ2jt6oA@mail.gmail.com>

I'm using a compiled version of Icecast (2.4.99.2) for TLS and having
problems tracking down where URL authentication is failing.  My icecast.xml
mount is:

        <mount-name>/teststream.mp3</mount-name>
        <authentication>
            <role type="url" match-method="get,post,head,options"
allow-web="*" deny-admin="*" may-alter="send_error,redirect">
                <option name="client_add"       value="
https://posthere.io/79f1-4499"/>
                <option name="client_remove"    value="
https://posthere.io/79f1-4499"/>
                <option name="action_add"       value="listener_add"/>
                <option name="action_remove"    value="listener_remove"/>
                <option name="headers"
 value="x-pragma,x-token,auth"/>
                <option name="header_prefix"    value=""/>
                <option name="header_auth"      value="HTTP/1.1 200 OK"/>
                <option name="header_timelimit" value=""/>
            </role>
            <role type="anonymous" match-method="get,post,head,options"
deny-all="*" />
        </authentication>

(I tried it first with "auth_header" like in the online doc, but changed it
to "header_auth" based on the messages in error.log) When I try to access
the stream, Icecast sends the correct POST to posthere.io to check
authentication. But in the error logs it says:

[2021-12-01  02:50:56] INFO auth/queue_auth_client auth on /teststream.mp3
has 1 pending
[2021-12-01  02:50:56] INFO auth_url/url_add_client client auth (
https://posthere.io/79f1-4499-9c2e) failed with ""
[2021-12-01  02:50:56] WARN reportxml/reportxml_database_build_report No
matching definition for "253444798-0643-4577-9139"

So it looks like auth failed. But why is it failing with ""? Does that mean
it didn't get the "HTTP/1.1 200 OK" response that posthere sent back? Any
suggestions on figuring this out?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211130/0103485e/attachment.htm>

From cf at it-flash.de  Wed Dec  8 14:00:57 2021
From: cf at it-flash.de (Christian 'flash2' Fladung)
Date: Wed, 08 Dec 2021 15:00:57 +0100
Subject: [Icecast] Standard Player / Choose
Message-ID: <3d6de16892d841c8eedcd1641ebee128@it-flash.de>

Hello, mailinglist 'icecast'.

I have a question about my favourite player that is implemented like 
this:

<audio controls>
   <source src="http://flashnet.it-flash.de:8000/primergy.ogg [1]" 
type="audio/ogg">
   <!-- fallback for non supporting browsers goes here -->
   <p>Your browser does not support HTML5 audio, but you can still
      <a href="https://necta.it-flash.de [2]">download the music</a>.</p>
</audio>
And shown on https://www2.it-flash.de

This is normally the standard way how to play audio in the browser via 
player controls.
So my question is for now: Why does it not work without a fresh cache?
On my Smartphones it only plays about 4 hours without disturb, when I 
even have rebooted the device freshly.
On PC there IT is the same problem, but in my opinion IT may depend on 
cache, too.
After the 6. second there is then the stream broken.
At first I thought, it is something with the buffer size.
But I had changed IT from small to big (don't remember the count) and IT 
didn't no difference.
Now I've thought that IT is something with "no-https" in modern browsers 
like firefox and chrome.
Their browser (chrome for eg.) does only work with valid https in this 
case (with standard player)
But I tested it with https and cert from Lets Encrypt and it didnt work, 
too.

Some ideas?
When the stream on top, these two players are started (once is started, 
yes), then I have to wait 6seconds.
When it does 6seconds, it makes half an hour allwayys then, too. Which 
is desired.
I really think, that another player which works differently should 
help... But I don't know which. ;-)

Pleasant thanks, &

-- 
MfG, Christian 'flash' Fladung

https://lab.spacecourt.org/09-soldiers_of_jah_army-true_love-rac.mp3

  [3]

Kinder und Greise fabeln. Die ersten, weil ihr Verstand [4] die 
Herrschaft ?ber die Phantasie noch nicht gewonnen, die zweiten, weil er 
sie verloren hat.

  [5]

Links:
------
[1] view-source:http://flashnet.it-flash.de:8000/primergy.ogg
[2] view-source:https://necta.it-flash.de/
[3] 
https://dragonfly.it-flash.de/music/ftp/NoMosk/NoMosk%20-%20Strike-maGIwQWwcLs.mp3
[4] http://zitate.net/verstand-zitate
[5] https://lab.spacecourt.org/13_-_ace_2__feat._makke_.mp3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211208/8e7b8705/attachment.htm>

From cf at it-flash.de  Wed Dec  8 14:29:01 2021
From: cf at it-flash.de (Christian 'flash2' Fladung)
Date: Wed, 08 Dec 2021 15:29:01 +0100
Subject: [Icecast] Fwd: Standard Player / Choose
In-Reply-To: <3d6de16892d841c8eedcd1641ebee128@it-flash.de>
References: <3d6de16892d841c8eedcd1641ebee128@it-flash.de>
Message-ID: <2941c907075e879ae076e79029de06ae@it-flash.de>

I want to add:

These like- Chrome Browser must of having https is dedicated to MP3 like 
I know.

So, I didn't test mp3, anyway. Iam using some aac and opus.

That primergy.ogg is, opus, too. (as far)

-------- Original Message --------

  		SUBJECT:
  		Standard Player / Choose

  		DATE:
  		2021-12-08 15:00

  		FROM:
  		Christian 'flash2' Fladung <cf at it-flash.de>

  		TO:
  		icecast at xiph.org

Hello, mailinglist 'icecast'.

I have a question about my favourite player that is implemented like 
this:

<audio controls>
   <source src="http://flashnet.it-flash.de:8000/primergy.ogg [1]" 
type="audio/ogg [2]">
   <!-- fallback for non supporting browsers goes here -->
   <p>Your browser does not support HTML5 audio, but you can still
      <a href="https://necta.it-flash.de [3]">download the music</a>.</p>
</audio>
And shown on https://www2.it-flash.de

This is normally the standard way how to play audio in the browser via 
player controls.
So my question is for now: Why does it not work without a fresh cache?
On my Smartphones it only plays about 4 hours without disturb, when I 
even have rebooted the device freshly.
On PC there IT is the same problem, but in my opinion IT may depend on 
cache, too.
After the 6. second there is then the stream broken.
At first I thought, it is something with the buffer size.
But I had changed IT from small to big (don't remember the count) and IT 
didn't no difference.
Now I've thought that IT is something with "no-https" in modern browsers 
like firefox and chrome.
Their browser (chrome for eg.) does only work with valid https in this 
case (with standard player)
But I tested it with https and cert from Lets Encrypt and it didnt work, 
too.

Some ideas?
When the stream on top, these two players are started (once is started, 
yes), then I have to wait 6seconds.
When it does 6seconds, it makes half an hour allwayys then, too. Which 
is desired.
I really think, that another player which works differently should 
help... But I don't know which. ;-)

Pleasant thanks, &

-- 
MfG, Christian 'flash' Fladung

https://lab.spacecourt.org/09-soldiers_of_jah_army-true_love-rac.mp3

  [4]

Kinder und Greise fabeln. Die ersten, weil ihr Verstand [5] die 
Herrschaft ?ber die Phantasie noch nicht gewonnen, die zweiten, weil er 
sie verloren hat.

  [6]
-- 
MfG, Christian 'flash' Fladung

https://lab.spacecourt.org/09-soldiers_of_jah_army-true_love-rac.mp3

  [4]

Kinder und Greise fabeln. Die ersten, weil ihr Verstand [5] die 
Herrschaft ?ber die Phantasie noch nicht gewonnen, die zweiten, weil er 
sie verloren hat.

  [6]

Links:
------
[1] view-source:http://flashnet.it-flash.de:8000/primergy.ogg
[2] http://dragonfly.it-flash.de/./#NOP
[3] view-source:https://necta.it-flash.de/
[4] 
https://dragonfly.it-flash.de/music/ftp/NoMosk/NoMosk%20-%20Strike-maGIwQWwcLs.mp3
[5] http://zitate.net/verstand-zitate
[6] https://lab.spacecourt.org/13_-_ace_2__feat._makke_.mp3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211208/9cd63256/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blocked.gif
Type: image/gif
Size: 118 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211208/9cd63256/attachment.gif>

From epirat07 at gmail.com  Wed Dec  8 16:28:28 2021
From: epirat07 at gmail.com (Marvin Scholz)
Date: Wed, 08 Dec 2021 17:28:28 +0100
Subject: [Icecast] Standard Player / Choose
In-Reply-To: <2941c907075e879ae076e79029de06ae@it-flash.de>
References: <3d6de16892d841c8eedcd1641ebee128@it-flash.de>
 <2941c907075e879ae076e79029de06ae@it-flash.de>
Message-ID: <8653D562-1298-4A5C-8B87-674A7D23D655@gmail.com>

Please stop with these unnecessary signatures after each of your mails,
they are not wanted here on this list.

On 8 Dec 2021, at 15:29, Christian 'flash2' Fladung wrote:

> I want to add:
>
> These like- Chrome Browser must of having https is dedicated to MP3 
> like I know.
>
> So, I didn't test mp3, anyway. Iam using some aac and opus.
>
> That primergy.ogg is, opus, too. (as far)
>
> -------- Original Message --------
>
>  		SUBJECT:
>  		Standard Player / Choose
>
>  		DATE:
>  		2021-12-08 15:00
>
>  		FROM:
>  		Christian 'flash2' Fladung <cf at it-flash.de>
>
>  		TO:
>  		icecast at xiph.org
>
> Hello, mailinglist 'icecast'.
>
> I have a question about my favourite player that is implemented like 
> this:
>
> <audio controls>
>   <source src="http://flashnet.it-flash.de:8000/primergy.ogg [1]" 
> type="audio/ogg [2]">
>   <!-- fallback for non supporting browsers goes here -->
>   <p>Your browser does not support HTML5 audio, but you can still
>      <a href="https://necta.it-flash.de [3]">download the 
> music</a>.</p>
> </audio>
> And shown on https://www2.it-flash.de
>
> This is normally the standard way how to play audio in the browser via 
> player controls.
> So my question is for now: Why does it not work without a fresh cache?
> On my Smartphones it only plays about 4 hours without disturb, when I 
> even have rebooted the device freshly.
> On PC there IT is the same problem, but in my opinion IT may depend on 
> cache, too.
> After the 6. second there is then the stream broken.
> At first I thought, it is something with the buffer size.
> But I had changed IT from small to big (don't remember the count) and 
> IT didn't no difference.
> Now I've thought that IT is something with "no-https" in modern 
> browsers like firefox and chrome.
> Their browser (chrome for eg.) does only work with valid https in this 
> case (with standard player)
> But I tested it with https and cert from Lets Encrypt and it didnt 
> work, too.
>
> Some ideas?
> When the stream on top, these two players are started (once is 
> started, yes), then I have to wait 6seconds.
> When it does 6seconds, it makes half an hour allwayys then, too. Which 
> is desired.
> I really think, that another player which works differently should 
> help... But I don't know which. ;-)
>
> Pleasant thanks, &
>
> -- 
> MfG, Christian 'flash' Fladung
>
> https://lab.spacecourt.org/09-soldiers_of_jah_army-true_love-rac.mp3
>
>  [4]
>
> Kinder und Greise fabeln. Die ersten, weil ihr Verstand [5] die 
> Herrschaft ?ber die Phantasie noch nicht gewonnen, die zweiten, weil 
> er sie verloren hat.
>
>  [6]
> -- 
> MfG, Christian 'flash' Fladung
>
> https://lab.spacecourt.org/09-soldiers_of_jah_army-true_love-rac.mp3
>
>  [4]
>
> Kinder und Greise fabeln. Die ersten, weil ihr Verstand [5] die 
> Herrschaft ?ber die Phantasie noch nicht gewonnen, die zweiten, weil 
> er sie verloren hat.
>
>  [6]
>
> Links:
> ------
> [1] view-source:http://flashnet.it-flash.de:8000/primergy.ogg
> [2] http://dragonfly.it-flash.de/./#NOP
> [3] view-source:https://necta.it-flash.de/
> [4] 
> https://dragonfly.it-flash.de/music/ftp/NoMosk/NoMosk%20-%20Strike-maGIwQWwcLs.mp3
> [5] http://zitate.net/verstand-zitate
> [6] https://lab.spacecourt.org/13_-_ace_2__feat._makke_.mp3


> _______________________________________________
> 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/20211208/dfa5be91/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blocked.gif
Type: image/gif
Size: 118 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211208/dfa5be91/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blocked.gif
Type: image/gif
Size: 118 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211208/dfa5be91/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blocked.gif
Type: image/gif
Size: 118 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211208/dfa5be91/attachment-0002.gif>

From cf at it-flash.de  Wed Dec  8 16:34:56 2021
From: cf at it-flash.de (Christian 'flash2' Fladung)
Date: Wed, 08 Dec 2021 17:34:56 +0100
Subject: [Icecast] Okay / Signatures / Question still alive
Message-ID: <95dc4af79a81f0de580e262ddf862850@it-flash.de>

Please stop with these unnecessary signatures after each of your mails,
they are not wanted here on this list.

On 8 Dec 2021, at 15:29, Christian 'flash2' Fladung wrote:

And are you unwanted, too?

> I want to add:
> 
> These like- Chrome Browser must of having https is dedicated to MP3 
> like I know.
> 
> So, I didn't test mp3, anyway. Iam using some aac and opus.
> 
> That primergy.ogg is, opus, too. (as far)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211208/a4a4c670/attachment.htm>

From cf at it-flash.de  Wed Dec  8 16:41:28 2021
From: cf at it-flash.de (Christian 'flash2' Fladung)
Date: Wed, 08 Dec 2021 17:41:28 +0100
Subject: [Icecast] Fwd:  Okay / Signatures / Question still alive
In-Reply-To: <95dc4af79a81f0de580e262ddf862850@it-flash.de>
References: <95dc4af79a81f0de580e262ddf862850@it-flash.de>
Message-ID: <a7fc45dab4df6196a08801f6f53ddf73@it-flash.de>

Patch your mouth or hold a doubt for your mailman!

Fucking flaming you do with Signatures etc.

-------- Original Message --------

  		SUBJECT:
  		[Icecast] Okay / Signatures / Question still alive

  		DATE:
  		2021-12-08 17:34

  		FROM:
  		Christian 'flash2' Fladung <cf at it-flash.de>

  		TO:
  		icecast at xiph.org

  		REPLY-TO:
  		Icecast streaming server user discussions <icecast at xiph.org>

Please stop with these unnecessary signatures after each of your mails,
they are not wanted here on this list.

On 8 Dec 2021, at 15:29, Christian 'flash2' Fladung wrote:

And are you unwanted, too?

> I want to add:
> 
> These like- Chrome Browser must of having https is dedicated to MP3 
> like I know.
> 
> So, I didn't test mp3, anyway. Iam using some aac and opus.
> 
> That primergy.ogg is, opus, too. (as far)

_______________________________________________
Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast
-- 
MfG, Christian 'flash' Fladung

Webdesigner & Event Manager @ NSA.gov

https://lab.spacecourt.org/09-soldiers_of_jah_army-true_love-rac.mp3

https://www.Digital-Rain.org

  [1]

Kinder und Greise fabeln. Die ersten, weil ihr Verstand [2] die 
Herrschaft ?ber die Phantasie noch nicht gewonnen, die zweiten, weil er 
sie verloren hat.

  [3]

Links:
------
[1] 
https://dragonfly.it-flash.de/music/ftp/NoMosk/NoMosk%20-%20Strike-maGIwQWwcLs.mp3
[2] http://zitate.net/verstand-zitate
[3] https://lab.spacecourt.org/13_-_ace_2__feat._makke_.mp3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211208/f7815cf1/attachment.htm>

From robinstl68 at icloud.com  Wed Dec  8 17:01:29 2021
From: robinstl68 at icloud.com (Robert Winkelmann)
Date: Wed, 8 Dec 2021 11:01:29 -0600
Subject: [Icecast] Standard Player / Choose
In-Reply-To: <8653D562-1298-4A5C-8B87-674A7D23D655@gmail.com>
References: <8653D562-1298-4A5C-8B87-674A7D23D655@gmail.com>
Message-ID: <F97B0803-BED1-400A-8466-5667768955FA@icloud.com>

Yeah that?s just a tad  excessive.

> On Dec 8, 2021, at 10:29 AM, Marvin Scholz <epirat07 at gmail.com> wrote:
> 
> ?
> Please stop with these unnecessary signatures after each of your mails,
> they are not wanted here on this list.
> 
> On 8 Dec 2021, at 15:29, Christian 'flash2' Fladung wrote:
> 
> I want to add:
> 
> These like- Chrome Browser must of having https is dedicated to MP3 like I know.
> 
> So, I didn't test mp3, anyway. Iam using some aac and opus.
> 
> That primergy.ogg is, opus, too. (as far)
> 
> -------- Original Message --------
> 
> Subject:	Standard Player / Choose
> Date:	2021-12-08 15:00
> From:	Christian 'flash2' Fladung <cf at it-flash.de>
> To:	icecast at xiph.org
> 
> 
> Hello, mailinglist 'icecast'.
> 
> I have a question about my favourite player that is implemented like this:
> 
> <audio controls>
>   <source src="http://flashnet.it-flash.de:8000/primergy.ogg" type="audio/ogg">
>   <!-- fallback for non supporting browsers goes here -->
>   <p>Your browser does not support HTML5 audio, but you can still
>      <a href="https://necta.it-flash.de">download the music</a>.</p>
> </audio>
> And shown on https://www2.it-flash.de
> 
> This is normally the standard way how to play audio in the browser via player controls.
> So my question is for now: Why does it not work without a fresh cache?
> On my Smartphones it only plays about 4 hours without disturb, when I even have rebooted the device freshly.
> On PC there IT is the same problem, but in my opinion IT may depend on cache, too.
> After the 6. second there is then the stream broken.
> At first I thought, it is something with the buffer size.
> But I had changed IT from small to big (don't remember the count) and IT didn't no difference.
> Now I've thought that IT is something with "no-https" in modern browsers like firefox and chrome.
> Their browser (chrome for eg.) does only work with valid https in this case (with standard player)
> But I tested it with https and cert from Lets Encrypt and it didnt work, too.
> 
> Some ideas?
> When the stream on top, these two players are started (once is started, yes), then I have to wait 6seconds.
> When it does 6seconds, it makes half an hour allwayys then, too. Which is desired. 
> I really think, that another player which works differently should help... But I don't know which. ;-)
> 
> Pleasant thanks, &
> 
> -- 
> MfG, Christian 'flash' Fladung
> 
> https://lab.spacecourt.org/09-soldiers_of_jah_army-true_love-rac.mp3
> 
> 
> 
> 
> 
> Kinder und Greise fabeln. Die ersten, weil ihr Verstand die Herrschaft ?ber die Phantasie noch nicht gewonnen, die zweiten, weil er sie verloren hat.
> 
> 
> 
> -- 
> MfG, Christian 'flash' Fladung
> 
> 
> 
> https://lab.spacecourt.org/09-soldiers_of_jah_army-true_love-rac.mp3
> 
> 
> 
> 
> 
> Kinder und Greise fabeln. Die ersten, weil ihr Verstand die Herrschaft ?ber die Phantasie noch nicht gewonnen, die zweiten, weil er sie verloren hat.
> 
> 
> 
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
> 
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211208/0b37034d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blocked.gif
Type: image/gif
Size: 118 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211208/0b37034d/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blocked.gif
Type: image/gif
Size: 118 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211208/0b37034d/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blocked.gif
Type: image/gif
Size: 118 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211208/0b37034d/attachment-0002.gif>

From tyctor at post.cz  Thu Dec  9 22:39:48 2021
From: tyctor at post.cz (tyctor)
Date: Thu, 09 Dec 2021 23:39:48 +0100
Subject: [Icecast] Prefered way to check if mountpoint is in use
Message-ID: <24c54a050246be5127e95a3e9950ecadf73e7476.camel@post.cz>

hi icecast masters

i have question what is prefered way to check if icecast mount point is
in use.
what i want to achieve is to start source ezstream as soon as mount
point is free.
probably i have two choices:
 - check icecast status and parse response
 - connect directly to omunt point with PUT request and check if
icecast response is "Mountpoint in use"

which way is prefered? or is there another way how to do it? 
is ok if i repeat this check once per second?

i have also defined fallback mount point to avoid client disconnections
where short loop is still playing

is it proper way how i doing it?

thanks for any tips 
tyctor
















From phschafft at de.loewenfelsen.net  Fri Dec 10 00:27:20 2021
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Fri, 10 Dec 2021 00:27:20 +0000
Subject: [Icecast] Prefered way to check if mountpoint is in use
In-Reply-To: <24c54a050246be5127e95a3e9950ecadf73e7476.camel@post.cz>
References: <24c54a050246be5127e95a3e9950ecadf73e7476.camel@post.cz>
Message-ID: <f6120539d2ed19d5154a4b527874b15e2ec2e598.camel@de.loewenfelsen.net>

Good evening,

On Thu, 2021-12-09 at 23:39 +0100, tyctor wrote:
> hi icecast masters
> 
> i have question what is prefered way to check if icecast mount point
> is in use. what i want to achieve is to start source ezstream as soon
> as mount point is free.
> probably i have two choices:
>  - check icecast status and parse response

Parsing the status page is *always* *wrong*. If you you would want to
access status data just use the API.


>  - connect directly to omunt point with PUT request and check if
> icecast response is "Mountpoint in use"

This is the 'correct' way. There is no point in checking first beside
creating an extra race condition and more ways for the check to go
wrong. ;)


> which way is prefered? or is there another way how to do it?

Generally I would suggest to have a look at <on-disconnect>,
"mount_remove" option for URL auth, as well as the "source-disconnect"
event (Icecast 2.5.x).

Those can provide triggers.

However keep in mind that Icecast is multi-threaded as well as your
operating is multi-tasking so it might take a few extra milliseconds
before the mountpoint is ready to be mounted again.


> is ok if i repeat this check once per second?

Icecast can work with that. But see above.


> i have also defined fallback mount point to avoid client
> disconnections where short loop is still playing is it proper way how
> i doing it?

I just wonder why not just send the backup signal to the fallback all
the time.


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: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211210/b0d41cc5/attachment.sig>

From tyctor at post.cz  Fri Dec 10 11:02:27 2021
From: tyctor at post.cz (tyctor)
Date: Fri, 10 Dec 2021 12:02:27 +0100
Subject: [Icecast] Prefered way to check if mountpoint is in use
In-Reply-To: <f6120539d2ed19d5154a4b527874b15e2ec2e598.camel@de.loewenfelsen.net>
References: <24c54a050246be5127e95a3e9950ecadf73e7476.camel@post.cz>
 <f6120539d2ed19d5154a4b527874b15e2ec2e598.camel@de.loewenfelsen.net>
Message-ID: <40cb4bccf2584bbb87dd0efbc9b750a92e6cb0f2.camel@post.cz>

hi, thanks for hints

On Fri, 2021-12-10 at 00:27 +0000, Philipp Schafft wrote:
> This is the 'correct' way. There is no point in checking first beside
> creating an extra race condition and more ways for the check to go
> wrong. ;)
> 

understand, no check, just to try to run ezstream, while mount point is
not in use, am i right?


> Generally I would suggest to have a look at <on-disconnect>,
> "mount_remove" option for URL auth, as well as the "source-
> disconnect"
> event (Icecast 2.5.x).
> 
> Those can provide triggers.

<on-disconnect> should be the best way, but it seems not working in
version 2.4.4-1 which we are using

this seems is latest version in ubuntu 18.04

$ apt-cache policy icecast2
icecast2:
  Installed: 2.4.4-1
  Candidate: 2.4.4-1
  Version table:
 *** 2.4.4-1 500
        500 
http://download.opensuse.org/repositories/multimedia:/xiph/xUbuntu_18.04
./ Packages
        100 /var/lib/dpkg/status


or is there 2.5.x package, for ubuntu 18.04?


> I just wonder why not just send the backup signal to the fallback all
> the time.

probably i am not clearly understanding how you mean this :o)
could you please describe it more?

best regards
tyctor




From un at aporee.org  Fri Dec 10 11:22:33 2021
From: un at aporee.org (unosonic)
Date: Fri, 10 Dec 2021 12:22:33 +0100
Subject: [Icecast] Prefered way to check if mountpoint is in use
In-Reply-To: <f6120539d2ed19d5154a4b527874b15e2ec2e598.camel@de.loewenfelsen.net>
References: <24c54a050246be5127e95a3e9950ecadf73e7476.camel@post.cz>
 <f6120539d2ed19d5154a4b527874b15e2ec2e598.camel@de.loewenfelsen.net>
Message-ID: <20211210112233.qd27ureyz25rrmf5@mail.aporee.net>

Philipp Schafft:
> >  - check icecast status and parse response
> 
> Parsing the status page is *always* *wrong*. If you you would want to
> access status data just use the API.

interesting! I've been parsing status-json.xsl for years in apps and scripts,
in order to check for mountpoints, and it never has failed. Can't be so wrong ;)
Curious, what does "API" refer to? Something like 
http://192.168.1.10:8000/admin/listmounts ?
bests, u.


From phschafft at de.loewenfelsen.net  Fri Dec 10 11:45:36 2021
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Fri, 10 Dec 2021 11:45:36 +0000
Subject: [Icecast] Prefered way to check if mountpoint is in use
In-Reply-To: <40cb4bccf2584bbb87dd0efbc9b750a92e6cb0f2.camel@post.cz>
References: <24c54a050246be5127e95a3e9950ecadf73e7476.camel@post.cz>
 <f6120539d2ed19d5154a4b527874b15e2ec2e598.camel@de.loewenfelsen.net>
 <40cb4bccf2584bbb87dd0efbc9b750a92e6cb0f2.camel@post.cz>
Message-ID: <cedde79c287b1664ae76c12b9e7b7e7dd355823a.camel@de.loewenfelsen.net>

Good morning,

On Fri, 2021-12-10 at 12:02 +0100, tyctor wrote:
> hi, thanks for hints
> 
> On Fri, 2021-12-10 at 00:27 +0000, Philipp Schafft wrote:
> > This is the 'correct' way. There is no point in checking first
> > beside
> > creating an extra race condition and more ways for the check to go
> > wrong. ;)
> > 
> 
> understand, no check, just to try to run ezstream, while mount point
> is not in use, am i right?

yes. Maybe it also has a auto-reconnect option.

> 
> > Generally I would suggest to have a look at <on-disconnect>,
> > "mount_remove" option for URL auth, as well as the "source-
> > disconnect" event (Icecast 2.5.x).
> > 
> > Those can provide triggers.
> 
> <on-disconnect> should be the best way, but it seems not working in
> version 2.4.4-1 which we are using

I'm not aware of any bugs regarding it for 2.4.4.
However:
 * Please note that the option takes the path to what is to be
   executed. This is not passed to a shell so you can not include any
   commandline arguments. A set of standard arguments and a basic ENV
   is passed to the binary/script.
 * (Not the case for you) IPC functionality such as this may be limited
   on Windows systems.


> this seems is latest version in ubuntu 18.04
> 
> $ apt-cache policy icecast2
> icecast2:
>   Installed: 2.4.4-1
>   Candidate: 2.4.4-1
>   Version table:
>  *** 2.4.4-1 500
>         500 
> http://download.opensuse.org/repositories/multimedia:/xiph/xUbuntu_18.04
> ./ Packages
>         100 /var/lib/dpkg/status
> 
> 
> or is there 2.5.x package, for ubuntu 18.04?

We are currently working on changing infrastructure here a bit.
There is this repo you could have a look at:
https://download.opensuse.org/repositories/home:/stephan48:/branches:/multimedia:/xiph:/beta/xUbuntu_18.04/

/!\ However it is at your own risk: it contains non-released code as
well as repo URL can/will change later on. /!\


> > I just wonder why not just send the backup signal to the fallback
> > all the time.
> 
> probably i am not clearly understanding how you mean this :o)
> could you please describe it more?

I understand your setup this way: When there is no "master signal" you
want some kind of fallback signal that is provided by ezstream. And you
already have some source that provides a fallback: Why not let ezstream
run all the time and provide the fallback? This would make the setup
much less complicated.


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: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211210/aee8af0e/attachment.sig>

From phschafft at de.loewenfelsen.net  Fri Dec 10 11:50:29 2021
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Fri, 10 Dec 2021 11:50:29 +0000
Subject: [Icecast] Prefered way to check if mountpoint is in use
In-Reply-To: <20211210112233.qd27ureyz25rrmf5@mail.aporee.net>
References: <24c54a050246be5127e95a3e9950ecadf73e7476.camel@post.cz>
 <f6120539d2ed19d5154a4b527874b15e2ec2e598.camel@de.loewenfelsen.net>
 <20211210112233.qd27ureyz25rrmf5@mail.aporee.net>
Message-ID: <4e4c59b9723c5549a533fe883886f74912739202.camel@de.loewenfelsen.net>

Good morning,

On Fri, 2021-12-10 at 12:22 +0100, unosonic wrote:
> Philipp Schafft:
> > >  - check icecast status and parse response
> > 
> > Parsing the status page is *always* *wrong*. If you you would want
> > to access status data just use the API.
> 
> interesting! I've been parsing status-json.xsl for years in apps and
> scripts, in order to check for mountpoints, and it never has failed.
> Can't be so wrong ;)

I was mostly referring to the generated HTML. For the old JSON there
are known bugs. If they do not bite you, nothing wrong with using this.

For 2.5.x we deprecated the status-json.xsl (it is still there, but
will see no more updates). The new interface can be found at
/admin/publicstats.


> Curious, what does "API" refer to? Something like 
> http://192.168.1.10:8000/admin/listmounts ?
> bests, u.

By API I generally mean anything that is not meant for human
consumption. So basically everything that is not HTML.

Please also keep in mind that for every bit of HTML Icecast generates
there is an non-HTML API call.


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: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211210/45ecc156/attachment.sig>

From tyctor at post.cz  Fri Dec 10 13:08:48 2021
From: tyctor at post.cz (tyctor)
Date: Fri, 10 Dec 2021 14:08:48 +0100
Subject: [Icecast] Prefered way to check if mountpoint is in use
In-Reply-To: <cedde79c287b1664ae76c12b9e7b7e7dd355823a.camel@de.loewenfelsen.net>
References: <24c54a050246be5127e95a3e9950ecadf73e7476.camel@post.cz>
 <f6120539d2ed19d5154a4b527874b15e2ec2e598.camel@de.loewenfelsen.net>
 <40cb4bccf2584bbb87dd0efbc9b750a92e6cb0f2.camel@post.cz>
 <cedde79c287b1664ae76c12b9e7b7e7dd355823a.camel@de.loewenfelsen.net>
Message-ID: <a8868570cdaccc0f90b4444ad1e1722c215ef463.camel@post.cz>

thanks for your reply

On Fri, 2021-12-10 at 11:45 +0000, Philipp Schafft wrote:
> Good morning,
> 
> On Fri, 2021-12-10 at 12:02 +0100, tyctor wrote:
> > hi, thanks for hints
> > 
> > On Fri, 2021-12-10 at 00:27 +0000, Philipp Schafft wrote:
> > > This is the 'correct' way. There is no point in checking first
> > > beside
> > > creating an extra race condition and more ways for the check to
> > > go
> > > wrong. ;)
> > > 
> > 
> > understand, no check, just to try to run ezstream, while mount
> > point
> > is not in use, am i right?
> 
> yes. Maybe it also has a auto-reconnect option.
> 

ok, i will try newer version of ezstream, if it have auto-reconnect
option
we are using 0.5.6 and there is already 1.0.2

> > > Generally I would suggest to have a look at <on-disconnect>,
> > > "mount_remove" option for URL auth, as well as the "source-
> > > disconnect" event (Icecast 2.5.x).
> > > 
> > > Those can provide triggers.
> > 
> > <on-disconnect> should be the best way, but it seems not working in
> > version 2.4.4-1 which we are using
> 
> I'm not aware of any bugs regarding it for 2.4.4.
> However:
>  * Please note that the option takes the path to what is to be
>    executed. This is not passed to a shell so you can not include any
>    commandline arguments. A set of standard arguments and a basic ENV
>    is passed to the binary/script.
>  * (Not the case for you) IPC functionality such as this may be
> limited
>    on Windows systems.

good to hear that it should work
i checked setup and i found, that owner of that file wasn't icecast2
user
so maybe that was point why it not working, we will se now

> 
> > this seems is latest version in ubuntu 18.04
> > 
> > $ apt-cache policy icecast2
> > icecast2:
> >   Installed: 2.4.4-1
> >   Candidate: 2.4.4-1
> >   Version table:
> >  *** 2.4.4-1 500
> >         500 
> > http://download.opensuse.org/repositories/multimedia:/xiph/xUbuntu_18.04
> > ./ Packages
> >         100 /var/lib/dpkg/status
> > 
> > 
> > or is there 2.5.x package, for ubuntu 18.04?
> 
> We are currently working on changing infrastructure here a bit.
> There is this repo you could have a look at:
> https://download.opensuse.org/repositories/home:/stephan48:/branches:/multimedia:/xiph:/beta/xUbuntu_18.04/
> 
> /!\ However it is at your own risk: it contains non-released code as
> well as repo URL can/will change later on. /!\
> 
> 
> > > I just wonder why not just send the backup signal to the fallback
> > > all the time.
> > 
> > probably i am not clearly understanding how you mean this :o)
> > could you please describe it more?
> 
> I understand your setup this way: When there is no "master signal"
> you
> want some kind of fallback signal that is provided by ezstream. And
> you
> already have some source that provides a fallback: Why not let
> ezstream
> run all the time and provide the fallback? This would make the setup
> much less complicated.
> 

our setup is like this:
 - mountpoint radio - main mount point where all clients are
connecting, here we are streaming live shows, it has fallback-mount
loops

 - mountpoint loops - when is brodcast day, we streaming here jingles
and loops, so when next live show is preparing, this is what clients
listening, while next live show is started, it has fallback-mount
archive

 - mountpoint archive - here we are nonstop streaming our old shows, so
when no live stream is available and no loops is available this is what
clients are listening


so we have live DJs show, and we also have prerecorded DJs shows
if DJ cant came to studio, it can send prerecorded DJ set, and it will
play in exact time, when his show was planned

prerecorded DJ sets are playing automatically by ezstream

but if broadcast day is mixed from live and prerecorded shows
sometimes happens that live show last little bit longer
and when ezstream starts planned prerecorded show, it need to wait
while previous live show will release mount point

so this is the cause why i want to start streaming exactly when mount
point is released

but if newer version of ezstream wll have auto-reconnect option it will
solve this

best regards
tyctor



From tyctor at post.cz  Fri Dec 10 15:11:20 2021
From: tyctor at post.cz (tyctor)
Date: Fri, 10 Dec 2021 16:11:20 +0100
Subject: [Icecast] Prefered way to check if mountpoint is in use
In-Reply-To: <a8868570cdaccc0f90b4444ad1e1722c215ef463.camel@post.cz>
References: <24c54a050246be5127e95a3e9950ecadf73e7476.camel@post.cz>
 <f6120539d2ed19d5154a4b527874b15e2ec2e598.camel@de.loewenfelsen.net>
 <40cb4bccf2584bbb87dd0efbc9b750a92e6cb0f2.camel@post.cz>
 <cedde79c287b1664ae76c12b9e7b7e7dd355823a.camel@de.loewenfelsen.net>
 <a8868570cdaccc0f90b4444ad1e1722c215ef463.camel@post.cz>
Message-ID: <51ef3927369b80fbd1d8beb99f55238619273c12.camel@post.cz>

> good to hear that it should work
> i checked setup and i found, that owner of that file wasn't icecast2
> user
> so maybe that was point why it not working, we will se now
> 
yes that was only permissions problem, not on-connect/on-disconnect is
working
so i will use it for starting ezstream player with prerecorded show

best regard
tyctor



From jordan at coolmic.net  Fri Dec 10 16:40:01 2021
From: jordan at coolmic.net (Jordan Erickson)
Date: Fri, 10 Dec 2021 08:40:01 -0800
Subject: [Icecast] Prefered way to check if mountpoint is in use
In-Reply-To: <20211210112233.qd27ureyz25rrmf5@mail.aporee.net>
References: <24c54a050246be5127e95a3e9950ecadf73e7476.camel@post.cz>
 <f6120539d2ed19d5154a4b527874b15e2ec2e598.camel@de.loewenfelsen.net>
 <20211210112233.qd27ureyz25rrmf5@mail.aporee.net>
Message-ID: <c8aac79b-491b-e8df-9983-7d51f574bdc6@coolmic.net>

The status pages are dynamic and the developers do not guarantee that 
they will stay the same. This means the method you use to parse them may 
break randomly with updates. Using the API itself guarantees a stable 
interface to query between versions. At least that's how I understand 
everything.

API: https://en.wikipedia.org/wiki/API


Cheers,
Jordan Erickson


On 12/10/21 3:22 AM, unosonic wrote:
> Philipp Schafft:
>>>   - check icecast status and parse response
>> Parsing the status page is *always* *wrong*. If you you would want to
>> access status data just use the API.
> interesting! I've been parsing status-json.xsl for years in apps and scripts,
> in order to check for mountpoints, and it never has failed. Can't be so wrong ;)
> Curious, what does "API" refer to? Something like
> http://192.168.1.10:8000/admin/listmounts ?
> bests, u.


From un at aporee.org  Fri Dec 10 17:54:01 2021
From: un at aporee.org (unosonic)
Date: Fri, 10 Dec 2021 18:54:01 +0100
Subject: [Icecast] Prefered way to check if mountpoint is in use
In-Reply-To: <c8aac79b-491b-e8df-9983-7d51f574bdc6@coolmic.net>
References: <24c54a050246be5127e95a3e9950ecadf73e7476.camel@post.cz>
 <f6120539d2ed19d5154a4b527874b15e2ec2e598.camel@de.loewenfelsen.net>
 <20211210112233.qd27ureyz25rrmf5@mail.aporee.net>
 <c8aac79b-491b-e8df-9983-7d51f574bdc6@coolmic.net>
Message-ID: <20211210175401.sloevn7nsm6ng6of@mail.aporee.net>



thanks, I'm familiar with APIs, my question was about where I can find one in 
icecast (2.4. ...) So I guess it's all about 2.5.*?
bests, u.

Jordan Erickson:
> The status pages are dynamic and the developers do not guarantee that they
> will stay the same. This means the method you use to parse them may break
> randomly with updates. Using the API itself guarantees a stable interface to
> query between versions. At least that's how I understand everything.
> 
> API: https://en.wikipedia.org/wiki/API
> 
> 


From mayianmm at jmu.edu  Wed Dec 15 18:09:28 2021
From: mayianmm at jmu.edu (Mayiani, Martin Martine - mayianmm)
Date: Wed, 15 Dec 2021 18:09:28 +0000
Subject: [Icecast] log4J Zero Day
Message-ID: <SN6PR03MB3599F4B2BFE87F0633159108C1769@SN6PR03MB3599.namprd03.prod.outlook.com>

Hi,

log4J Zero Day- is this a concern at all for the Icecast streaming service?

Thanks


Martin Mayiani
Operation Specialist WMRA & WEMC
540.568.4045
wmra.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.wmra.org_&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=eQi7nhx8pVV4tLuhsbN2fg&m=NFlE41P71KSXw5cwSeRchUP5NPq-DGAcQ7PZuBLgoOU&s=kMN-C5UjM7TSPILlWvJ-k5wu4UUakvkqbiJTlV6-zog&e=>

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

From yahav.shasha at gmail.com  Wed Dec 15 18:20:30 2021
From: yahav.shasha at gmail.com (Yahav Shasha)
Date: Wed, 15 Dec 2021 20:20:30 +0200
Subject: [Icecast] log4J Zero Day
In-Reply-To: <SN6PR03MB3599F4B2BFE87F0633159108C1769@SN6PR03MB3599.namprd03.prod.outlook.com>
References: <SN6PR03MB3599F4B2BFE87F0633159108C1769@SN6PR03MB3599.namprd03.prod.outlook.com>
Message-ID: <CABuab=Rf3AJnMyM5arzfkv95vNj51QWTMOsA0j33YA9BUeQdiw@mail.gmail.com>

Its a java library so no.

?????? ??? ??, 15 ????? 2021, 20:15, ??? Mayiani, Martin Martine - mayianmm
?<mayianmm at jmu.edu>:

> Hi,
>
>
>
> *log4J Zero Day*- is this a concern at all for the Icecast streaming
> service?
>
>
>
> Thanks
>
>
>
>
>
> Martin Mayiani
>
> Operation Specialist WMRA & WEMC
>
> 540.568.4045
>
> wmra.org
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.wmra.org_&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=eQi7nhx8pVV4tLuhsbN2fg&m=NFlE41P71KSXw5cwSeRchUP5NPq-DGAcQ7PZuBLgoOU&s=kMN-C5UjM7TSPILlWvJ-k5wu4UUakvkqbiJTlV6-zog&e=>
>
>
> _______________________________________________
> 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/20211215/6cfbd393/attachment.htm>

From mayianmm at jmu.edu  Wed Dec 15 21:49:27 2021
From: mayianmm at jmu.edu (Mayiani, Martin Martine - mayianmm)
Date: Wed, 15 Dec 2021 21:49:27 +0000
Subject: [Icecast] log4J Zero Day
In-Reply-To: <CABuab=Rf3AJnMyM5arzfkv95vNj51QWTMOsA0j33YA9BUeQdiw@mail.gmail.com>
References: <SN6PR03MB3599F4B2BFE87F0633159108C1769@SN6PR03MB3599.namprd03.prod.outlook.com>
 <CABuab=Rf3AJnMyM5arzfkv95vNj51QWTMOsA0j33YA9BUeQdiw@mail.gmail.com>
Message-ID: <SN6PR03MB359964705556D9494ECBB154C1769@SN6PR03MB3599.namprd03.prod.outlook.com>

Thank you

Martin
From: Icecast <icecast-bounces at xiph.org> On Behalf Of Yahav Shasha
Sent: Wednesday, December 15, 2021 1:21 PM
To: Icecast streaming server user discussions <icecast at xiph.org>
Subject: Re: [Icecast] log4J Zero Day

CAUTION: This email originated from outside of JMU. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
Its a java library so no.

?????? ??? ??, 15 ????? 2021, 20:15, ??? Mayiani, Martin Martine - mayianmm ?<mayianmm at jmu.edu<mailto:mayianmm at jmu.edu>>:
Hi,

log4J Zero Day- is this a concern at all for the Icecast streaming service?

Thanks


Martin Mayiani
Operation Specialist WMRA & WEMC
540.568.4045
wmra.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.wmra.org_&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=eQi7nhx8pVV4tLuhsbN2fg&m=NFlE41P71KSXw5cwSeRchUP5NPq-DGAcQ7PZuBLgoOU&s=kMN-C5UjM7TSPILlWvJ-k5wu4UUakvkqbiJTlV6-zog&e=>

_______________________________________________
Icecast mailing list
Icecast at xiph.org<mailto:Icecast at xiph.org>
http://lists.xiph.org/mailman/listinfo/icecast<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.xiph.org_mailman_listinfo_icecast&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=fM5iy7jgIV7jGhy9QkEGrQ&m=RZPeLJ5rTeF_ReQhvQK8l0mVWCQ2JiGjzGg1HtWITsw&s=sPqsF9oTK1SNFgQQmcT6OmCkmMVWULasVIlKLk7nrDA&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211215/de096e24/attachment.htm>

From mph at emotrics.com  Wed Dec 15 21:40:08 2021
From: mph at emotrics.com (Milton Huang)
Date: Wed, 15 Dec 2021 13:40:08 -0800
Subject: [Icecast] queue-size
Message-ID: <CAKSXWJ7HcsB+Ua2GSHti+Nv0MWin1eAP12n5xrzx=1rHCV2e5w@mail.gmail.com>

Hi all,
I just want to make sure I understand what the `queue-size` setting does in
icecast.xml. My understanding is that for each mountpoint, a buffer of that
size (default 0.5 MB) is maintained for serving to all connected clients.
Each client is fed from that buffer, and if their connection lags so they
can't keep up with the queue contents, they get kicked with a 'client has
fallen too far behind' message in the log.

I assume if we divide the queue-size by the mount's bitrate we would get
the duration of how slow a connection can be which is a limit on possible
latency of clients.

On the client side, there is an input buffer to help with poor connections.
This will be filled at the initial connection with a burst-on-connect if
enabled in the icecast settings. There will be an initial delay in play
while the buffer is filled, which the burst should help reduce. Obviously,
the burst-size has to be smaller than the queue size, or you will defeat
the purpose of the burst.

Do I have this all right? Any comments or clarifications?

-milton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211215/652dad10/attachment.htm>

From phschafft at de.loewenfelsen.net  Thu Dec 16 17:28:46 2021
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Thu, 16 Dec 2021 17:28:46 +0000
Subject: [Icecast] queue-size
In-Reply-To: <CAKSXWJ7HcsB+Ua2GSHti+Nv0MWin1eAP12n5xrzx=1rHCV2e5w@mail.gmail.com>
References: <CAKSXWJ7HcsB+Ua2GSHti+Nv0MWin1eAP12n5xrzx=1rHCV2e5w@mail.gmail.com>
Message-ID: <bf7ca95a05d1100f70c8446ff30534c744ac4a9d.camel@de.loewenfelsen.net>

Good afternoon,

On Wed, 2021-12-15 at 13:40 -0800, Milton Huang wrote:
> Hi all,
> I just want to make sure I understand what the `queue-size` setting
> does in icecast.xml. My understanding is that for each mountpoint, a
> buffer of that size (default 0.5 MB) is maintained for serving to all
> connected clients. Each client is fed from that buffer, and if their
> connection lags so they can't keep up with the queue contents, they
> get kicked with a 'client has fallen too far behind' message in the
> log.

That is basically right. However I would like to add that the default
queue size is fine for audio streaming and may need to be adjusted for
video streaming. If you see a lot of said messages in logs and you are
using the default the problem is likely not the value but something
else (e.g. the network being saturated). Or: If you think changing this
value will help you, rethink as it likely is not.


> I assume if we divide the queue-size by the mount's bitrate we would
> get the duration of how slow a connection can be which is a limit on
> possible latency of clients.

This is wrong. Sadly a common myth.

The 'bitrate' of a stream is generally 0) not constant, 1) only applies
to the audio data, not the stream.

as for 0) it can easily jump between 0.1% and 200% of the nominal value
for many codecs.

as for 1) the stream consists of more than just the audio data. E.g. it
contains of framing, setup headers, and metadata. Metadata can easily
account for the same amount of data than several seconds, sometimes
minutes of audio data.

Keeping this in mind a useful value of a bitrate for a stream needs to
be calculated over at least an entire segment (track/song/title)
including all of it's metadata and format overhead. Also as metadata
may be very different for different tracks the value may still be
'jumping around' a lot.


All of that said it is surely possible to create a stream with a more
constant or foreseeable bitrate. But this is NOT the general case.


So you calculation above may at best give a very rough estimation.


> On the client side, there is an input buffer to help with poor
> connections.

The input buffer needs to be there independent on the connection
quality, but what a good size for it is, depends mostly on the quality
of the connection.


> This will be filled at the initial connection with a burst-on-connect 
> if enabled in the icecast settings. There will be an initial delay in
> play while the buffer is filled, which the burst should help reduce. 

This is perfectly correct.


> Obviously, the burst-size has to be smaller than the queue size, or
> you will defeat the purpose of the burst.

This is not really true. The burst-size is a request to Icecast.
However Icecast will not send exactly this amount of bytes as it needs
to adhere external constrains. One of them is how much data it has. So
setting this to an overly large value will just let Icecast send as
much as possible.

Other such constrains are format specific aspects such as setup headers
and metadata, but also framing/syncing.


As a small addition:
Similar holds true for the queue-size. E.g. if Icecast has not yet got
a full queue-size of data from a source the buffer is smaller.
Depending on how the data is chunked (this depends on the version of
Icecast, the format, the operating systems, the sources, the network,
...) the size might be slightly smaller or larger.

Generally those values should be considered as requests and Icecast
tries to work with them as good as possible.


> Do I have this all right? Any comments or clarifications?

Please see my comments inline. :)


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: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211216/4887bb5a/attachment.sig>

From hgalt at gmx.net  Sat Dec 18 15:40:20 2021
From: hgalt at gmx.net (HGAlt)
Date: Sat, 18 Dec 2021 16:40:20 +0100
Subject: [Icecast] How include Referer to listclients
Message-ID: <000601d7f425$90f8c9f0$b2ea5dd0$@gmx.net>

Hi together,



I am able to receive a XML file which lists the current listeners, if I use the URL http://xxxxx.yy:port/admin/listclients?mount=/stream

But this file does not includes the Referer value.



I also use the 64-bit pre realized KH version. This one already has includes the Referer.



Is it possible to add the referrer in any way?



I have looked for a XLS file to add it. But the listclients.xls file is the one for the html view.



Thanks for our support,

Hans-Georg



--
Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211218/6c63d09d/attachment.htm>

From andreu.bassols at gmail.com  Sat Dec 18 22:21:46 2021
From: andreu.bassols at gmail.com (=?UTF-8?Q?Andreu_Bassols_Alc=C3=B3n?=)
Date: Sat, 18 Dec 2021 23:21:46 +0100
Subject: [Icecast] Listclients and Logging real IP behind proxy
Message-ID: <CAPCWFPdx5dKi804oKfmA=Zq38na_318UCBLU6UsrMmpMi1bx5Q@mail.gmail.com>

Hi!

I have Icecast behind Cloudflare, so all clients' IP got masked. In order
to show real IP, cloudflare sends the http header CF-Connecting-IP, similar
to the old known X-Forwarded-For.

Is there any way to Icecast to show (in Listclients) and log the real
client IP taking into consideration X-Forwarded-For (or CF-Connecting-IP)
header instead of the real IP?

Thank you!


-- 
Andreu Bassols i Alc?n
http://about.me/anigwei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211218/928896af/attachment.htm>

From ThomasPrivat92 at gmx.de  Sun Dec 19 00:10:19 2021
From: ThomasPrivat92 at gmx.de (Thomas)
Date: Sun, 19 Dec 2021 01:10:19 +0100
Subject: [Icecast] Listclients and Logging real IP behind proxy
In-Reply-To: <CAPCWFPdx5dKi804oKfmA=Zq38na_318UCBLU6UsrMmpMi1bx5Q@mail.gmail.com>
References: <CAPCWFPdx5dKi804oKfmA=Zq38na_318UCBLU6UsrMmpMi1bx5Q@mail.gmail.com>
Message-ID: <5a075dab-497e-5443-21ad-5944ef187a9d@gmx.de>

not that i know but you can log that with traefik if you use this tool
as a proxy service

Am 18.12.2021 um 23:21 schrieb Andreu Bassols Alc?n:
> Hi!
>
> I have Icecast behind Cloudflare, so all clients' IP got masked. In
> order to show real IP, cloudflare sends the http header
> CF-Connecting-IP, similar to the old known X-Forwarded-For.
>
> Is there any way to Icecast to show (in Listclients) and log the real
> client IP taking into consideration X-Forwarded-For (or
> CF-Connecting-IP) header instead of the real IP?
>
> Thank you!
>
>
> --
> Andreu Bassols i Alc?n
> http://about.me/anigwei
>
> _______________________________________________
> 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/20211219/962a1d4d/attachment.htm>

From usermark at mdrsesco.biz  Tue Dec 21 20:52:32 2021
From: usermark at mdrsesco.biz (usermark at mdrsesco.biz)
Date: Tue, 21 Dec 2021 15:52:32 -0500
Subject: [Icecast] Trouble
Message-ID: <001701d7f6ac$ad435d80$07ca1880$@mdrsesco.biz>

icecast Was Working Fine But Now...

 

 <https://www.washear.org/> Metropolitan Washington Ear Home (washear.org)

 

The link above is the homepage for Metropolitan Washington Ear, a radio
reading service for the blind.

 

Somebody else installed Icecast on a dedicated Windows 7 PC in 2008.   Roll
forward to 2022 (almost) the live feed still works great.  But the Radio
Archive (which see on the homepage) does not.

 

I just tested it again.  By clicking one of the radio programs the browser
attempts to contact Icecast via this URL:
<http://live.washear.org/mp3s/20-09.mp3>
http://live.washear.org/mp3s/20-09.mp3

 

No response.  Dang.   

 

Mark Rockman

 

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

From jeffares.robert at gmail.com  Tue Dec 21 21:41:48 2021
From: jeffares.robert at gmail.com (Robert Jeffares)
Date: Wed, 22 Dec 2021 10:41:48 +1300
Subject: [Icecast] Trouble
In-Reply-To: <001701d7f6ac$ad435d80$07ca1880$@mdrsesco.biz>
References: <001701d7f6ac$ad435d80$07ca1880$@mdrsesco.biz>
Message-ID: <c99122e7-24f3-9c77-0063-42406697c350@gmail.com>

I checked here Mark but it's geoblocked

regards

Robert

On 22/12/21 9:52 am, usermark at mdrsesco.biz wrote:
>
> icecast Was Working Fine But Now...
>
> Metropolitan Washington Ear Home (washear.org) <https://www.washear.org/>
>
> The link above is the homepage for Metropolitan Washington Ear, a 
> radio reading service for the blind.
>
> Somebody else installed Icecast on a dedicated Windows 7 PC in 2008.?? 
> Roll forward to 2022 (almost) the live feed still works great.? But 
> the Radio Archive (which see on the homepage) does not.
>
> I just tested it again.? By clicking one of the radio programs the 
> browser attempts to contact Icecast via this URL: 
> http://live.washear.org/mp3s/20-09.mp3 
> <http://live.washear.org/mp3s/20-09.mp3>
>
> No response.? Dang.
>
> Mark Rockman
>
>
> _______________________________________________
> 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/20211222/fdad654d/attachment.htm>

From mph at emotrics.com  Tue Dec 21 22:33:12 2021
From: mph at emotrics.com (Milton Huang)
Date: Tue, 21 Dec 2021 14:33:12 -0800
Subject: [Icecast] queue-size
In-Reply-To: <bf7ca95a05d1100f70c8446ff30534c744ac4a9d.camel@de.loewenfelsen.net>
References: <CAKSXWJ7HcsB+Ua2GSHti+Nv0MWin1eAP12n5xrzx=1rHCV2e5w@mail.gmail.com>
 <bf7ca95a05d1100f70c8446ff30534c744ac4a9d.camel@de.loewenfelsen.net>
Message-ID: <CAKSXWJ7SM=uPnosH=auc9Dtx1GefC1EASc_5NjWXsJ8Cur5KRQ@mail.gmail.com>

Philipp,

Thank you for your detailed and enlightening answers. Just to make sure I
understand how 'bitrate' works here. Assuming we are just working with
audio to keep it simple. Let's also ignore metadata, as my use case is that
I am generating an electronic music stream from ffmpeg and broadcasting
that using Icecast, so I can control/calculate that.  I presume that if we
specify `audio_bitrate` for a particular mount, that is a 'target' rate
that Icecast will attempt to transmit audio data at. You mentioned that the
actual rate can vary. Am I right to assume this is because it is dependent
on the source (ffmpeg) rate for filling the 'queue', which in turn is used
to fill each buffer of each connected client?

If so, wouldn't it generally be best for the mount `audio_bitrate` to be
set to the same bitrate that the source is generating/sending at?  I have
the option of generating and compressing my mp3 stream at either a fixed
bitrate or to use a LAME VBR setting, and from what I am now understanding
it seems that using a fixed bitrate could be better to avoid leading or
lagging the queue buffer.

Thanks for educating all of us!

On Thu, Dec 16, 2021 at 9:28 AM Philipp Schafft <
phschafft at de.loewenfelsen.net> wrote:

> Good afternoon,
>
> On Wed, 2021-12-15 at 13:40 -0800, Milton Huang wrote:
> > Hi all,
> > I just want to make sure I understand what the `queue-size` setting
> > does in icecast.xml. My understanding is that for each mountpoint, a
> > buffer of that size (default 0.5 MB) is maintained for serving to all
> > connected clients. Each client is fed from that buffer, and if their
> > connection lags so they can't keep up with the queue contents, they
> > get kicked with a 'client has fallen too far behind' message in the
> > log.
>
> That is basically right. However I would like to add that the default
> queue size is fine for audio streaming and may need to be adjusted for
> video streaming. If you see a lot of said messages in logs and you are
> using the default the problem is likely not the value but something
> else (e.g. the network being saturated). Or: If you think changing this
> value will help you, rethink as it likely is not.
>
>
> > I assume if we divide the queue-size by the mount's bitrate we would
> > get the duration of how slow a connection can be which is a limit on
> > possible latency of clients.
>
> This is wrong. Sadly a common myth.
>
> The 'bitrate' of a stream is generally 0) not constant, 1) only applies
> to the audio data, not the stream.
>
> as for 0) it can easily jump between 0.1% and 200% of the nominal value
> for many codecs.
>
> as for 1) the stream consists of more than just the audio data. E.g. it
> contains of framing, setup headers, and metadata. Metadata can easily
> account for the same amount of data than several seconds, sometimes
> minutes of audio data.
>
> Keeping this in mind a useful value of a bitrate for a stream needs to
> be calculated over at least an entire segment (track/song/title)
> including all of it's metadata and format overhead. Also as metadata
> may be very different for different tracks the value may still be
> 'jumping around' a lot.
>
>
> All of that said it is surely possible to create a stream with a more
> constant or foreseeable bitrate. But this is NOT the general case.
>
>
> So you calculation above may at best give a very rough estimation.
>
>
> > On the client side, there is an input buffer to help with poor
> > connections.
>
> The input buffer needs to be there independent on the connection
> quality, but what a good size for it is, depends mostly on the quality
> of the connection.
>
>
> > This will be filled at the initial connection with a burst-on-connect
> > if enabled in the icecast settings. There will be an initial delay in
> > play while the buffer is filled, which the burst should help reduce.
>
> This is perfectly correct.
>
>
> > Obviously, the burst-size has to be smaller than the queue size, or
> > you will defeat the purpose of the burst.
>
> This is not really true. The burst-size is a request to Icecast.
> However Icecast will not send exactly this amount of bytes as it needs
> to adhere external constrains. One of them is how much data it has. So
> setting this to an overly large value will just let Icecast send as
> much as possible.
>
> Other such constrains are format specific aspects such as setup headers
> and metadata, but also framing/syncing.
>
>
> As a small addition:
> Similar holds true for the queue-size. E.g. if Icecast has not yet got
> a full queue-size of data from a source the buffer is smaller.
> Depending on how the data is chunked (this depends on the version of
> Icecast, the format, the operating systems, the sources, the network,
> ...) the size might be slightly smaller or larger.
>
> Generally those values should be considered as requests and Icecast
> tries to work with them as good as possible.
>
>
> > Do I have this all right? Any comments or clarifications?
>
> Please see my comments inline. :)
>
>
> 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
> _______________________________________________
> 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/20211221/7ae1594b/attachment.htm>

From usermark at mdrsesco.biz  Wed Dec 22 01:01:41 2021
From: usermark at mdrsesco.biz (usermark at mdrsesco.biz)
Date: Tue, 21 Dec 2021 20:01:41 -0500
Subject: [Icecast] Trouble
In-Reply-To: <c99122e7-24f3-9c77-0063-42406697c350@gmail.com>
References: <001701d7f6ac$ad435d80$07ca1880$@mdrsesco.biz>
 <c99122e7-24f3-9c77-0063-42406697c350@gmail.com>
Message-ID: <003b01d7f6cf$7bd811a0$738834e0$@mdrsesco.biz>

Thanks for trying Robert.   What country should I unblock?

 

From: Icecast <icecast-bounces at xiph.org> On Behalf Of Robert Jeffares
Sent: Tuesday, December 21, 2021 16:42
To: icecast at xiph.org
Subject: Re: [Icecast] Trouble

 

I checked here Mark but it's geoblocked

regards

Robert

On 22/12/21 9:52 am, usermark at mdrsesco.biz <mailto:usermark at mdrsesco.biz>
wrote:

icecast Was Working Fine But Now...

 

Metropolitan Washington Ear Home (washear.org) <https://www.washear.org/> 

 

The link above is the homepage for Metropolitan Washington Ear, a radio
reading service for the blind.

 

Somebody else installed Icecast on a dedicated Windows 7 PC in 2008.   Roll
forward to 2022 (almost) the live feed still works great.  But the Radio
Archive (which see on the homepage) does not.

 

I just tested it again.  By clicking one of the radio programs the browser
attempts to contact Icecast via this URL:
<http://live.washear.org/mp3s/20-09.mp3>
http://live.washear.org/mp3s/20-09.mp3

 

No response.  Dang.   

 

Mark Rockman

 





_______________________________________________
Icecast mailing list
Icecast at xiph.org <mailto: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/20211221/7eaf5c80/attachment.htm>

From phschafft at de.loewenfelsen.net  Wed Dec 22 01:40:17 2021
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Wed, 22 Dec 2021 01:40:17 +0000
Subject: [Icecast] queue-size
In-Reply-To: <CAKSXWJ7SM=uPnosH=auc9Dtx1GefC1EASc_5NjWXsJ8Cur5KRQ@mail.gmail.com>
References: <CAKSXWJ7HcsB+Ua2GSHti+Nv0MWin1eAP12n5xrzx=1rHCV2e5w@mail.gmail.com>
 <bf7ca95a05d1100f70c8446ff30534c744ac4a9d.camel@de.loewenfelsen.net>
 <CAKSXWJ7SM=uPnosH=auc9Dtx1GefC1EASc_5NjWXsJ8Cur5KRQ@mail.gmail.com>
Message-ID: <3814bcba6e224aaca2b173a329423376526c6b1c.camel@de.loewenfelsen.net>

Good evening,

On Tue, 2021-12-21 at 14:33 -0800, Milton Huang wrote:
> Philipp,
> 
> Thank you for your detailed and enlightening answers.

you're very welcome.


> Just to make sure I understand how 'bitrate' works here. Assuming we
> are just working with audio to keep it simple. Let's also ignore
> metadata,

Ok. Just a word of warning to the general audience: This is a very
limited view on the problem and might not apply to real deployments or
fail to be valid at random.


> as my use case is that I am generating an electronic music stream
> from ffmpeg and broadcasting that using Icecast, so I can
> control/calculate that.


> I presume that if we specify `audio_bitrate` for a particular mount,
> that is a 'target' rate that Icecast will attempt to transmit audio
> data at.

No, see below.


> You mentioned that the actual rate can vary. Am I right to assume
> this is because it is dependent on the source (ffmpeg) rate for
> filling the 'queue', which in turn is used to fill each buffer of
> each connected client?

No. The bitrate depends on the codec, the encoder parameters, and the
audio. E.g. bitrate can drop to virtually (or actually) zero for
moments of silence as there just is no entropy to encode.


> If so, wouldn't it generally be best for the mount `audio_bitrate` to
> be set to the same bitrate that the source is generating/sending at?

It is generally recommended to set as few options on the Icecast side
as possible. Also see below.


> I have the option of generating and compressing my mp3 stream at
> either a fixed bitrate or to use a LAME VBR setting, and from what I
> am now understanding it seems that using a fixed bitrate could be
> better to avoid leading or lagging the queue buffer.

Generally encoding with fixed bitrate tends to harm the quality of the
signal. How much error is introduced depends again on the codec, the
encoder parameters, and the signal.

A quality based encoding is normally best as this results in the
encoder trying to keep the signal on the same quality level. Bitrate is
approximately a function of entropy*quality. The more constant you try
to keep it the more quality of the signal will change with changes in
entropy. Change of the amount of entropy per time in a signal is a very
common event. E.g. you have a radical change between voice and music,
but also between different kinds of music/compositions (fade-
in/intro/fade-out/outro, instrumental-only, instruments+voice,
simpler/more complex parts of a track, ...).

With flexible transports such as IP based networks I see little use of
constant or semi-constant bitrate modes. The main applications that
comes to mind are fixed bitrate transports channels such as radio
channels (e.g. GSM slots).


Back to Icecast:
Ignoring bursts and format specific headers, as well as syncing for a
moment (which is exactly what happens once a listener is fully
connected) Icecast sends data out as soon as it receives it.
Icecast does not implement any bitrate control. There are no delays
(which would be the only way for Icecast to do this, as it can not send
data before it received it). All bitrate related options are cosmetic
only (e.g. for user friendly display in directory services).

Please note that this holds true for all official Icecast versions.
Forks or custom versions may differ here.


> Thanks for educating all of us!

Again, just happy if this helps anyone. :)

With best regards,


> On Thu, Dec 16, 2021 at 9:28 AM Philipp Schafft <
> phschafft at de.loewenfelsen.net> wrote:
> > Good afternoon,
> > 
> > On Wed, 2021-12-15 at 13:40 -0800, Milton Huang wrote:
> > > Hi all,
> > > I just want to make sure I understand what the `queue-size`
> > setting
> > > does in icecast.xml. My understanding is that for each
> > mountpoint, a
> > > buffer of that size (default 0.5 MB) is maintained for serving to
> > all
> > > connected clients. Each client is fed from that buffer, and if
> > their
> > > connection lags so they can't keep up with the queue contents,
> > they
> > > get kicked with a 'client has fallen too far behind' message in
> > the
> > > log.
> > 
> > That is basically right. However I would like to add that the
> > default
> > queue size is fine for audio streaming and may need to be adjusted
> > for
> > video streaming. If you see a lot of said messages in logs and you
> > are
> > using the default the problem is likely not the value but something
> > else (e.g. the network being saturated). Or: If you think changing
> > this
> > value will help you, rethink as it likely is not.
> > 
> > 
> > > I assume if we divide the queue-size by the mount's bitrate we
> > would
> > > get the duration of how slow a connection can be which is a limit
> > on
> > > possible latency of clients.
> > 
> > This is wrong. Sadly a common myth.
> > 
> > The 'bitrate' of a stream is generally 0) not constant, 1) only
> > applies
> > to the audio data, not the stream.
> > 
> > as for 0) it can easily jump between 0.1% and 200% of the nominal
> > value
> > for many codecs.
> > 
> > as for 1) the stream consists of more than just the audio data.
> > E.g. it
> > contains of framing, setup headers, and metadata. Metadata can
> > easily
> > account for the same amount of data than several seconds, sometimes
> > minutes of audio data.
> > 
> > Keeping this in mind a useful value of a bitrate for a stream needs
> > to
> > be calculated over at least an entire segment (track/song/title)
> > including all of it's metadata and format overhead. Also as
> > metadata
> > may be very different for different tracks the value may still be
> > 'jumping around' a lot.
> > 
> > 
> > All of that said it is surely possible to create a stream with a
> > more
> > constant or foreseeable bitrate. But this is NOT the general case.
> > 
> > 
> > So you calculation above may at best give a very rough estimation.
> > 
> > 
> > > On the client side, there is an input buffer to help with poor
> > > connections.
> > 
> > The input buffer needs to be there independent on the connection
> > quality, but what a good size for it is, depends mostly on the
> > quality
> > of the connection.
> > 
> > 
> > > This will be filled at the initial connection with a burst-on-
> > connect 
> > > if enabled in the icecast settings. There will be an initial
> > delay in
> > > play while the buffer is filled, which the burst should help
> > reduce. 
> > 
> > This is perfectly correct.
> > 
> > 
> > > Obviously, the burst-size has to be smaller than the queue size,
> > or
> > > you will defeat the purpose of the burst.
> > 
> > This is not really true. The burst-size is a request to Icecast.
> > However Icecast will not send exactly this amount of bytes as it
> > needs
> > to adhere external constrains. One of them is how much data it has.
> > So
> > setting this to an overly large value will just let Icecast send as
> > much as possible.
> > 
> > Other such constrains are format specific aspects such as setup
> > headers
> > and metadata, but also framing/syncing.
> > 
> > 
> > As a small addition:
> > Similar holds true for the queue-size. E.g. if Icecast has not yet
> > got
> > a full queue-size of data from a source the buffer is smaller.
> > Depending on how the data is chunked (this depends on the version
> > of
> > Icecast, the format, the operating systems, the sources, the
> > network,
> > ...) the size might be slightly smaller or larger.
> > 
> > Generally those values should be considered as requests and Icecast
> > tries to work with them as good as possible.
> > 
> > 
> > > Do I have this all right? Any comments or clarifications?
> > 
> > Please see my comments inline. :)


-- 
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: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211222/c74e0f27/attachment.sig>

From gavin at stephens.net.nz  Wed Dec 22 02:55:49 2021
From: gavin at stephens.net.nz (Gavin Stephens)
Date: Wed, 22 Dec 2021 15:55:49 +1300
Subject: [Icecast] queue-size
In-Reply-To: <CAKSXWJ7SM=uPnosH=auc9Dtx1GefC1EASc_5NjWXsJ8Cur5KRQ@mail.gmail.com>
References: <CAKSXWJ7HcsB+Ua2GSHti+Nv0MWin1eAP12n5xrzx=1rHCV2e5w@mail.gmail.com>
 <bf7ca95a05d1100f70c8446ff30534c744ac4a9d.camel@de.loewenfelsen.net>
 <CAKSXWJ7SM=uPnosH=auc9Dtx1GefC1EASc_5NjWXsJ8Cur5KRQ@mail.gmail.com>
Message-ID: <cdee9b1a-8c9b-7440-20f0-a03984abb9cf@stephens.net.nz>

I have the queue size customised.

I run 320Kbps bitrates by default (we're mostly all fibre over here) 
along side the odd 64Kbps for monitoring, and while using burst, and a 
customised queue I know roughly that a client sits at the estimated 8 
seconds ahead of the queue (bitrate? / 8? x 8). With the default queue, 
if there are any issues with burst the clients get dropped to much where 
latency is increased (ie: international).

The second reason is when I play with low bitrate streams, customising 
the queue means I can have the delay to the client at roughly the same 
point in time regardless of bitrate being used. But for 320Kbps, I found 
the default queue not good enough. There's the opposite problem with 
this though, if you don't set a queue for low bitrates for each mount 
point, those low bitrate queues become reallllllllyyyyy delayed.

On 22/12/2021 11:33 am, Milton Huang wrote:
> Philipp,
>
> Thank you for your detailed and enlightening answers. Just to make 
> sure I understand how 'bitrate' works here. Assuming we are just 
> working with audio to keep it simple. Let's also ignore metadata, as 
> my use case is that I am generating an electronic music stream from 
> ffmpeg and broadcasting that using Icecast, so I can control/calculate 
> that.? I presume that if we specify `audio_bitrate` for a particular 
> mount, that is a 'target' rate that Icecast will attempt to transmit 
> audio data at. You mentioned that the actual rate can vary. Am I right 
> to assume this is because it is dependent on the source (ffmpeg) rate 
> for filling the 'queue', which in turn is used to fill each buffer of 
> each connected client?
>
> If so, wouldn't it generally be best for the mount `audio_bitrate` to 
> be set to the same bitrate that the source is generating/sending at?? 
> I have the option of generating and compressing my mp3 stream at 
> either a fixed bitrate or to use a LAME VBR setting, and from what I 
> am now understanding it seems that using a fixed bitrate could be 
> better to avoid leading or lagging the queue buffer.
>
> Thanks for educating all of us!
>
> On Thu, Dec 16, 2021 at 9:28 AM Philipp Schafft 
> <phschafft at de.loewenfelsen.net <mailto:phschafft at de.loewenfelsen.net>> 
> wrote:
>
>     Good afternoon,
>
>     On Wed, 2021-12-15 at 13:40 -0800, Milton Huang wrote:
>     > Hi all,
>     > I just want to make sure I understand what the `queue-size` setting
>     > does in icecast.xml. My understanding is that for each mountpoint, a
>     > buffer of that size (default 0.5 MB) is maintained for serving
>     to all
>     > connected clients. Each client is fed from that buffer, and if their
>     > connection lags so they can't keep up with the queue contents, they
>     > get kicked with a 'client has fallen too far behind' message in the
>     > log.
>
>     That is basically right. However I would like to add that the default
>     queue size is fine for audio streaming and may need to be adjusted for
>     video streaming. If you see a lot of said messages in logs and you are
>     using the default the problem is likely not the value but something
>     else (e.g. the network being saturated). Or: If you think changing
>     this
>     value will help you, rethink as it likely is not.
>
>
>     > I assume if we divide the queue-size by the mount's bitrate we would
>     > get the duration of how slow a connection can be which is a limit on
>     > possible latency of clients.
>
>     This is wrong. Sadly a common myth.
>
>     The 'bitrate' of a stream is generally 0) not constant, 1) only
>     applies
>     to the audio data, not the stream.
>
>     as for 0) it can easily jump between 0.1% and 200% of the nominal
>     value
>     for many codecs.
>
>     as for 1) the stream consists of more than just the audio data.
>     E.g. it
>     contains of framing, setup headers, and metadata. Metadata can easily
>     account for the same amount of data than several seconds, sometimes
>     minutes of audio data.
>
>     Keeping this in mind a useful value of a bitrate for a stream needs to
>     be calculated over at least an entire segment (track/song/title)
>     including all of it's metadata and format overhead. Also as metadata
>     may be very different for different tracks the value may still be
>     'jumping around' a lot.
>
>
>     All of that said it is surely possible to create a stream with a more
>     constant or foreseeable bitrate. But this is NOT the general case.
>
>
>     So you calculation above may at best give a very rough estimation.
>
>
>     > On the client side, there is an input buffer to help with poor
>     > connections.
>
>     The input buffer needs to be there independent on the connection
>     quality, but what a good size for it is, depends mostly on the quality
>     of the connection.
>
>
>     > This will be filled at the initial connection with a
>     burst-on-connect
>     > if enabled in the icecast settings. There will be an initial
>     delay in
>     > play while the buffer is filled, which the burst should help
>     reduce.
>
>     This is perfectly correct.
>
>
>     > Obviously, the burst-size has to be smaller than the queue size, or
>     > you will defeat the purpose of the burst.
>
>     This is not really true. The burst-size is a request to Icecast.
>     However Icecast will not send exactly this amount of bytes as it needs
>     to adhere external constrains. One of them is how much data it has. So
>     setting this to an overly large value will just let Icecast send as
>     much as possible.
>
>     Other such constrains are format specific aspects such as setup
>     headers
>     and metadata, but also framing/syncing.
>
>
>     As a small addition:
>     Similar holds true for the queue-size. E.g. if Icecast has not yet got
>     a full queue-size of data from a source the buffer is smaller.
>     Depending on how the data is chunked (this depends on the version of
>     Icecast, the format, the operating systems, the sources, the network,
>     ...) the size might be slightly smaller or larger.
>
>     Generally those values should be considered as requests and Icecast
>     tries to work with them as good as possible.
>
>
>     > Do I have this all right? Any comments or clarifications?
>
>     Please see my comments inline. :)
>
>
>     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
>     _______________________________________________
>     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
> 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/20211222/54433b60/attachment.htm>

From fredg at paravelsystems.com  Wed Dec 22 14:00:28 2021
From: fredg at paravelsystems.com (Fred Gleason)
Date: Wed, 22 Dec 2021 09:00:28 -0500
Subject: [Icecast] Trouble
In-Reply-To: <001701d7f6ac$ad435d80$07ca1880$@mdrsesco.biz>
References: <001701d7f6ac$ad435d80$07ca1880$@mdrsesco.biz>
Message-ID: <DA8D8584-6179-401F-808C-11FD7A1C4182@paravelsystems.com>

On Dec 21, 2021, at 15:52, <usermark at mdrsesco.biz> <usermark at mdrsesco.biz> wrote:

> Somebody else installed Icecast on a dedicated Windows 7 PC in 2008.   Roll forward to 2022 (almost) the live feed still works great.  But the Radio Archive (which see on the homepage) does not.
>  
> I just tested it again.  By clicking one of the radio programs the browser attempts to contact Icecast via this URL:  http://live.washear.org/mp3s/20-09.mp3 <http://live.washear.org/mp3s/20-09.mp3>
It appears that the entire archive server [?live.washear.org?] may be down, or at least disconnected from Internet access. No response to attempts to connect via HTTP, nor to pings.

What IP address[es] are the Windows 7 PC using? DNS is mapping ?live.washear.org? to 70.91.72.83.

Cheers!


|---------------------------------------------------------------------|
| Frederick F. Gleason, Jr. |             Chief Developer             |
|                           |             Paravel Systems             |
|---------------------------------------------------------------------|
|         A room without books is like a body without a soul.         |
|                                                                     |
|                                                         -- Cicero   |
|---------------------------------------------------------------------|

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

From usermark at mdrsesco.biz  Wed Dec 22 15:09:39 2021
From: usermark at mdrsesco.biz (usermark at mdrsesco.biz)
Date: Wed, 22 Dec 2021 10:09:39 -0500
Subject: [Icecast] Trouble
In-Reply-To: <DA8D8584-6179-401F-808C-11FD7A1C4182@paravelsystems.com>
References: <001701d7f6ac$ad435d80$07ca1880$@mdrsesco.biz>
 <DA8D8584-6179-401F-808C-11FD7A1C4182@paravelsystems.com>
Message-ID: <000d01d7f745$f18665c0$d4933140$@mdrsesco.biz>

Yes.  The PC that runs Icecast is behind a firewall that excludes countries outside USA.   I can disable that feature of the firewall if you like.

 

From: Icecast <icecast-bounces at xiph.org> On Behalf Of Fred Gleason
Sent: Wednesday, December 22, 2021 09:00
To: Icecast streaming server user discussions <icecast at xiph.org>
Subject: Re: [Icecast] Trouble

 

On Dec 21, 2021, at 15:52, <usermark at mdrsesco.biz <mailto:usermark at mdrsesco.biz> > <usermark at mdrsesco.biz <mailto:usermark at mdrsesco.biz> > wrote:

 

Somebody else installed Icecast on a dedicated Windows 7 PC in 2008.   Roll forward to 2022 (almost) the live feed still works great.  But the Radio Archive (which see on the homepage) does not.

 

I just tested it again.  By clicking one of the radio programs the browser attempts to contact Icecast via this URL:   <http://live.washear.org/mp3s/20-09.mp3> http://live.washear.org/mp3s/20-09.mp3

 

It appears that the entire archive server [?live.washear.org <http://live.washear.org> ?] may be down, or at least disconnected from Internet access. No response to attempts to connect via HTTP, nor to pings.

 

What IP address[es] are the Windows 7 PC using? DNS is mapping ?live.washear.org <http://live.washear.org> ? to 70.91.72.83.

 

Cheers!

 

 

|---------------------------------------------------------------------|

| Frederick F. Gleason, Jr. |             Chief Developer             |

|                           |             Paravel Systems             |

|---------------------------------------------------------------------|

|         A room without books is like a body without a soul.         |

|                                                                     |

|                                                         -- Cicero   |

|---------------------------------------------------------------------|





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

From fredg at paravelsystems.com  Wed Dec 22 16:15:14 2021
From: fredg at paravelsystems.com (Fred Gleason)
Date: Wed, 22 Dec 2021 11:15:14 -0500
Subject: [Icecast] Trouble
In-Reply-To: <000d01d7f745$f18665c0$d4933140$@mdrsesco.biz>
References: <001701d7f6ac$ad435d80$07ca1880$@mdrsesco.biz>
 <DA8D8584-6179-401F-808C-11FD7A1C4182@paravelsystems.com>
 <000d01d7f745$f18665c0$d4933140$@mdrsesco.biz>
Message-ID: <5D7DDB08-EA47-4672-8C39-9D4DCCAF3EF8@paravelsystems.com>

On Dec 22, 2021, at 10:09, usermark at mdrsesco.biz wrote:

> Yes.  The PC that runs Icecast is behind a firewall that excludes countries outside USA.   I can disable that feature of the firewall if you like.

I?m in northern VA (originating IP 71.63.82.77). Certainly in the USA!

Cheers!


|---------------------------------------------------------------------|
| Frederick F. Gleason, Jr. |             Chief Developer             |
|                           |             Paravel Systems             |
|---------------------------------------------------------------------|
|         A room without books is like a body without a soul.         |
|                                                                     |
|                                                         -- Cicero   |
|---------------------------------------------------------------------|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211222/847754df/attachment.htm>

From jeffares.robert at gmail.com  Wed Dec 22 19:22:25 2021
From: jeffares.robert at gmail.com (Robert Jeffares)
Date: Thu, 23 Dec 2021 08:22:25 +1300
Subject: [Icecast] Trouble
In-Reply-To: <003b01d7f6cf$7bd811a0$738834e0$@mdrsesco.biz>
References: <001701d7f6ac$ad435d80$07ca1880$@mdrsesco.biz>
 <c99122e7-24f3-9c77-0063-42406697c350@gmail.com>
 <003b01d7f6cf$7bd811a0$738834e0$@mdrsesco.biz>
Message-ID: <aeaa91c4-088a-1682-a5e3-1c3b4792c726@gmail.com>

I am in New Zealand.

There are a LOT of Comcast servers on the route from here.

They may be using least cost routing and moving traffic across their 
owned circuits.

The issue may be external to the server.

R

On 22/12/21 2:01 pm, usermark at mdrsesco.biz wrote:
>
> Thanks for trying Robert.?? What country should I unblock?
>
> *From:* Icecast <icecast-bounces at xiph.org> *On Behalf Of *Robert Jeffares
> *Sent:* Tuesday, December 21, 2021 16:42
> *To:* icecast at xiph.org
> *Subject:* Re: [Icecast] Trouble
>
> I checked here Mark but it's geoblocked
>
> regards
>
> Robert
>
> On 22/12/21 9:52 am, usermark at mdrsesco.biz 
> <mailto:usermark at mdrsesco.biz> wrote:
>
>     icecast Was Working Fine But Now...
>
>     Metropolitan Washington Ear Home (washear.org)
>     <https://www.washear.org/>
>
>     The link above is the homepage for Metropolitan Washington Ear, a
>     radio reading service for the blind.
>
>     Somebody else installed Icecast on a dedicated Windows 7 PC in
>     2008.?? Roll forward to 2022 (almost) the live feed still works
>     great.? But the Radio Archive (which see on the homepage) does not.
>
>     I just tested it again.? By clicking one of the radio programs the
>     browser attempts to contact Icecast via this URL:
>     http://live.washear.org/mp3s/20-09.mp3
>     <http://live.washear.org/mp3s/20-09.mp3>
>
>     No response.? Dang.
>
>     Mark Rockman
>
>
>
>     _______________________________________________
>
>     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
> http://lists.xiph.org/mailman/listinfo/icecast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211223/577e4477/attachment.htm>

From mph at emotrics.com  Thu Dec 23 04:28:04 2021
From: mph at emotrics.com (Milton Huang)
Date: Wed, 22 Dec 2021 20:28:04 -0800
Subject: [Icecast] queue-size
In-Reply-To: <3814bcba6e224aaca2b173a329423376526c6b1c.camel@de.loewenfelsen.net>
References: <CAKSXWJ7HcsB+Ua2GSHti+Nv0MWin1eAP12n5xrzx=1rHCV2e5w@mail.gmail.com>
 <bf7ca95a05d1100f70c8446ff30534c744ac4a9d.camel@de.loewenfelsen.net>
 <CAKSXWJ7SM=uPnosH=auc9Dtx1GefC1EASc_5NjWXsJ8Cur5KRQ@mail.gmail.com>
 <3814bcba6e224aaca2b173a329423376526c6b1c.camel@de.loewenfelsen.net>
Message-ID: <CAKSXWJ439+wN=4tnrGraXVsbNbByUuOyLNuY0xbJibG4WseBhQ@mail.gmail.com>

Wow. This has been helpful to me to really understand what is going on.
I'd suspected the 'audio_bitrate' was just for show.  So, to again make
sure I'm understanding, I assume I can get the actual (average) transfer
rate of data to a particular user for a particular session by taking the
access.log BYTES = total bytes of data sent (other than headers) and
dividing by TIME = seconds that the connection lasted. This varies
depending on many of the factors you mention, particularly the amount of
information in the signal.  And for those reasons, it can be misleading if
measured in a very short window.

I just looked at one of my logs and saw a huge spread for the 1 second
duration... Don't know how to post pictures though...

On Tue, Dec 21, 2021 at 5:40 PM Philipp Schafft <
phschafft at de.loewenfelsen.net> wrote:

> Good evening,
>
> On Tue, 2021-12-21 at 14:33 -0800, Milton Huang wrote:
> > Philipp,
> >
> > Thank you for your detailed and enlightening answers.
>
> you're very welcome.
>
>
> > Just to make sure I understand how 'bitrate' works here. Assuming we
> > are just working with audio to keep it simple. Let's also ignore
> > metadata,
>
> Ok. Just a word of warning to the general audience: This is a very
> limited view on the problem and might not apply to real deployments or
> fail to be valid at random.
>
>
> > as my use case is that I am generating an electronic music stream
> > from ffmpeg and broadcasting that using Icecast, so I can
> > control/calculate that.
>
>
> > I presume that if we specify `audio_bitrate` for a particular mount,
> > that is a 'target' rate that Icecast will attempt to transmit audio
> > data at.
>
> No, see below.
>
>
> > You mentioned that the actual rate can vary. Am I right to assume
> > this is because it is dependent on the source (ffmpeg) rate for
> > filling the 'queue', which in turn is used to fill each buffer of
> > each connected client?
>
> No. The bitrate depends on the codec, the encoder parameters, and the
> audio. E.g. bitrate can drop to virtually (or actually) zero for
> moments of silence as there just is no entropy to encode.
>
>
> > If so, wouldn't it generally be best for the mount `audio_bitrate` to
> > be set to the same bitrate that the source is generating/sending at?
>
> It is generally recommended to set as few options on the Icecast side
> as possible. Also see below.
>
>
> > I have the option of generating and compressing my mp3 stream at
> > either a fixed bitrate or to use a LAME VBR setting, and from what I
> > am now understanding it seems that using a fixed bitrate could be
> > better to avoid leading or lagging the queue buffer.
>
> Generally encoding with fixed bitrate tends to harm the quality of the
> signal. How much error is introduced depends again on the codec, the
> encoder parameters, and the signal.
>
> A quality based encoding is normally best as this results in the
> encoder trying to keep the signal on the same quality level. Bitrate is
> approximately a function of entropy*quality. The more constant you try
> to keep it the more quality of the signal will change with changes in
> entropy. Change of the amount of entropy per time in a signal is a very
> common event. E.g. you have a radical change between voice and music,
> but also between different kinds of music/compositions (fade-
> in/intro/fade-out/outro, instrumental-only, instruments+voice,
> simpler/more complex parts of a track, ...).
>
> With flexible transports such as IP based networks I see little use of
> constant or semi-constant bitrate modes. The main applications that
> comes to mind are fixed bitrate transports channels such as radio
> channels (e.g. GSM slots).
>
>
> Back to Icecast:
> Ignoring bursts and format specific headers, as well as syncing for a
> moment (which is exactly what happens once a listener is fully
> connected) Icecast sends data out as soon as it receives it.
> Icecast does not implement any bitrate control. There are no delays
> (which would be the only way for Icecast to do this, as it can not send
> data before it received it). All bitrate related options are cosmetic
> only (e.g. for user friendly display in directory services).
>
> Please note that this holds true for all official Icecast versions.
> Forks or custom versions may differ here.
>
>
> > Thanks for educating all of us!
>
> Again, just happy if this helps anyone. :)
>
> With best regards,
>
>
> > On Thu, Dec 16, 2021 at 9:28 AM Philipp Schafft <
> > phschafft at de.loewenfelsen.net> wrote:
> > > Good afternoon,
> > >
> > > On Wed, 2021-12-15 at 13:40 -0800, Milton Huang wrote:
> > > > Hi all,
> > > > I just want to make sure I understand what the `queue-size`
> > > setting
> > > > does in icecast.xml. My understanding is that for each
> > > mountpoint, a
> > > > buffer of that size (default 0.5 MB) is maintained for serving to
> > > all
> > > > connected clients. Each client is fed from that buffer, and if
> > > their
> > > > connection lags so they can't keep up with the queue contents,
> > > they
> > > > get kicked with a 'client has fallen too far behind' message in
> > > the
> > > > log.
> > >
> > > That is basically right. However I would like to add that the
> > > default
> > > queue size is fine for audio streaming and may need to be adjusted
> > > for
> > > video streaming. If you see a lot of said messages in logs and you
> > > are
> > > using the default the problem is likely not the value but something
> > > else (e.g. the network being saturated). Or: If you think changing
> > > this
> > > value will help you, rethink as it likely is not.
> > >
> > >
> > > > I assume if we divide the queue-size by the mount's bitrate we
> > > would
> > > > get the duration of how slow a connection can be which is a limit
> > > on
> > > > possible latency of clients.
> > >
> > > This is wrong. Sadly a common myth.
> > >
> > > The 'bitrate' of a stream is generally 0) not constant, 1) only
> > > applies
> > > to the audio data, not the stream.
> > >
> > > as for 0) it can easily jump between 0.1% and 200% of the nominal
> > > value
> > > for many codecs.
> > >
> > > as for 1) the stream consists of more than just the audio data.
> > > E.g. it
> > > contains of framing, setup headers, and metadata. Metadata can
> > > easily
> > > account for the same amount of data than several seconds, sometimes
> > > minutes of audio data.
> > >
> > > Keeping this in mind a useful value of a bitrate for a stream needs
> > > to
> > > be calculated over at least an entire segment (track/song/title)
> > > including all of it's metadata and format overhead. Also as
> > > metadata
> > > may be very different for different tracks the value may still be
> > > 'jumping around' a lot.
> > >
> > >
> > > All of that said it is surely possible to create a stream with a
> > > more
> > > constant or foreseeable bitrate. But this is NOT the general case.
> > >
> > >
> > > So you calculation above may at best give a very rough estimation.
> > >
> > >
> > > > On the client side, there is an input buffer to help with poor
> > > > connections.
> > >
> > > The input buffer needs to be there independent on the connection
> > > quality, but what a good size for it is, depends mostly on the
> > > quality
> > > of the connection.
> > >
> > >
> > > > This will be filled at the initial connection with a burst-on-
> > > connect
> > > > if enabled in the icecast settings. There will be an initial
> > > delay in
> > > > play while the buffer is filled, which the burst should help
> > > reduce.
> > >
> > > This is perfectly correct.
> > >
> > >
> > > > Obviously, the burst-size has to be smaller than the queue size,
> > > or
> > > > you will defeat the purpose of the burst.
> > >
> > > This is not really true. The burst-size is a request to Icecast.
> > > However Icecast will not send exactly this amount of bytes as it
> > > needs
> > > to adhere external constrains. One of them is how much data it has.
> > > So
> > > setting this to an overly large value will just let Icecast send as
> > > much as possible.
> > >
> > > Other such constrains are format specific aspects such as setup
> > > headers
> > > and metadata, but also framing/syncing.
> > >
> > >
> > > As a small addition:
> > > Similar holds true for the queue-size. E.g. if Icecast has not yet
> > > got
> > > a full queue-size of data from a source the buffer is smaller.
> > > Depending on how the data is chunked (this depends on the version
> > > of
> > > Icecast, the format, the operating systems, the sources, the
> > > network,
> > > ...) the size might be slightly smaller or larger.
> > >
> > > Generally those values should be considered as requests and Icecast
> > > tries to work with them as good as possible.
> > >
> > >
> > > > Do I have this all right? Any comments or clarifications?
> > >
> > > Please see my comments inline. :)
>
>
> --
> 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
> _______________________________________________
> 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/20211222/2f148b48/attachment.htm>

From usermark at mdrsesco.biz  Thu Dec 23 05:07:04 2021
From: usermark at mdrsesco.biz (usermark at mdrsesco.biz)
Date: Thu, 23 Dec 2021 00:07:04 -0500
Subject: [Icecast] Trouble
In-Reply-To: <aeaa91c4-088a-1682-a5e3-1c3b4792c726@gmail.com>
References: <001701d7f6ac$ad435d80$07ca1880$@mdrsesco.biz>
 <c99122e7-24f3-9c77-0063-42406697c350@gmail.com>
 <003b01d7f6cf$7bd811a0$738834e0$@mdrsesco.biz>
 <aeaa91c4-088a-1682-a5e3-1c3b4792c726@gmail.com>
Message-ID: <001b01d7f7ba$edc494a0$c94dbde0$@mdrsesco.biz>

Thanks.   My customer where the Icecast server is located is having trouble
with Comcast locally.  It is their monthly "area-wide outage" that can only
be fixed between midnight and 0600 when the office is closed.  I will
unblock the world as soon as I can log in.

 

From: Icecast <icecast-bounces at xiph.org> On Behalf Of Robert Jeffares
Sent: Wednesday, December 22, 2021 14:22
To: icecast at xiph.org
Subject: Re: [Icecast] Trouble

 

I am in New Zealand.

There are a LOT of Comcast servers on the route from here. 

They may be using least cost routing and moving traffic across their owned
circuits.

The issue may be external to the server.

R

On 22/12/21 2:01 pm, usermark at mdrsesco.biz <mailto:usermark at mdrsesco.biz>
wrote:

Thanks for trying Robert.   What country should I unblock?

 

From: Icecast  <mailto:icecast-bounces at xiph.org> <icecast-bounces at xiph.org>
On Behalf Of Robert Jeffares
Sent: Tuesday, December 21, 2021 16:42
To: icecast at xiph.org <mailto:icecast at xiph.org> 
Subject: Re: [Icecast] Trouble

 

I checked here Mark but it's geoblocked

regards

Robert

On 22/12/21 9:52 am, usermark at mdrsesco.biz <mailto:usermark at mdrsesco.biz>
wrote:

icecast Was Working Fine But Now...

 

Metropolitan Washington Ear Home (washear.org) <https://www.washear.org/> 

 

The link above is the homepage for Metropolitan Washington Ear, a radio
reading service for the blind.

 

Somebody else installed Icecast on a dedicated Windows 7 PC in 2008.   Roll
forward to 2022 (almost) the live feed still works great.  But the Radio
Archive (which see on the homepage) does not.

 

I just tested it again.  By clicking one of the radio programs the browser
attempts to contact Icecast via this URL:
<http://live.washear.org/mp3s/20-09.mp3>
http://live.washear.org/mp3s/20-09.mp3

 

No response.  Dang.   

 

Mark Rockman

 






_______________________________________________
Icecast mailing list
Icecast at xiph.org <mailto:Icecast at xiph.org> 
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

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

From phschafft at de.loewenfelsen.net  Fri Dec 24 12:45:30 2021
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Fri, 24 Dec 2021 12:45:30 +0000
Subject: [Icecast] queue-size
In-Reply-To: <CAKSXWJ439+wN=4tnrGraXVsbNbByUuOyLNuY0xbJibG4WseBhQ@mail.gmail.com>
References: <CAKSXWJ7HcsB+Ua2GSHti+Nv0MWin1eAP12n5xrzx=1rHCV2e5w@mail.gmail.com>
 <bf7ca95a05d1100f70c8446ff30534c744ac4a9d.camel@de.loewenfelsen.net>
 <CAKSXWJ7SM=uPnosH=auc9Dtx1GefC1EASc_5NjWXsJ8Cur5KRQ@mail.gmail.com>
 <3814bcba6e224aaca2b173a329423376526c6b1c.camel@de.loewenfelsen.net>
 <CAKSXWJ439+wN=4tnrGraXVsbNbByUuOyLNuY0xbJibG4WseBhQ@mail.gmail.com>
Message-ID: <2639c00160edf6bc7cf3b67ee545de6d6407246f.camel@de.loewenfelsen.net>

Good morning,

On Wed, 2021-12-22 at 20:28 -0800, Milton Huang wrote:
> Wow. This has been helpful to me to really understand what is going
> on.  I'd suspected the 'audio_bitrate' was just for show.

happy to hear. :)


> So, to again make sure I'm understanding, I assume I can get the
> actual (average) transfer rate of data to a particular user for a
> particular session by taking the access.log BYTES = total bytes of
> data sent (other than headers) and dividing by TIME = seconds that
> the connection lasted.

Generally this is the way to go. However with the limit of BYTES and
TIME being big enough. See below.


> This varies depending on many of the factors you mention,
> particularly the amount of information in the signal.  And for those
> reasons, it can be misleading if measured in a very short window.

Correct.


> I just looked at one of my logs and saw a huge spread for the 1
> second duration... Don't know how to post pictures though...


That is right. There are a number of factors here that need to be kept
in mind for very short connections:

First of all Icecast sends the burst (of wich we know the estimated
size from the configuration, but again: exact size is unknown to us as
it depends on the signal at given point in time):

The burst is sent as fast as possible. The time it takes depend on the
connection's performance (speed, delay, and jitter), as well as the
state of Icecast and the operating system and their configuration.

E.g. if you have a burst of 128kByte (= 1024kBit = 1MBit), a connection
speed of 10MBit/s, a delay of 64ms, an jitter of +/- 10ms, and a TCP
Window of 64kByte a initial estimation would be:

TIME_Burst = (1MBit / 10Mit/s) + 3*64ms              +/- 4*10ms
             Connection speed    delay for SYN-ACK,  Jitter matching
                                 ACK, and final ACK  delays + one for
                                                     data jitter
->           100ms             + 192ms               +/- 40ms
->           292ms +/- 40ms (252ms .. 332ms)

This ignores the internal operation of Icecast and the operating system
(such as effects of multitasking).


After the burst the actual data transmission begins. Let's call that
TIME_Streaming, and BYTES_Streaming.

After the streaming the client disconnects (we ignore "being kicked by
the admin" here):

Depending on whether the client sends a RST or times out (by stalling
the connection; we also ignore the buffer state of the client as we are
interested in the bitrate, not the playback time):

TIME_Termination = 1*delay +/- 1*jitter + (0 .. ~Queue_Size/~bitrate)
BYTES_Termination = 0 .. ~Queue_Size

(Please note that we are only using approximations here for the reasons
already discussed.)

Let us use the Example of Queue_Size = 512kByte (= 4096
kBit), bitrate = 112kbit/s:

TIME_Termination = 64ms +/- 10ms + (0 .. (~ 4096 kBit / 112kbit/s)
->   
64ms +/- 10ms + (0 .. ~36000ms)
->                 54ms .. ~36074ms
BYTES
_Termination = 0 .. ~Queue_Size
->                  0 .. 512kByte


The access.log now logs the sum:
TIME = TIME_Burst + TIME_Streaming + TIME_Termination +/- TIME_e,
BYTES = BYTES_Burst + BYTES_Streaming + BYTES_Termination +/- BYTES_e.

However the TIME in access.log has a limited resolution of 1 second.
Which means that it can not be better than +/- 0.5s as it can not
provide "steps in between". In Addition there is clock-
desynchronisation from the operating system (basically the clocks from
all the cores tick a little bit differently) adding another +/-0.5s,
and finally there are rounding errors adding another +/-0.5s.

So TIME_e = 3*+/-0.5s = +/-1.5s.
However in reality it is normally close to: ~TIME_e = -1s .. 0.

BYTES_e is basically 0 as this is just a count. Most real world effects
are already covered above.

Let us put our example together:

TIME = (292ms +/- 40ms) + TIME_Streaming + 54ms .. ~36074ms +/- 1500ms,
       TIME_Burst                          TIME_Termination     TIME_e,

    -> 346ms            + TIME_Streaming + (-1486ms .. 37614 ms)


BYTES = 128kByte    + BYTES_Streaming + (0 .. 512kByte)   +/- 0
        BYTES_Burst                     BYTES_Termination     BYTES_e


BITRATE = BYTES / TIME

          128kByte + BYTES_Streaming + (0 .. 512kByte) +/- 0
        = --------------------------------------------------
          346ms    + TIME_Streaming  + (-1486ms .. 37614 ms)


Let us calculate this for a TIME_Streaming = 5s and for
TIME_Streaming = 500s with a bitrate of 112kBit/s (as used above):


             128kByte + (5s * 112kBit/s) + (0 .. 512kByte) +/- 0
BITRATE_5s = ---------------------------------------------------
             346ms    +  5s              + (-1486ms .. 37614 ms)

             202752 Byte + (0 .. 524288 Byte)
           = --------------------------------
             5346 ms + (-1486ms .. 37614 ms)

          ->  36.87kBit/s .. 1471.50kBit/s
          -> (36.87kBit/s .. 1471.50kBit/s)/2 = 754.19kBit/s
             Expected: 112kBit/s

and:

               128kByte + (500s * 112kBit/s) + (0 .. 512kByte) +/- 0
BITRATE_500s = -----------------------------------------------------
               346ms    +  500s              + (-1486ms .. 37614 ms)

               7299072 Byte + (0 .. 524288 Byte)
             = ---------------------------------
               500346 ms + (-1486ms .. 37614 ms)

            ->  106.00kbit/s .. 122.51 kBit/s
            -> (106.00kbit/s .. 122.51 kBit/s)/2 = 114.26kBit/s
               Expected: 112kBit/s


Conclusion:

As clearly can be seen the shorter the amount of time for which is
measured the bigger the likely error is. This depends on both effects
of the real system as well as that calculations in form of
lim t -> 0 x/t tend to amplify nose.

The values from above can also be enhanced by estimating how much of
the burst has been sent to a given client and subtracting that on both
sides of the fraction. However this also comes with the downside of
being only a estimation and therefore is mostly of statistical value.
However it is expected to work well for connections with a connection
time still relatively low so that the burst has an important impact but
also long enough that other effects can be ignored (or otherwise
compensated).


If anyone finds errors in my calculations, feel free to point them out
(on or off list).


As always, in the hope that this was useful and did not cause more
confusion.


With best regards,

> On Tue, Dec 21, 2021 at 5:40 PM Philipp Schafft <
> phschafft at de.loewenfelsen.net> wrote:
> > Good evening,
> > 
> > On Tue, 2021-12-21 at 14:33 -0800, Milton Huang wrote:
> > > Philipp,
> > > 
> > > Thank you for your detailed and enlightening answers.
> > 
> > you're very welcome.
> > 
> > 
> > > Just to make sure I understand how 'bitrate' works here. Assuming
> > we
> > > are just working with audio to keep it simple. Let's also ignore
> > > metadata,
> > 
> > Ok. Just a word of warning to the general audience: This is a very
> > limited view on the problem and might not apply to real deployments
> > or
> > fail to be valid at random.
> > 
> > 
> > > as my use case is that I am generating an electronic music stream
> > > from ffmpeg and broadcasting that using Icecast, so I can
> > > control/calculate that.
> > 
> > 
> > > I presume that if we specify `audio_bitrate` for a particular
> > mount,
> > > that is a 'target' rate that Icecast will attempt to transmit
> > audio
> > > data at.
> > 
> > No, see below.
> > 
> > 
> > > You mentioned that the actual rate can vary. Am I right to assume
> > > this is because it is dependent on the source (ffmpeg) rate for
> > > filling the 'queue', which in turn is used to fill each buffer of
> > > each connected client?
> > 
> > No. The bitrate depends on the codec, the encoder parameters, and
> > the
> > audio. E.g. bitrate can drop to virtually (or actually) zero for
> > moments of silence as there just is no entropy to encode.
> > 
> > 
> > > If so, wouldn't it generally be best for the mount
> > `audio_bitrate` to
> > > be set to the same bitrate that the source is generating/sending
> > at?
> > 
> > It is generally recommended to set as few options on the Icecast
> > side
> > as possible. Also see below.
> > 
> > 
> > > I have the option of generating and compressing my mp3 stream at
> > > either a fixed bitrate or to use a LAME VBR setting, and from
> > what I
> > > am now understanding it seems that using a fixed bitrate could be
> > > better to avoid leading or lagging the queue buffer.
> > 
> > Generally encoding with fixed bitrate tends to harm the quality of
> > the
> > signal. How much error is introduced depends again on the codec,
> > the
> > encoder parameters, and the signal.
> > 
> > A quality based encoding is normally best as this results in the
> > encoder trying to keep the signal on the same quality level.
> > Bitrate is
> > approximately a function of entropy*quality. The more constant you
> > try
> > to keep it the more quality of the signal will change with changes
> > in
> > entropy. Change of the amount of entropy per time in a signal is a
> > very
> > common event. E.g. you have a radical change between voice and
> > music,
> > but also between different kinds of music/compositions (fade-
> > in/intro/fade-out/outro, instrumental-only, instruments+voice,
> > simpler/more complex parts of a track, ...).
> > 
> > With flexible transports such as IP based networks I see little use
> > of
> > constant or semi-constant bitrate modes. The main applications that
> > comes to mind are fixed bitrate transports channels such as radio
> > channels (e.g. GSM slots).
> > 
> > 
> > Back to Icecast:
> > Ignoring bursts and format specific headers, as well as syncing for
> > a
> > moment (which is exactly what happens once a listener is fully
> > connected) Icecast sends data out as soon as it receives it.
> > Icecast does not implement any bitrate control. There are no delays
> > (which would be the only way for Icecast to do this, as it can not
> > send
> > data before it received it). All bitrate related options are
> > cosmetic
> > only (e.g. for user friendly display in directory services).
> > 
> > Please note that this holds true for all official Icecast versions.
> > Forks or custom versions may differ here.


-- 
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: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211224/3488d203/attachment.sig>

From usermark at mdrsesco.biz  Fri Dec 24 14:09:05 2021
From: usermark at mdrsesco.biz (usermark at mdrsesco.biz)
Date: Fri, 24 Dec 2021 09:09:05 -0500
Subject: [Icecast] Trouble
In-Reply-To: <aeaa91c4-088a-1682-a5e3-1c3b4792c726@gmail.com>
References: <001701d7f6ac$ad435d80$07ca1880$@mdrsesco.biz>
 <c99122e7-24f3-9c77-0063-42406697c350@gmail.com>
 <003b01d7f6cf$7bd811a0$738834e0$@mdrsesco.biz>
 <aeaa91c4-088a-1682-a5e3-1c3b4792c726@gmail.com>
Message-ID: <004e01d7f8cf$d056ff00$7104fd00$@mdrsesco.biz>

I logged into the firewall and unblocked New Zealand.

 

From: Icecast <icecast-bounces at xiph.org> On Behalf Of Robert Jeffares
Sent: Wednesday, December 22, 2021 14:22
To: icecast at xiph.org
Subject: Re: [Icecast] Trouble

 

I am in New Zealand.

There are a LOT of Comcast servers on the route from here. 

They may be using least cost routing and moving traffic across their owned
circuits.

The issue may be external to the server.

R

On 22/12/21 2:01 pm, usermark at mdrsesco.biz <mailto:usermark at mdrsesco.biz>
wrote:

Thanks for trying Robert.   What country should I unblock?

 

From: Icecast  <mailto:icecast-bounces at xiph.org> <icecast-bounces at xiph.org>
On Behalf Of Robert Jeffares
Sent: Tuesday, December 21, 2021 16:42
To: icecast at xiph.org <mailto:icecast at xiph.org> 
Subject: Re: [Icecast] Trouble

 

I checked here Mark but it's geoblocked

regards

Robert

On 22/12/21 9:52 am, usermark at mdrsesco.biz <mailto:usermark at mdrsesco.biz>
wrote:

icecast Was Working Fine But Now...

 

Metropolitan Washington Ear Home (washear.org) <https://www.washear.org/> 

 

The link above is the homepage for Metropolitan Washington Ear, a radio
reading service for the blind.

 

Somebody else installed Icecast on a dedicated Windows 7 PC in 2008.   Roll
forward to 2022 (almost) the live feed still works great.  But the Radio
Archive (which see on the homepage) does not.

 

I just tested it again.  By clicking one of the radio programs the browser
attempts to contact Icecast via this URL:
<http://live.washear.org/mp3s/20-09.mp3>
http://live.washear.org/mp3s/20-09.mp3

 

No response.  Dang.   

 

Mark Rockman

 






_______________________________________________
Icecast mailing list
Icecast at xiph.org <mailto:Icecast at xiph.org> 
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

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

From uktony at radiocompany.net  Sat Dec 25 16:09:21 2021
From: uktony at radiocompany.net (Tony Harding)
Date: Sun, 26 Dec 2021 00:09:21 +0800
Subject: [Icecast] Icecast-KH
Message-ID: <20211225160925.310B640584@smtp2.osuosl.org>

 ?

Merry Christmas

 ?

Can I ask about the KH version here? Or is this just the standard version?

 ?

A client of mine needs to run KH and I have it working on a windows server for them. But the icecast.xml is tiny and missing several things that are in my standard version xml.

 ?

I copied and pasted in things like <location> and <support> and the server would not run. Also I tied adding ports like 80 so I can get certbot to work and it did not seem to like that either.

 ?

Suggestions from the multitude would be gratefully received.

 ?

Merry Christmas 

 ?

Tony

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

From railgun.michael at gmail.com  Sat Dec 25 16:27:51 2021
From: railgun.michael at gmail.com (Railgun)
Date: Sat, 25 Dec 2021 17:27:51 +0100
Subject: [Icecast] Icecast-KH
In-Reply-To: <20211225160925.310B640584@smtp2.osuosl.org>
References: <20211225160925.310B640584@smtp2.osuosl.org>
Message-ID: <0ab7d6e3-2798-cb66-6a18-d1073de8115d@gmail.com>

you need to use certbot not with the icecast server, and you need to 
create another typ of pam file that icececast can use it

icecast must be builded with ssl support. at some standart repo it isnt.

on ubuntu run for icecast cert:

apt-get install certbot

certbot certonly --webroot-path="/usr/share/icecast2/web" -d 'stream.example.com'

cat /etc/letsencrypt/live/stream.example.com/fullchain.pem /etc/letsencrypt/live/stream1.example.com/privkey.pem > /etc/icecast2/bundle.pem

chmod 666 /etc/icecast2/bundle.pem  (if you know the user of icecast you can run chown and not chmod)

renewl
nano /etc/letsencrypt/renewal/stream.example.com.conf

post_hook = cat /etc/letsencrypt/live/stream.example.com/fullchain.pem /etc/letsencrypt/live/stream.example/privkey.pem > /etc/icecast2/bundle.pem && service icecast2 restart

certbot renew --dry-run


Am 25.12.2021 um 17:09 schrieb Tony Harding:
>
> Merry Christmas
>
> Can I ask about the KH version here? Or is this just the standard version?
>
> A client of mine needs to run KH and I have it working on a windows 
> server for them. But the icecast.xml is tiny and missing several 
> things that are in my standard version xml.
>
> I copied and pasted in things like <location> and <support> and the 
> server would not run. Also I tied adding ports like 80 so I can get 
> certbot to work and it did not seem to like that either.
>
> Suggestions from the multitude would be gratefully received.
>
> Merry Christmas
>
> Tony
>
>
> _______________________________________________
> 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/20211225/f191d7a2/attachment.htm>

From jordan at coolmic.net  Sat Dec 25 16:52:46 2021
From: jordan at coolmic.net (Jordan Erickson)
Date: Sat, 25 Dec 2021 08:52:46 -0800
Subject: [Icecast] Icecast-KH
In-Reply-To: <20211225160925.310B640584@smtp2.osuosl.org>
References: <20211225160925.310B640584@smtp2.osuosl.org>
Message-ID: <8afb7b16-1443-dbe4-3248-0dd66c03f98f@coolmic.net>

Hi Tony,

-KH is not supported on this list and is a different animal than 
official Icecast. I'm pretty sure there's a forum or something for it 
specifically but don't quote me on it, never used it.


Cheers,
Jordan Erickson

On 12/25/21 8:09 AM, Tony Harding wrote:
>
> Merry Christmas
>
> Can I ask about the KH version here? Or is this just the standard version?
>
> A client of mine needs to run KH and I have it working on a windows 
> server for them. But the icecast.xml is tiny and missing several 
> things that are in my standard version xml.
>
> I copied and pasted in things like <location> and <support> and the 
> server would not run. Also I tied adding ports like 80 so I can get 
> certbot to work and it did not seem to like that either.
>
> Suggestions from the multitude would be gratefully received.
>
> Merry Christmas
>
> Tony
>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast

-- 
Jordan Erickson
Project Manager, Cool Mic
https://coolmic.net/

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

From uktony at radiocompany.net  Sat Dec 25 16:47:44 2021
From: uktony at radiocompany.net (Tony Harding)
Date: Sun, 26 Dec 2021 00:47:44 +0800
Subject: [Icecast] Icecast-KH
In-Reply-To: <0ab7d6e3-2798-cb66-6a18-d1073de8115d@gmail.com>
Message-ID: <20211225165505.8A32B818D7@smtp1.osuosl.org>

To use certbot you need Port80 with something on the end of it. 

 ?

If icecast is listening on port 80 certbot will work.

 ?

But I cannot get Icecast-KH to work if I put the port in icecast.xml or port 443 for that matter. 

 ?

I have certbot working on a standard icecast server 

 ?

The question is how do I get KH to work with more tags in the xml?

 ?

Tony

 ?

  _____  

From: Icecast [mailto:icecast-bounces at xiph.org] On Behalf Of Railgun
Sent: Sunday, December 26, 2021 12:28 AM
To: icecast at xiph.org
Subject: Re: [Icecast] Icecast-KH

 ?

you need to use certbot not with the icecast server, and you need to create another typ of pam file that icececast can use it

icecast must be builded with ssl support. at some standart repo it isnt.

on ubuntu run for icecast cert:

apt-get install certbot

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

From railgun.michael at gmail.com  Sat Dec 25 16:55:47 2021
From: railgun.michael at gmail.com (Railgun)
Date: Sat, 25 Dec 2021 17:55:47 +0100
Subject: [Icecast] Icecast-KH
In-Reply-To: <20211225165505.8A32B818D7@smtp1.osuosl.org>
References: <20211225165505.8A32B818D7@smtp1.osuosl.org>
Message-ID: <d71b4710-169c-7d5d-5027-3adc46325a86@gmail.com>

erase kh and use a normal icecast

Am 25.12.2021 um 17:47 schrieb Tony Harding:
>
> To use certbot you need Port80 with something on the end of it.
>
> If icecast is listening on port 80 certbot will work.
>
> But I cannot get Icecast-KH to work if I put the port in icecast.xml 
> or port 443 for that matter.
>
> I have certbot working on a standard icecast server
>
> The question is how do I get KH to work with more tags in the xml?
>
> Tony
>
> ------------------------------------------------------------------------
>
> *From:*Icecast [mailto:icecast-bounces at xiph.org] *On Behalf Of *Railgun
> *Sent:* Sunday, December 26, 2021 12:28 AM
> *To:* icecast at xiph.org
> *Subject:* Re: [Icecast] Icecast-KH
>
> you need to use certbot not with the icecast server, and you need to 
> create another typ of pam file that icececast can use it
>
> icecast must be builded with ssl support. at some standart repo it isnt.
>
> on ubuntu run for icecast cert:
>
> apt-get install certbot
> certbot certonly --webroot-path="/usr/share/icecast2/web" -d 
> 'stream.example.com'
> cat /etc/letsencrypt/live/stream.example.com/fullchain.pem 
> /etc/letsencrypt/live/stream1.example.com/privkey.pem > 
> /etc/icecast2/bundle.pem
> chmod 666 /etc/icecast2/bundle.pem? (if you know the user of icecast 
> you can run chown and not chmod)
> renewl
> nano /etc/letsencrypt/renewal/stream.example.com.conf
> post_hook = cat /etc/letsencrypt/live/stream.example.com/fullchain.pem 
> /etc/letsencrypt/live/stream.example/privkey.pem > 
> /etc/icecast2/bundle.pem && service icecast2 restart
> certbot renew --dry-run
>
> Am 25.12.2021 um 17:09 schrieb Tony Harding:
>
>> Merry Christmas
>>
>> Can I ask about the KH version here? Or is this just the standard 
>> version?
>>
>> A client of mine needs to run KH and I have it working on a windows 
>> server for them. But the icecast.xml is tiny and missing several 
>> things that are in my standard version xml.
>>
>> I copied and pasted in things like <location> and <support> and the 
>> server would not run. Also I tied adding ports like 80 so I can get 
>> certbot to work and it did not seem to like that either.
>>
>> Suggestions from the multitude would be gratefully received.
>>
>> Merry Christmas
>>
>> Tony
>>
>>
>>
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211225/3758c4d5/attachment.htm>

From uktony at radiocompany.net  Sat Dec 25 18:23:47 2021
From: uktony at radiocompany.net (uktony)
Date: Sun, 26 Dec 2021 02:23:47 +0800
Subject: [Icecast] Icecast-KH
In-Reply-To: <d71b4710-169c-7d5d-5027-3adc46325a86@gmail.com>
Message-ID: <20211225182353.EFB7A405A1@smtp2.osuosl.org>

Unfortunately some music licensing agents insist on KH being used. So that is why I am struggling like this.TonySent from my Galaxy
-------- Original message --------From: Railgun <railgun.michael at gmail.com> Date: 26/12/2021  00:55  (GMT+08:00) To: icecast at xiph.org Subject: Re: [Icecast] Icecast-KH 
    erase kh and use a normal icecast
    
    Am 25.12.2021 um 17:47 schrieb Tony
      Harding:
    
    
      
      
      
      @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}pre
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}span.EmailStyle19
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}span.EmailStyle20
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}span.EmailStyle21
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}div.Section1
	{page:Section1;}
      
      
        To use certbot you
              need Port80 with
              something on the end of it. 
        ?
        If icecast is
              listening on port 80 certbot
              will work.
        ?
        But I cannot get
              Icecast-KH to work if I
              put the port in icecast.xml or port 443 for that matter. 
        ?
        I have certbot
              working on a standard
              icecast server 
        ?
        The question is how
              do I get KH to work
              with more tags in the xml?
        ?
        Tony
        ?
        
          
                
              
          From:
                Icecast [mailto:icecast-bounces at xiph.org] On
                    Behalf Of Railgun
                Sent:
                Sunday, December 26, 2021
                12:28 AM
                To:
                icecast at xiph.org
                Subject:
                Re: [Icecast] Icecast-KH
        
        ?
        you need
              to use certbot not with the icecast server, and you need
              to create another typ
              of pam file that icececast can use it
        icecast
              must be builded with ssl support. at some standart repo it
              isnt.
        on ubuntu
              run for icecast cert:
        apt-get install certbot
        ?
        certbot certonly --webroot-path="/usr/share/icecast2/web" -d 'stream.example.com'
        ?
        cat /etc/letsencrypt/live/stream.example.com/fullchain.pem /etc/letsencrypt/live/stream1.example.com/privkey.pem > /etc/icecast2/bundle.pem
        ?
        chmod 666 /etc/icecast2/bundle.pem? (if you know the user of icecast you can run chown and not chmod)
        ?
        renewl
        nano /etc/letsencrypt/renewal/stream.example.com.conf
        ?
        post_hook = cat /etc/letsencrypt/live/stream.example.com/fullchain.pem /etc/letsencrypt/live/stream.example/privkey.pem > /etc/icecast2/bundle.pem && service icecast2 restart
        ?
        certbot renew --dry-run
        ?
        ?
        
          Am 25.12.2021 um 17:09 schrieb Tony Harding:
        
        
          ?
          
            Merry Christmas
          
          
          ?
          Can I ask about the KH version here?
                Or is this just the
                standard version?
          ?
          A client of mine needs to run KH and
                I have it working on a
                windows server for them. But the icecast.xml is tiny and
                missing several things
                that are in my standard version xml.
          ?
          I copied and pasted in things like
                <location> and
                <support> and the server would not run. Also I
                tied adding ports like 80
                so I can get certbot to work and it did not seem to like
                that either.
          ?
          Suggestions from the multitude would
                be gratefully received.
          ?
          Merry Christmas 
          ?
          Tony
          
                
                
          
          _______________________________________________
          Icecast mailing list
          Icecast at xiph.org
          http://lists.xiph.org/mailman/listinfo/icecast
        
      
      
      
      _______________________________________________
Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast

    
  

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

From gavin at stephens.net.nz  Sun Dec 26 05:41:56 2021
From: gavin at stephens.net.nz (Gavin Stephens)
Date: Sun, 26 Dec 2021 18:41:56 +1300
Subject: [Icecast] Icecast-KH
In-Reply-To: <d71b4710-169c-7d5d-5027-3adc46325a86@gmail.com>
References: <20211225165505.8A32B818D7@smtp1.osuosl.org>
 <d71b4710-169c-7d5d-5027-3adc46325a86@gmail.com>
Message-ID: <1b7d140a-dbb8-0638-7af3-909b1b17bf48@stephens.net.nz>

Can you re-load the config in the normal version yet without having to 
boot all the mount points?

That's the only reason I have used kh.

On 26/12/2021 5:55 am, Railgun wrote:
>
> erase kh and use a normal icecast
>
> Am 25.12.2021 um 17:47 schrieb Tony Harding:
>>
>> To use certbot you need Port80 with something on the end of it.
>>
>> If icecast is listening on port 80 certbot will work.
>>
>> But I cannot get Icecast-KH to work if I put the port in icecast.xml 
>> or port 443 for that matter.
>>
>> I have certbot working on a standard icecast server
>>
>> The question is how do I get KH to work with more tags in the xml?
>>
>> Tony
>>
>> ------------------------------------------------------------------------
>>
>> *From:*Icecast [mailto:icecast-bounces at xiph.org] *On Behalf Of *Railgun
>> *Sent:* Sunday, December 26, 2021 12:28 AM
>> *To:* icecast at xiph.org
>> *Subject:* Re: [Icecast] Icecast-KH
>>
>> you need to use certbot not with the icecast server, and you need to 
>> create another typ of pam file that icececast can use it
>>
>> icecast must be builded with ssl support. at some standart repo it isnt.
>>
>> on ubuntu run for icecast cert:
>>
>> apt-get install certbot
>> certbot certonly --webroot-path="/usr/share/icecast2/web" -d 
>> 'stream.example.com'
>> cat /etc/letsencrypt/live/stream.example.com/fullchain.pem 
>> /etc/letsencrypt/live/stream1.example.com/privkey.pem > 
>> /etc/icecast2/bundle.pem
>> chmod 666 /etc/icecast2/bundle.pem? (if you know the user of icecast 
>> you can run chown and not chmod)
>> renewl
>> nano /etc/letsencrypt/renewal/stream.example.com.conf
>> post_hook = cat 
>> /etc/letsencrypt/live/stream.example.com/fullchain.pem 
>> /etc/letsencrypt/live/stream.example/privkey.pem > 
>> /etc/icecast2/bundle.pem && service icecast2 restart
>> certbot renew --dry-run
>>
>> Am 25.12.2021 um 17:09 schrieb Tony Harding:
>>
>>> Merry Christmas
>>>
>>> Can I ask about the KH version here? Or is this just the standard 
>>> version?
>>>
>>> A client of mine needs to run KH and I have it working on a windows 
>>> server for them. But the icecast.xml is tiny and missing several 
>>> things that are in my standard version xml.
>>>
>>> I copied and pasted in things like <location> and <support> and the 
>>> server would not run. Also I tied adding ports like 80 so I can get 
>>> certbot to work and it did not seem to like that either.
>>>
>>> Suggestions from the multitude would be gratefully received.
>>>
>>> Merry Christmas
>>>
>>> Tony
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> 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/20211226/695e9d9a/attachment.htm>

From railgun.michael at gmail.com  Sun Dec 26 10:30:12 2021
From: railgun.michael at gmail.com (Railgun)
Date: Sun, 26 Dec 2021 11:30:12 +0100
Subject: [Icecast] Icecast-KH
In-Reply-To: <1b7d140a-dbb8-0638-7af3-909b1b17bf48@stephens.net.nz>
References: <20211225165505.8A32B818D7@smtp1.osuosl.org>
 <d71b4710-169c-7d5d-5027-3adc46325a86@gmail.com>
 <1b7d140a-dbb8-0638-7af3-909b1b17bf48@stephens.net.nz>
Message-ID: <CAOUVwuudYs4nNcEtCXHoVkiGB1GbxeTLYTd537=2TXAR3VqoQg@mail.gmail.com>

If you use the stabile Branche from github (Version 4.49xxxx) yes

Gavin Stephens <gavin at stephens.net.nz> schrieb am So., 26. Dez. 2021, 06:42:

> Can you re-load the config in the normal version yet without having to
> boot all the mount points?
>
> That's the only reason I have used kh.
> On 26/12/2021 5:55 am, Railgun wrote:
>
> erase kh and use a normal icecast
> Am 25.12.2021 um 17:47 schrieb Tony Harding:
>
> To use certbot you need Port80 with something on the end of it.
>
>
>
> If icecast is listening on port 80 certbot will work.
>
>
>
> But I cannot get Icecast-KH to work if I put the port in icecast.xml or
> port 443 for that matter.
>
>
>
> I have certbot working on a standard icecast server
>
>
>
> The question is how do I get KH to work with more tags in the xml?
>
>
>
> Tony
>
>
> ------------------------------
>
> *From:* Icecast [mailto:icecast-bounces at xiph.org
> <icecast-bounces at xiph.org>] *On Behalf Of *Railgun
> *Sent:* Sunday, December 26, 2021 12:28 AM
> *To:* icecast at xiph.org
> *Subject:* Re: [Icecast] Icecast-KH
>
>
>
> you need to use certbot not with the icecast server, and you need to
> create another typ of pam file that icececast can use it
>
> icecast must be builded with ssl support. at some standart repo it isnt.
>
> on ubuntu run for icecast cert:
>
> apt-get install certbot
>
>
>
> certbot certonly --webroot-path="/usr/share/icecast2/web" -d 'stream.example.com'
>
>
>
> cat /etc/letsencrypt/live/stream.example.com/fullchain.pem /etc/letsencrypt/live/stream1.example.com/privkey.pem > /etc/icecast2/bundle.pem
>
>
>
> chmod 666 /etc/icecast2/bundle.pem  (if you know the user of icecast you can run chown and not chmod)
>
>
>
> renewl
>
> nano /etc/letsencrypt/renewal/stream.example.com.conf
>
>
>
> post_hook = cat /etc/letsencrypt/live/stream.example.com/fullchain.pem /etc/letsencrypt/live/stream.example/privkey.pem > /etc/icecast2/bundle.pem && service icecast2 restart
>
>
>
> certbot renew --dry-run
>
>
>
>
>
> Am 25.12.2021 um 17:09 schrieb Tony Harding:
>
>
>
> Merry Christmas
>
>
>
> Can I ask about the KH version here? Or is this just the standard version?
>
>
>
> A client of mine needs to run KH and I have it working on a windows server
> for them. But the icecast.xml is tiny and missing several things that are
> in my standard version xml.
>
>
>
> I copied and pasted in things like <location> and <support> and the server
> would not run. Also I tied adding ports like 80 so I can get certbot to
> work and it did not seem to like that either.
>
>
>
> Suggestions from the multitude would be gratefully received.
>
>
>
> Merry Christmas
>
>
>
> Tony
>
>
>
> _______________________________________________
>
> Icecast mailing list
>
> Icecast at xiph.org
>
> http://lists.xiph.org/mailman/listinfo/icecast
>
>
> _______________________________________________
> Icecast mailing listIcecast at xiph.orghttp://lists.xiph.org/mailman/listinfo/icecast
>
>
> _______________________________________________
> Icecast mailing listIcecast at xiph.orghttp://lists.xiph.org/mailman/listinfo/icecast
>
>
>
> <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>
> <#m_-119081770187375379_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> _______________________________________________
> 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/20211226/7c198454/attachment.htm>

From mph at emotrics.com  Wed Dec 29 22:16:11 2021
From: mph at emotrics.com (Milton Huang)
Date: Wed, 29 Dec 2021 14:16:11 -0800
Subject: [Icecast] queue-size
In-Reply-To: <2639c00160edf6bc7cf3b67ee545de6d6407246f.camel@de.loewenfelsen.net>
References: <CAKSXWJ7HcsB+Ua2GSHti+Nv0MWin1eAP12n5xrzx=1rHCV2e5w@mail.gmail.com>
 <bf7ca95a05d1100f70c8446ff30534c744ac4a9d.camel@de.loewenfelsen.net>
 <CAKSXWJ7SM=uPnosH=auc9Dtx1GefC1EASc_5NjWXsJ8Cur5KRQ@mail.gmail.com>
 <3814bcba6e224aaca2b173a329423376526c6b1c.camel@de.loewenfelsen.net>
 <CAKSXWJ439+wN=4tnrGraXVsbNbByUuOyLNuY0xbJibG4WseBhQ@mail.gmail.com>
 <2639c00160edf6bc7cf3b67ee545de6d6407246f.camel@de.loewenfelsen.net>
Message-ID: <CAKSXWJ7bDRRgem5AYjrYK3ApqkpnzubpXgasuq_La5-L8PyhwA@mail.gmail.com>

Man, that was awesome. I think that formula should be put in the doc pages
somewhere, as it really clarifies what that code is doing.

Thanks for all the details!

On Fri, Dec 24, 2021 at 4:45 AM Philipp Schafft <
phschafft at de.loewenfelsen.net> wrote:

> Good morning,
>
> On Wed, 2021-12-22 at 20:28 -0800, Milton Huang wrote:
> > Wow. This has been helpful to me to really understand what is going
> > on.  I'd suspected the 'audio_bitrate' was just for show.
>
> happy to hear. :)
>
>
> > So, to again make sure I'm understanding, I assume I can get the
> > actual (average) transfer rate of data to a particular user for a
> > particular session by taking the access.log BYTES = total bytes of
> > data sent (other than headers) and dividing by TIME = seconds that
> > the connection lasted.
>
> Generally this is the way to go. However with the limit of BYTES and
> TIME being big enough. See below.
>
>
> > This varies depending on many of the factors you mention,
> > particularly the amount of information in the signal.  And for those
> > reasons, it can be misleading if measured in a very short window.
>
> Correct.
>
>
> > I just looked at one of my logs and saw a huge spread for the 1
> > second duration... Don't know how to post pictures though...
>
>
> That is right. There are a number of factors here that need to be kept
> in mind for very short connections:
>
> First of all Icecast sends the burst (of wich we know the estimated
> size from the configuration, but again: exact size is unknown to us as
> it depends on the signal at given point in time):
>
> The burst is sent as fast as possible. The time it takes depend on the
> connection's performance (speed, delay, and jitter), as well as the
> state of Icecast and the operating system and their configuration.
>
> E.g. if you have a burst of 128kByte (= 1024kBit = 1MBit), a connection
> speed of 10MBit/s, a delay of 64ms, an jitter of +/- 10ms, and a TCP
> Window of 64kByte a initial estimation would be:
>
> TIME_Burst = (1MBit / 10Mit/s) + 3*64ms              +/- 4*10ms
>              Connection speed    delay for SYN-ACK,  Jitter matching
>                                  ACK, and final ACK  delays + one for
>                                                      data jitter
> ->           100ms             + 192ms               +/- 40ms
> ->           292ms +/- 40ms (252ms .. 332ms)
>
> This ignores the internal operation of Icecast and the operating system
> (such as effects of multitasking).
>
>
> After the burst the actual data transmission begins. Let's call that
> TIME_Streaming, and BYTES_Streaming.
>
> After the streaming the client disconnects (we ignore "being kicked by
> the admin" here):
>
> Depending on whether the client sends a RST or times out (by stalling
> the connection; we also ignore the buffer state of the client as we are
> interested in the bitrate, not the playback time):
>
> TIME_Termination = 1*delay +/- 1*jitter + (0 .. ~Queue_Size/~bitrate)
> BYTES_Termination = 0 .. ~Queue_Size
>
> (Please note that we are only using approximations here for the reasons
> already discussed.)
>
> Let us use the Example of Queue_Size = 512kByte (= 4096
> kBit), bitrate = 112kbit/s:
>
> TIME_Termination = 64ms +/- 10ms + (0 .. (~ 4096 kBit / 112kbit/s)
> ->
> 64ms +/- 10ms + (0 .. ~36000ms)
> ->                 54ms .. ~36074ms
> BYTES
> _Termination = 0 .. ~Queue_Size
> ->                  0 .. 512kByte
>
>
> The access.log now logs the sum:
> TIME = TIME_Burst + TIME_Streaming + TIME_Termination +/- TIME_e,
> BYTES = BYTES_Burst + BYTES_Streaming + BYTES_Termination +/- BYTES_e.
>
> However the TIME in access.log has a limited resolution of 1 second.
> Which means that it can not be better than +/- 0.5s as it can not
> provide "steps in between". In Addition there is clock-
> desynchronisation from the operating system (basically the clocks from
> all the cores tick a little bit differently) adding another +/-0.5s,
> and finally there are rounding errors adding another +/-0.5s.
>
> So TIME_e = 3*+/-0.5s = +/-1.5s.
> However in reality it is normally close to: ~TIME_e = -1s .. 0.
>
> BYTES_e is basically 0 as this is just a count. Most real world effects
> are already covered above.
>
> Let us put our example together:
>
> TIME = (292ms +/- 40ms) + TIME_Streaming + 54ms .. ~36074ms +/- 1500ms,
>        TIME_Burst                          TIME_Termination     TIME_e,
>
>     -> 346ms            + TIME_Streaming + (-1486ms .. 37614 ms)
>
>
> BYTES = 128kByte    + BYTES_Streaming + (0 .. 512kByte)   +/- 0
>         BYTES_Burst                     BYTES_Termination     BYTES_e
>
>
> BITRATE = BYTES / TIME
>
>           128kByte + BYTES_Streaming + (0 .. 512kByte) +/- 0
>         = --------------------------------------------------
>           346ms    + TIME_Streaming  + (-1486ms .. 37614 ms)
>
>
> Let us calculate this for a TIME_Streaming = 5s and for
> TIME_Streaming = 500s with a bitrate of 112kBit/s (as used above):
>
>
>              128kByte + (5s * 112kBit/s) + (0 .. 512kByte) +/- 0
> BITRATE_5s = ---------------------------------------------------
>              346ms    +  5s              + (-1486ms .. 37614 ms)
>
>              202752 Byte + (0 .. 524288 Byte)
>            = --------------------------------
>              5346 ms + (-1486ms .. 37614 ms)
>
>           ->  36.87kBit/s .. 1471.50kBit/s
>           -> (36.87kBit/s .. 1471.50kBit/s)/2 = 754.19kBit/s
>              Expected: 112kBit/s
>
> and:
>
>                128kByte + (500s * 112kBit/s) + (0 .. 512kByte) +/- 0
> BITRATE_500s = -----------------------------------------------------
>                346ms    +  500s              + (-1486ms .. 37614 ms)
>
>                7299072 Byte + (0 .. 524288 Byte)
>              = ---------------------------------
>                500346 ms + (-1486ms .. 37614 ms)
>
>             ->  106.00kbit/s .. 122.51 kBit/s
>             -> (106.00kbit/s .. 122.51 kBit/s)/2 = 114.26kBit/s
>                Expected: 112kBit/s
>
>
> Conclusion:
>
> As clearly can be seen the shorter the amount of time for which is
> measured the bigger the likely error is. This depends on both effects
> of the real system as well as that calculations in form of
> lim t -> 0 x/t tend to amplify nose.
>
> The values from above can also be enhanced by estimating how much of
> the burst has been sent to a given client and subtracting that on both
> sides of the fraction. However this also comes with the downside of
> being only a estimation and therefore is mostly of statistical value.
> However it is expected to work well for connections with a connection
> time still relatively low so that the burst has an important impact but
> also long enough that other effects can be ignored (or otherwise
> compensated).
>
>
> If anyone finds errors in my calculations, feel free to point them out
> (on or off list).
>
>
> As always, in the hope that this was useful and did not cause more
> confusion.
>
>
> With best regards,
>
> > On Tue, Dec 21, 2021 at 5:40 PM Philipp Schafft <
> > phschafft at de.loewenfelsen.net> wrote:
> > > Good evening,
> > >
> > > On Tue, 2021-12-21 at 14:33 -0800, Milton Huang wrote:
> > > > Philipp,
> > > >
> > > > Thank you for your detailed and enlightening answers.
> > >
> > > you're very welcome.
> > >
> > >
> > > > Just to make sure I understand how 'bitrate' works here. Assuming
> > > we
> > > > are just working with audio to keep it simple. Let's also ignore
> > > > metadata,
> > >
> > > Ok. Just a word of warning to the general audience: This is a very
> > > limited view on the problem and might not apply to real deployments
> > > or
> > > fail to be valid at random.
> > >
> > >
> > > > as my use case is that I am generating an electronic music stream
> > > > from ffmpeg and broadcasting that using Icecast, so I can
> > > > control/calculate that.
> > >
> > >
> > > > I presume that if we specify `audio_bitrate` for a particular
> > > mount,
> > > > that is a 'target' rate that Icecast will attempt to transmit
> > > audio
> > > > data at.
> > >
> > > No, see below.
> > >
> > >
> > > > You mentioned that the actual rate can vary. Am I right to assume
> > > > this is because it is dependent on the source (ffmpeg) rate for
> > > > filling the 'queue', which in turn is used to fill each buffer of
> > > > each connected client?
> > >
> > > No. The bitrate depends on the codec, the encoder parameters, and
> > > the
> > > audio. E.g. bitrate can drop to virtually (or actually) zero for
> > > moments of silence as there just is no entropy to encode.
> > >
> > >
> > > > If so, wouldn't it generally be best for the mount
> > > `audio_bitrate` to
> > > > be set to the same bitrate that the source is generating/sending
> > > at?
> > >
> > > It is generally recommended to set as few options on the Icecast
> > > side
> > > as possible. Also see below.
> > >
> > >
> > > > I have the option of generating and compressing my mp3 stream at
> > > > either a fixed bitrate or to use a LAME VBR setting, and from
> > > what I
> > > > am now understanding it seems that using a fixed bitrate could be
> > > > better to avoid leading or lagging the queue buffer.
> > >
> > > Generally encoding with fixed bitrate tends to harm the quality of
> > > the
> > > signal. How much error is introduced depends again on the codec,
> > > the
> > > encoder parameters, and the signal.
> > >
> > > A quality based encoding is normally best as this results in the
> > > encoder trying to keep the signal on the same quality level.
> > > Bitrate is
> > > approximately a function of entropy*quality. The more constant you
> > > try
> > > to keep it the more quality of the signal will change with changes
> > > in
> > > entropy. Change of the amount of entropy per time in a signal is a
> > > very
> > > common event. E.g. you have a radical change between voice and
> > > music,
> > > but also between different kinds of music/compositions (fade-
> > > in/intro/fade-out/outro, instrumental-only, instruments+voice,
> > > simpler/more complex parts of a track, ...).
> > >
> > > With flexible transports such as IP based networks I see little use
> > > of
> > > constant or semi-constant bitrate modes. The main applications that
> > > comes to mind are fixed bitrate transports channels such as radio
> > > channels (e.g. GSM slots).
> > >
> > >
> > > Back to Icecast:
> > > Ignoring bursts and format specific headers, as well as syncing for
> > > a
> > > moment (which is exactly what happens once a listener is fully
> > > connected) Icecast sends data out as soon as it receives it.
> > > Icecast does not implement any bitrate control. There are no delays
> > > (which would be the only way for Icecast to do this, as it can not
> > > send
> > > data before it received it). All bitrate related options are
> > > cosmetic
> > > only (e.g. for user friendly display in directory services).
> > >
> > > Please note that this holds true for all official Icecast versions.
> > > Forks or custom versions may differ here.
>
>
> --
> 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
> _______________________________________________
> 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/20211229/14843e7b/attachment.htm>

From mph at emotrics.com  Wed Dec 29 22:37:40 2021
From: mph at emotrics.com (Milton Huang)
Date: Wed, 29 Dec 2021 14:37:40 -0800
Subject: [Icecast] URL authentication failing
In-Reply-To: <CAKSXWJ6dsHF-mkJM5pHtb=_SkuazVMDKGoDpqpCMjykJ2jt6oA@mail.gmail.com>
References: <CAKSXWJ6dsHF-mkJM5pHtb=_SkuazVMDKGoDpqpCMjykJ2jt6oA@mail.gmail.com>
Message-ID: <CAKSXWJ7w0fbhVebXbuRSNcYwLe2YgtiJUqtaqQM6Fs4=V70wLg@mail.gmail.com>

In case anyone is interested, I eventually figured out that despite the
error.log message, the `option name` should be `auth_header`. I guess the
warning is for an update that hasn't been applied yet.

On Tue, Nov 30, 2021 at 10:08 PM Milton Huang <mph at emotrics.com> wrote:

> I'm using a compiled version of Icecast (2.4.99.2) for TLS and having
> problems tracking down where URL authentication is failing.  My icecast.xml
> mount is:
>
>         <mount-name>/teststream.mp3</mount-name>
>         <authentication>
>             <role type="url" match-method="get,post,head,options"
> allow-web="*" deny-admin="*" may-alter="send_error,redirect">
>                 <option name="client_add"       value="
> https://posthere.io/79f1-4499"/>
>                 <option name="client_remove"    value="
> https://posthere.io/79f1-4499"/>
>                 <option name="action_add"       value="listener_add"/>
>                 <option name="action_remove"    value="listener_remove"/>
>                 <option name="headers"
>  value="x-pragma,x-token,auth"/>
>                 <option name="header_prefix"    value=""/>
>                 <option name="header_auth"      value="HTTP/1.1 200 OK"/>
>                 <option name="header_timelimit" value=""/>
>             </role>
>             <role type="anonymous" match-method="get,post,head,options"
> deny-all="*" />
>         </authentication>
>
> (I tried it first with "auth_header" like in the online doc, but changed
> it to "header_auth" based on the messages in error.log) When I try to
> access the stream, Icecast sends the correct POST to posthere.io to check
> authentication. But in the error logs it says:
>
> [2021-12-01  02:50:56] INFO auth/queue_auth_client auth on /teststream.mp3
> has 1 pending
> [2021-12-01  02:50:56] INFO auth_url/url_add_client client auth (
> https://posthere.io/79f1-4499-9c2e) failed with ""
> [2021-12-01  02:50:56] WARN reportxml/reportxml_database_build_report No
> matching definition for "253444798-0643-4577-9139"
>
> So it looks like auth failed. But why is it failing with ""? Does that
> mean it didn't get the "HTTP/1.1 200 OK" response that posthere sent back?
> Any suggestions on figuring this out?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211229/4dacbab2/attachment.htm>

From mph at emotrics.com  Wed Dec 29 22:54:56 2021
From: mph at emotrics.com (Milton Huang)
Date: Wed, 29 Dec 2021 14:54:56 -0800
Subject: [Icecast] listclients with url authentication
Message-ID: <CAKSXWJ4oWAXHv-Wf5ekCQNgBEOR1soLUt5jVxZ9cCZOdYoe3rA@mail.gmail.com>

I'm using  the latest Icecast (2.4.99.2) compiled for TLS and having a
problem using the `listclients` page. It works fine if the URL
authentication is not used. Also pages like `/admin/stats` are available
with the standard basic authentication. But, when trying to get the client
list from `/admin/listclients?mount=stream`, the host responds with
<text>You need to authenticate</text> message.

This may be related to the issue described by
https://gitlab.xiph.org/xiph/icecast-server/-/issues/2387, although I am
*NOT* doing stream authentication, so this is even simpler.

Is there a work around for this? Is this an appropriate place to bring this
up, or should I be commenting over there?  Any other steps I can do to help
explore this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20211229/9fafac70/attachment.htm>

From rlbart53 at gmail.com  Thu Dec 30 22:22:03 2021
From: rlbart53 at gmail.com (Richard Bartholomew)
Date: Thu, 30 Dec 2021 22:22:03 -0000
Subject: [Icecast] ACCESSING STATS
Message-ID: <034d01d7fdcb$ac89f630$059de290$@gmail.com>

Hi,

 

I am using Icecast 2.4.4 and can access the list of clients with
<domain.com>:port/admin/listclients?mount=<stream> and supplying the
username and password.

 

However, I would like to be able to access this page programmatically using
either python or php so that I can automate some tasks but can't find a way
of providing the username and password.

 

Is there a way, please, of being able to do this so that the login page can
be circumvented?

 

Thanks for any help.

 

Regards

Richard Bartholomew

 

 

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

From marius at flage.org  Thu Dec 30 22:33:13 2021
From: marius at flage.org (Marius Flage)
Date: Thu, 30 Dec 2021 23:33:13 +0100
Subject: [Icecast] ACCESSING STATS
In-Reply-To: <034d01d7fdcb$ac89f630$059de290$@gmail.com>
References: <034d01d7fdcb$ac89f630$059de290$@gmail.com>
Message-ID: <1bd0b1a1-d9fc-6f08-4957-beceae3b674a@flage.org>

If you use Python, for instance, you can use the requests module and 
then supply the username/password using the auth dict:

r = requests.get(URL, auth=(username, password))

--
Marius

On 30.12.2021 23:22, Richard Bartholomew wrote:
>
> Hi,
>
> I am using Icecast 2.4.4 and can access the list of clients with 
> <domain.com>:port/admin/listclients?mount=<stream> and supplying the 
> username and password.
>
> However, I would like to be able to access this page programmatically 
> using either python or php so that I can automate some tasks but can't 
> find a way of providing the username and password.
>
> Is there a way, please, of being able to do this so that the login 
> page can be circumvented?
>
> Thanks for any help.
>
> Regards
>
> Richard Bartholomew
>
>
> _______________________________________________
> 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/20211230/a14f15f3/attachment.htm>

From un at aporee.org  Fri Dec 31 08:27:39 2021
From: un at aporee.org (uno)
Date: Fri, 31 Dec 2021 09:27:39 +0100
Subject: [Icecast] ACCESSING STATS
In-Reply-To: <034d01d7fdcb$ac89f630$059de290$@gmail.com>
References: <034d01d7fdcb$ac89f630$059de290$@gmail.com>
Message-ID: <1ce19be9-3ad6-aae8-538a-dd716cc25cf8@aporee.org>

check php/curl/simplexml:

/* url, eg: http://127.0.0.1:8000/admin/viewxml.xsl?mount=/yourmount */

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_USERPWD, ICECAST_LOGIN);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION,0);
curl_setopt($ch, CURLOPT_TIMEOUT, 5);

$result = curl_exec($ch);
curl_close($ch);

if($result) {

try {
 ???? $xml = new SimpleXMLElement($result);
 ???? $listeners = $xml->LISTENERS->LISTENER;

...
}

Am 30.12.21 um 23:22 schrieb Richard Bartholomew:
>
> Hi,
>
> I am using Icecast 2.4.4 and can access the list of clients with 
> <domain.com>:port/admin/listclients?mount=<stream> and supplying the 
> username and password.
>
> However, I would like to be able to access this page programmatically 
> using either python or php so that I can automate some tasks but can't 
> find a way of providing the username and password.
>
> Is there a way, please, of being able to do this so that the login 
> page can be circumvented?
>
> Thanks for any help.
>
> Regards
>
> Richard Bartholomew
>
>
> _______________________________________________
> 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/20211231/cbd5af4e/attachment.htm>

From rlbart53 at gmail.com  Fri Dec 31 09:22:58 2021
From: rlbart53 at gmail.com (Richard Bartholomew)
Date: Fri, 31 Dec 2021 09:22:58 -0000
Subject: [Icecast] ACCESSING STATS
In-Reply-To: <1ce19be9-3ad6-aae8-538a-dd716cc25cf8@aporee.org>
References: <034d01d7fdcb$ac89f630$059de290$@gmail.com>
 <1ce19be9-3ad6-aae8-538a-dd716cc25cf8@aporee.org>
Message-ID: <006001d7fe28$01e6f860$05b4e920$@gmail.com>

Thanks very much to both Uno and Marius...exactly the guidance I needed.

 

Happy New Year to all

 

Richard Bartholomew

 

 

From: Icecast <icecast-bounces at xiph.org> On Behalf Of uno
Sent: 31 December 2021 08:28
To: icecast at xiph.org
Subject: Re: [Icecast] ACCESSING STATS

 

check php/curl/simplexml:

/* url, eg:  http://127.0.0.1:8000/admin/viewxml.xsl?mount=/yourmount */

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_USERPWD, ICECAST_LOGIN);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION,0);
curl_setopt($ch, CURLOPT_TIMEOUT, 5);

$result = curl_exec($ch);
curl_close($ch);

if($result) {

try {
     $xml = new SimpleXMLElement($result);
     $listeners = $xml->LISTENERS->LISTENER;

...

}

 

Am 30.12.21 um 23:22 schrieb Richard Bartholomew:

Hi,

 

I am using Icecast 2.4.4 and can access the list of clients with
<domain.com>:port/admin/listclients?mount=<stream> and supplying the
username and password.

 

However, I would like to be able to access this page programmatically using
either python or php so that I can automate some tasks but can't find a way
of providing the username and password.

 

Is there a way, please, of being able to do this so that the login page can
be circumvented?

 

Thanks for any help.

 

Regards

Richard Bartholomew

 

 





_______________________________________________
Icecast mailing list
Icecast at xiph.org <mailto: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/20211231/08df0dfb/attachment.htm>