From ross at stationplaylist.com  Thu Aug  1 02:01:11 2019
From: ross at stationplaylist.com (Ross Levis)
Date: Thu, 1 Aug 2019 14:01:11 +1200
Subject: [Icecast] SSL-Question
In-Reply-To: <90420393-a9be-c6a3-3a8b-7be0618b0791@ruecker.fi>
References: <20190731124934.GA11538@aporee.org>
 <0d6c2bd6-0e06-f230-e89b-b3884387230a@yandex.com>
 <20190731135632.GE11872@aporee.org>
 <dddd7d25-adad-ec53-4193-54a98e3601a3@ruecker.fi>
 <20190731144411.GE14677@aporee.org>
 <90420393-a9be-c6a3-3a8b-7be0618b0791@ruecker.fi>
Message-ID: <007f01d5480c$ff1e9760$fd5bc620$@com>

Perhaps it is a Karl Heyes feature addition, but I can access my Icecast KH server with http and https URL's on the same port.

http://s2.stationplaylist.com:9000

https://s2.stationplaylist.com:9000

Ross.

-----Original Message-----
From: Icecast [mailto:icecast-bounces at xiph.org] On Behalf Of Thomas B. R?cker
Sent: Thursday, 1 August 2019 4:20 a.m.
To: icecast at xiph.org
Subject: Re: [Icecast] SSL-Question


On 7/31/19 2:44 PM, unosonic wrote:
> Thomas B. R?cker:
>> After all, Icecast is just another web server.
>>
>> Please note the absence of 8000 and 8443. Neither are officially 
>> specified for WWW type HTTP(S). They are commonly used as such, but 
>> 80 and 443 are *much* better choices and should be preferred.
> makes sense, but if my webserver needs to serve http/s from the same 
> IP, that would not work. Unless I want to use Icecast as a nginx or 
> apache replacement ;)


You *can* run it on any port. 80/443 is clearly preferred and servers or IP addresses, especially IPv6, are cheap.

If I'd have to run a production environment, I wouldn't spend a second considering that matter and spin up a second machine or IP address.


TBR

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




From mperez at flumotion.com  Thu Aug  1 08:45:48 2019
From: mperez at flumotion.com (=?UTF-8?Q?Marti=C3=B1o_Perez?=)
Date: Thu, 1 Aug 2019 10:45:48 +0200
Subject: [Icecast] mount points down in relay after a network problem
Message-ID: <CAFP0tpeO=hawSq751GKZmxaPFXGutX-tf+_RDbn_rP9T9zDV-Q@mail.gmail.com>

Hello.

I have a problem in a master-relay scenario.

Sometimes, when a stream is down in master server and after a while the
stream is fine again (e.g. after a network problem), relay/s server can't
get the stream again, so I have to restart icecast in relay server to make
it work:

1- An incoming stream is stopped in icecast master
2 - The stream is up again in icecast master
3 - Relay server has the mount point up but is not possible to play
(timeout error when playing)
4 - When source-timeout is reached in icecast relay, relay server
does source_shutdown in each failed mount points. Then when I request a
mount point it gives a 404 error and I have to restart the service to make
it work

Relay server has the following config:
<master-update-interval>15</master-update-interval>
So each 15 seconds the relay server goes to check the stream in the master
server

Master Server has the following config:
<source-timeout>180</source-timeout>
So it has to be 3 minutes without stream to delete the mount point.

Why the relay server does not respond after the network failure and before
the source-timeout?
Why the relay server can't find the mount points after the source-timeout?

Are there any way to force the relay server to check the mount points in
master server to avoid a restart?

This is the master config:
<icecast>
    <limits>
        <clients>5000</clients>
        <sources>1000</sources>
        <threadpool>4</threadpool>
        <queue-size>524288</queue-size>
        <client-timeout>60</client-timeout>
        <header-timeout>30</header-timeout>
        <source-timeout>20</source-timeout>
             <burst-on-connect>0</burst-on-connect>
        <burst-size>0</burst-size>
    </limits>

    <authentication>
        <source-password>1234</source-password>
        <relay-password>1234</relay-password>
        <admin-user>1234</admin-user>
        <admin-password>1234</admin-password>
    </authentication>

    <hostname>icecast-master</hostname>

    <listen-socket>
        <port>8000</port>
    </listen-socket>
        <http-headers>
        <header name="Access-Control-Allow-Origin" value="*" />
    </http-headers>

     <relay>
        <server>127.0.0.1</server>
        <port>8000</port>
        <mount>/test1</mount>
        <local-mount>/test1.mp3</local-mount>
    </relay>
<relay>
        <server>127.0.0.1</server>
        <port>8000</port>
        <mount>/test2</mount>
        <local-mount>/test2.mp3</local-mount>
    </relay>


    <paths>
        <basedir>/usr/share/icecast</basedir>
        <logdir>/var/log/icecast</logdir>
        <webroot>/usr/share/icecast/web</webroot>
        <adminroot>/usr/share/icecast/admin</adminroot>
    </paths>

    <logging>
        <accesslog>access.log</accesslog>
        <errorlog>error.log</errorlog>
        <loglevel>3</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
        <logsize>200000</logsize> <!-- Max size of a logfile -->
    </logging>

    <security>
        <chroot>0</chroot>
        <changeowner>
            <user>icecast</user>
            <group>icecast</group>
        </changeowner>
    </security>
</icecast>
##################################
And this is relay config:

<icecast>
    <limits>
        <clients>2310</clients>
        <sources>10000</sources>
        <threadpool>16</threadpool>
        <queue-size>524288</queue-size>
        <client-timeout>30</client-timeout>
        <header-timeout>15</header-timeout>
        <source-timeout>600</source-timeout>
        <burst-on-connect>1</burst-on-connect>
        <burst-size>65536</burst-size>
    </limits>

    <authentication>
        <source-password>1234</source-password>
        <relay-password>1234</relay-password>
        <admin-user>1234</admin-user>
        <admin-password>1234</admin-password>
    </authentication>

    <hostname>192.168.1.5</hostname>

    <listen-socket>
        <port>80</port>
        <bind-address>192.168.1.5</bind-address>
    </listen-socket>

    <listen-socket>
        <port>443</port>
        <bind-address>192.168.1.5</bind-address>
        <ssl>1</ssl>
    </listen-socket>

        <http-headers>
        <header name="Access-Control-Allow-Origin" value="*" />
    </http-headers>

    <master-server>192.168.1.4</master-server>
    <master-server-port>8000</master-server-port>
    <master-update-interval>15</master-update-interval>
    <master-password>1234</master-password>

   <mount>
       <mount-name>/test1.mp3</mount-name>
       <burst-on-connect>0</burst-on-connect>
       <burst-size>0</burst-size>
   </mount>
   <mount>
       <mount-name>/test2.mp3</mount-name>
       <burst-on-connect>0</burst-on-connect>
       <burst-size>0</burst-size>
   </mount>

    <fileserve>1</fileserve>

    <paths>
        <basedir>/usr/share/icecast</basedir>
        <logdir>/var/log/icecast</logdir>
        <webroot>/usr/share/icecast/web</webroot>
        <adminroot>/usr/share/icecast/admin</adminroot>

<ssl-certificate>/etc/pki/tls/certs/certificate_chained.crt</ssl-certificate>
    </paths>

    <logging>
        <accesslog>access.log</accesslog>
        <errorlog>error.log</errorlog>
        <loglevel>3</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
        <logsize>200000</logsize> <!-- Max size of a logfile -->
    </logging>

    <security>
        <chroot>0</chroot>
        <changeowner>
            <user>icecast</user>
            <group>icecast</group>
        </changeowner>
    </security>
</icecast>


Relay's error log file:
[2019-07-30  02:11:15] WARN slave/open_relay_connection Failed to connect
to 192.168.1.4:8000
[2019-07-30  02:11:15] WARN slave/open_relay_connection Failed to connect
to 192.168.1.4:8000
[2019-07-30  02:13:32] WARN slave/open_relay_connection Failed to connect
to 192.168.1.4:8000
[2019-07-30  02:13:56] WARN slave/open_relay_connection Failed to connect
to 192.168.1.4:8000
...
(After the network problem, the stream is up in master server but relay
server gives a timeout. Despite this, the number of listeners in log file
continue growing)
[2019-07-30  02:20:32] INFO source/source_main listener count on /test1.mp3
now 787
[2019-07-30  02:20:34] INFO source/source_main listener count on /test1.mp3
now 788
[2019-07-30  02:20:34] INFO source/source_main listener count on /test1.mp3
now 789
[2019-07-30  02:20:35] INFO source/source_main listener count on /test1.mp3
now 790
[2019-07-30  02:20:35] INFO source/source_main listener count on /test1.mp3
now 791
[2019-07-30  02:20:36] INFO source/source_main listener count on /test1.mp3
now 792
[2019-07-30  02:20:36] INFO source/source_main listener count on /test1.mp3
now 793
[2019-07-30  02:20:37] INFO source/source_main listener count on /test1.mp3
now 794
[2019-07-30  02:20:38] INFO source/source_main listener count on /test1.mp3
now 796
[2019-07-30  02:20:39] INFO source/source_main listener count on /test1.mp3
now 797
...
(the source-timeout is applied and down mount points are cleared. It starts
to give a 404 error)
[2019-07-30  02:20:39] INFO source/source_shutdown Source from 192.168.1.4
at "/test1.mp3" exiting
[2019-07-30  02:20:39] INFO source/source_clear_source 796 active listeners
on /test1.mp3 released
[2019-07-30  02:20:39] INFO fserve/fserve_client_create checking for file
/test1.mp3 (/usr/share/icecast/web/test1.mp3)
[2019-07-30  02:20:39] WARN fserve/fserve_client_create req for file
"/usr/share/icecast/web/test1.mp3" No such file or directory
[2019-07-30  02:20:39] INFO fserve/fserve_client_create checking for file
/test1.mp3 (/usr/share/icecast/web/test1.mp3)
[2019-07-30  02:20:39] WARN fserve/fserve_client_create req for file
"/usr/share/icecast/web/test1.mp3" No such file or directory
[2019-07-30  02:20:39] INFO fserve/fserve_client_create checking for file
/test1.mp3 (/usr/share/icecast/web/test1.mp3)
[2019-07-30  02:20:39] WARN fserve/fserve_client_create req for file
"/usr/share/icecast/web/test1.mp3" No such file or directory
[2019-07-30  02:20:39] INFO fserve/fserve_client_create checking for file
/test1.mp3 (/usr/share/icecast/web/test1.mp3)
[2019-07-30  02:20:39] WARN fserve/fserve_client_create req for file
"/usr/share/icecast/web/test1.mp3" No such file or directory
[2019-07-30  02:20:39] INFO fserve/fserve_client_create checking for file
/test1.mp3 (/usr/share/icecast/web/test1.mp3)
...
(The service is restarted)
[2019-07-30  02:45:26] INFO source/source_main listener count on /test1.mp3
now 0
[2019-07-30  02:45:39] INFO source/source_main listener count on /test1.mp3
now 1
[2019-07-30  02:45:54] INFO source/source_main listener count on /test1.mp3
now 2
[2019-07-30  02:46:18] INFO source/source_main listener count on /test1.mp3
now 3
[2019-07-30  02:46:19] INFO source/source_main listener count on /test1.mp3
now 4
...


Kind regards.
Martinho P?rez.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20190801/637d864d/attachment.htm>

From support at flumotion.com  Thu Aug  1 08:43:31 2019
From: support at flumotion.com (Flumotion Support)
Date: Thu, 1 Aug 2019 10:43:31 +0200
Subject: [Icecast] mount points down in relay after a network problem
Message-ID: <CAFP0tpfV+dFJdqqdiGqB1XeHuw0xMrGPbq0sOGia8MDMHCtP_w@mail.gmail.com>

Hello.

I have a problem in a master-relay scenario.

Sometimes, when a stream is down in master server and after a while the
stream is fine again (e.g. after a network problem), relay/s server can't
get the stream again, so I have to restart icecast in relay server to make
it work:

1- An incoming stream is stopped in icecast master
2 - The stream is up again in icecast master
3 - Relay server has the mount point up but is not possible to play
(timeout error when playing)
4 - When source-timeout is reached in icecast relay, relay server
does source_shutdown in each failed mount points. Then when I request a
mount point it gives a 404 error and I have to restart the service to make
it work

Relay server has the following config:
<master-update-interval>15</master-update-interval>
So each 15 seconds the relay server goes to check the stream in the master
server

Master Server has the following config:
<source-timeout>180</source-timeout>
So it has to be 3 minutes without stream to delete the mount point.

Why the relay server does not respond after the network failure and before
the source-timeout?
Why the relay server can't find the mount points after the source-timeout?

Are there any way to force the relay server to check the mount points in
master server to avoid a restart?

This is the master config:
<icecast>
    <limits>
        <clients>5000</clients>
        <sources>1000</sources>
        <threadpool>4</threadpool>
        <queue-size>524288</queue-size>
        <client-timeout>60</client-timeout>
        <header-timeout>30</header-timeout>
        <source-timeout>20</source-timeout>
             <burst-on-connect>0</burst-on-connect>
        <burst-size>0</burst-size>
    </limits>

    <authentication>
        <source-password>1234</source-password>
        <relay-password>1234</relay-password>
        <admin-user>1234</admin-user>
        <admin-password>1234</admin-password>
    </authentication>

    <hostname>icecast-master</hostname>

    <listen-socket>
        <port>8000</port>
    </listen-socket>
        <http-headers>
        <header name="Access-Control-Allow-Origin" value="*" />
    </http-headers>

     <relay>
        <server>127.0.0.1</server>
        <port>8000</port>
        <mount>/test1</mount>
        <local-mount>/test1.mp3</local-mount>
    </relay>
<relay>
        <server>127.0.0.1</server>
        <port>8000</port>
        <mount>/test2</mount>
        <local-mount>/test2.mp3</local-mount>
    </relay>


    <paths>
        <basedir>/usr/share/icecast</basedir>
        <logdir>/var/log/icecast</logdir>
        <webroot>/usr/share/icecast/web</webroot>
        <adminroot>/usr/share/icecast/admin</adminroot>
    </paths>

    <logging>
        <accesslog>access.log</accesslog>
        <errorlog>error.log</errorlog>
        <loglevel>3</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
        <logsize>200000</logsize> <!-- Max size of a logfile -->
    </logging>

    <security>
        <chroot>0</chroot>
        <changeowner>
            <user>icecast</user>
            <group>icecast</group>
        </changeowner>
    </security>
</icecast>
##################################
And this is relay config:

<icecast>
    <limits>
        <clients>2310</clients>
        <sources>10000</sources>
        <threadpool>16</threadpool>
        <queue-size>524288</queue-size>
        <client-timeout>30</client-timeout>
        <header-timeout>15</header-timeout>
        <source-timeout>600</source-timeout>
        <burst-on-connect>1</burst-on-connect>
        <burst-size>65536</burst-size>
    </limits>

    <authentication>
        <source-password>1234</source-password>
        <relay-password>1234</relay-password>
        <admin-user>1234</admin-user>
        <admin-password>1234</admin-password>
    </authentication>

    <hostname>192.168.1.5</hostname>

    <listen-socket>
        <port>80</port>
        <bind-address>192.168.1.5</bind-address>
    </listen-socket>

    <listen-socket>
        <port>443</port>
        <bind-address>192.168.1.5</bind-address>
        <ssl>1</ssl>
    </listen-socket>

        <http-headers>
        <header name="Access-Control-Allow-Origin" value="*" />
    </http-headers>

    <master-server>192.168.1.4</master-server>
    <master-server-port>8000</master-server-port>
    <master-update-interval>15</master-update-interval>
    <master-password>1234</master-password>

   <mount>
       <mount-name>/test1.mp3</mount-name>
       <burst-on-connect>0</burst-on-connect>
       <burst-size>0</burst-size>
   </mount>
   <mount>
       <mount-name>/test2.mp3</mount-name>
       <burst-on-connect>0</burst-on-connect>
       <burst-size>0</burst-size>
   </mount>

    <fileserve>1</fileserve>

    <paths>
        <basedir>/usr/share/icecast</basedir>
        <logdir>/var/log/icecast</logdir>
        <webroot>/usr/share/icecast/web</webroot>
        <adminroot>/usr/share/icecast/admin</adminroot>

<ssl-certificate>/etc/pki/tls/certs/certificate_chained.crt</ssl-certificate>
    </paths>

    <logging>
        <accesslog>access.log</accesslog>
        <errorlog>error.log</errorlog>
        <loglevel>3</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
        <logsize>200000</logsize> <!-- Max size of a logfile -->
    </logging>

    <security>
        <chroot>0</chroot>
        <changeowner>
            <user>icecast</user>
            <group>icecast</group>
        </changeowner>
    </security>
</icecast>


Relay's error log file:
[2019-07-30  02:11:15] WARN slave/open_relay_connection Failed to connect
to 192.168.1.4:8000
[2019-07-30  02:11:15] WARN slave/open_relay_connection Failed to connect
to 192.168.1.4:8000
[2019-07-30  02:13:32] WARN slave/open_relay_connection Failed to connect
to 192.168.1.4:8000
[2019-07-30  02:13:56] WARN slave/open_relay_connection Failed to connect
to 192.168.1.4:8000
...
(After the network problem, the stream is up in master server but relay
server gives a timeout. Despite this, the number of listeners in log file
continue growing)
[2019-07-30  02:20:32] INFO source/source_main listener count on /test1.mp3
now 787
[2019-07-30  02:20:34] INFO source/source_main listener count on /test1.mp3
now 788
[2019-07-30  02:20:34] INFO source/source_main listener count on /test1.mp3
now 789
[2019-07-30  02:20:35] INFO source/source_main listener count on /test1.mp3
now 790
[2019-07-30  02:20:35] INFO source/source_main listener count on /test1.mp3
now 791
[2019-07-30  02:20:36] INFO source/source_main listener count on /test1.mp3
now 792
[2019-07-30  02:20:36] INFO source/source_main listener count on /test1.mp3
now 793
[2019-07-30  02:20:37] INFO source/source_main listener count on /test1.mp3
now 794
[2019-07-30  02:20:38] INFO source/source_main listener count on /test1.mp3
now 796
[2019-07-30  02:20:39] INFO source/source_main listener count on /test1.mp3
now 797
...
(the source-timeout is applied and down mount points are cleared. It starts
to give a 404 error)
[2019-07-30  02:20:39] INFO source/source_shutdown Source from 192.168.1.4
at "/test1.mp3" exiting
[2019-07-30  02:20:39] INFO source/source_clear_source 796 active listeners
on /test1.mp3 released
[2019-07-30  02:20:39] INFO fserve/fserve_client_create checking for file
/test1.mp3 (/usr/share/icecast/web/test1.mp3)
[2019-07-30  02:20:39] WARN fserve/fserve_client_create req for file
"/usr/share/icecast/web/test1.mp3" No such file or directory
[2019-07-30  02:20:39] INFO fserve/fserve_client_create checking for file
/test1.mp3 (/usr/share/icecast/web/test1.mp3)
[2019-07-30  02:20:39] WARN fserve/fserve_client_create req for file
"/usr/share/icecast/web/test1.mp3" No such file or directory
[2019-07-30  02:20:39] INFO fserve/fserve_client_create checking for file
/test1.mp3 (/usr/share/icecast/web/test1.mp3)
[2019-07-30  02:20:39] WARN fserve/fserve_client_create req for file
"/usr/share/icecast/web/test1.mp3" No such file or directory
[2019-07-30  02:20:39] INFO fserve/fserve_client_create checking for file
/test1.mp3 (/usr/share/icecast/web/test1.mp3)
[2019-07-30  02:20:39] WARN fserve/fserve_client_create req for file
"/usr/share/icecast/web/test1.mp3" No such file or directory
[2019-07-30  02:20:39] INFO fserve/fserve_client_create checking for file
/test1.mp3 (/usr/share/icecast/web/test1.mp3)
...
(The service is restarted)
[2019-07-30  02:45:26] INFO source/source_main listener count on /test1.mp3
now 0
[2019-07-30  02:45:39] INFO source/source_main listener count on /test1.mp3
now 1
[2019-07-30  02:45:54] INFO source/source_main listener count on /test1.mp3
now 2
[2019-07-30  02:46:18] INFO source/source_main listener count on /test1.mp3
now 3
[2019-07-30  02:46:19] INFO source/source_main listener count on /test1.mp3
now 4
...


Kind regards.
Marti?o P?rez.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20190801/2c3c772f/attachment.htm>

From martinho.pgz at gmail.com  Thu Aug  1 08:54:39 2019
From: martinho.pgz at gmail.com (martinho pgz)
Date: Thu, 1 Aug 2019 10:54:39 +0200
Subject: [Icecast] mount points down in relay after a network problem
Message-ID: <CAHTed9hcwQeYLRTLJbt++UfwbNVGSE+OLe5T-Ko3408vke=asA@mail.gmail.com>

Hello.

I have a problem in a master-relay scenario.

Sometimes, when a stream is down in master server and after a while the
stream is fine again (e.g. after a network problem), relay/s server can't
get the stream again, so I have to restart icecast in relay server to make
it work:

1- An incoming stream is stopped in icecast master
2 - The stream is up again in icecast master
3 - Relay server has the mount point up but is not possible to play
(timeout error when playing)
4 - When source-timeout is reached in icecast relay, relay server
does source_shutdown in each failed mount points. Then when I request a
mount point it gives a 404 error and I have to restart the service to make
it work

Relay server has the following config:
<master-update-interval>15</master-update-interval>
So each 15 seconds the relay server goes to check the stream in the master
server

Master Server has the following config:
<source-timeout>180</source-timeout>
So it has to be 3 minutes without stream to delete the mount point.

Why the relay server does not respond after the network failure and before
the source-timeout?
Why the relay server can't find the mount points after the source-timeout?

Are there any way to force the relay server to check the mount points in
master server to avoid a restart?

This is the master config:
<icecast>
    <limits>
        <clients>5000</clients>
        <sources>1000</sources>
        <threadpool>4</threadpool>
        <queue-size>524288</queue-size>
        <client-timeout>60</client-timeout>
        <header-timeout>30</header-timeout>
        <source-timeout>20</source-timeout>
             <burst-on-connect>0</burst-on-connect>
        <burst-size>0</burst-size>
    </limits>

    <authentication>
        <source-password>1234</source-password>
        <relay-password>1234</relay-password>
        <admin-user>1234</admin-user>
        <admin-password>1234</admin-password>
    </authentication>

    <hostname>icecast-master</hostname>

    <listen-socket>
        <port>8000</port>
    </listen-socket>
        <http-headers>
        <header name="Access-Control-Allow-Origin" value="*" />
    </http-headers>

     <relay>
        <server>127.0.0.1</server>
        <port>8000</port>
        <mount>/test1</mount>
        <local-mount>/test1.mp3</local-mount>
    </relay>
<relay>
        <server>127.0.0.1</server>
        <port>8000</port>
        <mount>/test2</mount>
        <local-mount>/test2.mp3</local-mount>
    </relay>


    <paths>
        <basedir>/usr/share/icecast</basedir>
        <logdir>/var/log/icecast</logdir>
        <webroot>/usr/share/icecast/web</webroot>
        <adminroot>/usr/share/icecast/admin</adminroot>
    </paths>

    <logging>
        <accesslog>access.log</accesslog>
        <errorlog>error.log</errorlog>
        <loglevel>3</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
        <logsize>200000</logsize> <!-- Max size of a logfile -->
    </logging>

    <security>
        <chroot>0</chroot>
        <changeowner>
            <user>icecast</user>
            <group>icecast</group>
        </changeowner>
    </security>
</icecast>
##################################
And this is relay config:

<icecast>
    <limits>
        <clients>2310</clients>
        <sources>10000</sources>
        <threadpool>16</threadpool>
        <queue-size>524288</queue-size>
        <client-timeout>30</client-timeout>
        <header-timeout>15</header-timeout>
        <source-timeout>600</source-timeout>
        <burst-on-connect>1</burst-on-connect>
        <burst-size>65536</burst-size>
    </limits>

    <authentication>
        <source-password>1234</source-password>
        <relay-password>1234</relay-password>
        <admin-user>1234</admin-user>
        <admin-password>1234</admin-password>
    </authentication>

    <hostname>192.168.1.5</hostname>

    <listen-socket>
        <port>80</port>
        <bind-address>192.168.1.5</bind-address>
    </listen-socket>

    <listen-socket>
        <port>443</port>
        <bind-address>192.168.1.5</bind-address>
        <ssl>1</ssl>
    </listen-socket>

        <http-headers>
        <header name="Access-Control-Allow-Origin" value="*" />
    </http-headers>

    <master-server>192.168.1.4</master-server>
    <master-server-port>8000</master-server-port>
    <master-update-interval>15</master-update-interval>
    <master-password>1234</master-password>

   <mount>
       <mount-name>/test1.mp3</mount-name>
       <burst-on-connect>0</burst-on-connect>
       <burst-size>0</burst-size>
   </mount>
   <mount>
       <mount-name>/test2.mp3</mount-name>
       <burst-on-connect>0</burst-on-connect>
       <burst-size>0</burst-size>
   </mount>

    <fileserve>1</fileserve>

    <paths>
        <basedir>/usr/share/icecast</basedir>
        <logdir>/var/log/icecast</logdir>
        <webroot>/usr/share/icecast/web</webroot>
        <adminroot>/usr/share/icecast/admin</adminroot>

<ssl-certificate>/etc/pki/tls/certs/certificate_chained.crt</ssl-certificate>
    </paths>

    <logging>
        <accesslog>access.log</accesslog>
        <errorlog>error.log</errorlog>
        <loglevel>3</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
        <logsize>200000</logsize> <!-- Max size of a logfile -->
    </logging>

    <security>
        <chroot>0</chroot>
        <changeowner>
            <user>icecast</user>
            <group>icecast</group>
        </changeowner>
    </security>
</icecast>


Relay's error log file:
[2019-07-30  02:11:15] WARN slave/open_relay_connection Failed to connect
to 192.168.1.4:8000
[2019-07-30  02:11:15] WARN slave/open_relay_connection Failed to connect
to 192.168.1.4:8000
[2019-07-30  02:13:32] WARN slave/open_relay_connection Failed to connect
to 192.168.1.4:8000
[2019-07-30  02:13:56] WARN slave/open_relay_connection Failed to connect
to 192.168.1.4:8000
...
(After the network problem, the stream is up in master server but relay
server gives a timeout. Despite this, the number of listeners in log file
continue growing)
[2019-07-30  02:20:32] INFO source/source_main listener count on /test1.mp3
now 787
[2019-07-30  02:20:34] INFO source/source_main listener count on /test1.mp3
now 788
[2019-07-30  02:20:34] INFO source/source_main listener count on /test1.mp3
now 789
[2019-07-30  02:20:35] INFO source/source_main listener count on /test1.mp3
now 790
[2019-07-30  02:20:35] INFO source/source_main listener count on /test1.mp3
now 791
[2019-07-30  02:20:36] INFO source/source_main listener count on /test1.mp3
now 792
[2019-07-30  02:20:36] INFO source/source_main listener count on /test1.mp3
now 793
[2019-07-30  02:20:37] INFO source/source_main listener count on /test1.mp3
now 794
[2019-07-30  02:20:38] INFO source/source_main listener count on /test1.mp3
now 796
[2019-07-30  02:20:39] INFO source/source_main listener count on /test1.mp3
now 797
...
(the source-timeout is applied and down mount points are cleared. It starts
to give a 404 error)
[2019-07-30  02:20:39] INFO source/source_shutdown Source from 192.168.1.4
at "/test1.mp3" exiting
[2019-07-30  02:20:39] INFO source/source_clear_source 796 active listeners
on /test1.mp3 released
[2019-07-30  02:20:39] INFO fserve/fserve_client_create checking for file
/test1.mp3 (/usr/share/icecast/web/test1.mp3)
[2019-07-30  02:20:39] WARN fserve/fserve_client_create req for file
"/usr/share/icecast/web/test1.mp3" No such file or directory
[2019-07-30  02:20:39] INFO fserve/fserve_client_create checking for file
/test1.mp3 (/usr/share/icecast/web/test1.mp3)
[2019-07-30  02:20:39] WARN fserve/fserve_client_create req for file
"/usr/share/icecast/web/test1.mp3" No such file or directory
[2019-07-30  02:20:39] INFO fserve/fserve_client_create checking for file
/test1.mp3 (/usr/share/icecast/web/test1.mp3)
[2019-07-30  02:20:39] WARN fserve/fserve_client_create req for file
"/usr/share/icecast/web/test1.mp3" No such file or directory
[2019-07-30  02:20:39] INFO fserve/fserve_client_create checking for file
/test1.mp3 (/usr/share/icecast/web/test1.mp3)
[2019-07-30  02:20:39] WARN fserve/fserve_client_create req for file
"/usr/share/icecast/web/test1.mp3" No such file or directory
[2019-07-30  02:20:39] INFO fserve/fserve_client_create checking for file
/test1.mp3 (/usr/share/icecast/web/test1.mp3)
...
(The service is restarted)
[2019-07-30  02:45:26] INFO source/source_main listener count on /test1.mp3
now 0
[2019-07-30  02:45:39] INFO source/source_main listener count on /test1.mp3
now 1
[2019-07-30  02:45:54] INFO source/source_main listener count on /test1.mp3
now 2
[2019-07-30  02:46:18] INFO source/source_main listener count on /test1.mp3
now 3
[2019-07-30  02:46:19] INFO source/source_main listener count on /test1.mp3
now 4
...


Kind regards.
Martinho P?rez.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20190801/fea5c7f5/attachment.htm>

From webmaster at berean-biblechurch.org  Fri Aug  2 01:23:21 2019
From: webmaster at berean-biblechurch.org (webmaster at berean-biblechurch.org)
Date: Thu, 01 Aug 2019 20:23:21 -0500
Subject: [Icecast] SSL-Question
In-Reply-To: <20190731144411.GE14677@aporee.org>
References: <20190731124934.GA11538@aporee.org>
 <0d6c2bd6-0e06-f230-e89b-b3884387230a@yandex.com>
 <20190731135632.GE11872@aporee.org>
 <dddd7d25-adad-ec53-4193-54a98e3601a3@ruecker.fi>
 <20190731144411.GE14677@aporee.org>
Message-ID: <1962600fa9d0520078e816e3f8011698@berean-biblechurch.org>

On 2019-07-31 09:44, unosonic wrote:
> Thomas B. R?cker:
>> After all, Icecast is just another web server.
>> 
>> Please note the absence of 8000 and 8443. Neither are officially
>> specified for WWW type HTTP(S). They are commonly used as such, but 80
>> and 443 are *much* better choices and should be preferred.
> 
> makes sense, but if my webserver needs to serve http/s from the same 
> IP,
> that would not work. Unless I want to use Icecast as a nginx or apache
> replacement ;)

Uno, could you create a sub-domain, like radio.yoursite.com, and have it 
point to the Icecast server?


From alvin.eisma324 at gmail.com  Mon Aug  5 05:44:49 2019
From: alvin.eisma324 at gmail.com (Alvin Eisma)
Date: Mon, 5 Aug 2019 09:44:49 +0400
Subject: [Icecast] need help on script
Message-ID: <CAPyCgUPc7ZdZJbrrWt71Sp8eGQdvmf4RwHj+igG_TfGPpwVTxA@mail.gmail.com>

Hi! good day I am Alvin it is my first time to configure a live stream
using icecast need some help connecting or configuring the icecast script.
I am using a Z/IPStream R/1 as source audio below is the script I am using.
My problem is I can see my stream in your directory but it does not count
how many listener is connected

<icecast>
    <!-- location and admin are two arbitrary strings that are e.g. visible
         on the server info page of the icecast web interface
         (server_version.xsl). -->
    <location>Ras Al Khaimah</location>
    <admin>https://www.facebook.com/rak1035fm/</admin>

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

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

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

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

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

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


    <!-- Uncomment this if you want directory listings -->

    <directory>
        <yp-url-timeout>15</yp-url-timeout>
        <yp-url>http://dir.xiph.org/cgi-bin/yp-cgi</yp-url>
    </directory>


    <!-- You may have multiple <listener> elements -->
   <!--
    <listen-socket>
        <port>8000</port>
        <bind-address>192.168.11.16</bind-address>
        <shoutcast-mount>/mystream</shoutcast-mount>
    </listen-socket>
    -->
    <!--
    <listen-socket>
        <port>8080</port>
    </listen-socket>
    -->
    <!--
    <listen-socket>
        <port>8443</port>
        <ssl>1</ssl>
    </listen-socket>
    -->


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

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


    <!-- Relaying
         You don't need this if you only have one server.
         Please refer to the config for a detailed explanation.
    -->
<!--
    <master-server>radio1.dyndns.org</master-server>
    <master-server-port>8000</master-server-port>
    <master-update-interval>120</master-update-interval>
    <master-password>streampwd</master-password>
-->
    <!-- setting this makes all relays on-demand unless overridden, this is
         useful for master relays which do not have <relay> definitions
here.
         The default is 0 -->

    <relays-on-demand>0</relays-on-demand>


    <relay>
        <server>radio1.dyndns.org</server>
        <port>8000</port>
        <mount>/mystream</mount>
        <local-mount>/mystream</local-mount>
        <on-demand>0</on-demand>

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


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

    <!-- Default settings for all mounts that don't have a specific <mount
type="normal">.
    -->

    <mount type="default">
        <public>1</public>
        <intro>/server-wide-intro.ogg</intro>
        <max-listener-duration>3600</max-listener-duration>
        <authentication type="url">
                <option name="mount_add" value="
radio1.dyndns.org:8000/mystream"/>
        </authentication>
        <http-headers>
                <header name="foo" value="bar" />
        </http-headers>

    </mount>


    <!-- Normal mounts -->
    <!--
    <mount type="normal">
        <mount-name>radio1.dyndns.org:8000/mystream</mount-name>

        <username>source</username>
        <password>streampwd</password>

        <max-listeners>1</max-listeners>
        <dump-file>/tmp/dump-example1.ogg</dump-file>
        <burst-size>65536</burst-size>
        <fallback-mount>/example2.ogg</fallback-mount>
        <fallback-override>1</fallback-override>
        <fallback-when-full>1</fallback-when-full>
        <intro>/example_intro.ogg</intro>
        <hidden>1</hidden>
        <public>1</public>

        <authentication type="htpasswd">
                <option name="filename" value="myauth"/>
                <option name="allow_duplicate_users" value="0"/>
        </authentication>

        <http-headers>
                <header name="Access-Control-Allow-Origin" value="
http://webplayer.example.org" />
                <header name="baz" value="quux" />
        </http-headers>
    </mount>
    -->


    <mount type="normal">
        <mount-name>/mystream</mount-name>
<stream-name>RAKFM 1035 LIVE</stream-name>
<stream-description>RAKFM Live Stream</stream-description>
<genre>Arabic Music Live</genre>

<!--
        <authentication type="url">
            <option name="mount_add"       value="
http://myauthserver.net/notify_mount.php"/>
            <option name="mount_remove"    value="
http://myauthserver.net/notify_mount.php"/>
            <option name="listener_add"    value="
http://myauthserver.net/notify_listener.php"/>
            <option name="listener_remove" value="
http://myauthserver.net/notify_listener.php"/>
            <option name="headers"         value="x-pragma,x-token"/>
            <option name="header_prefix"   value="ClientHeader."/>
        </authentication>
-->
    </mount>

<source mount="/mystream">

<listener_peak>1</listener_peak>
<listeners>1</listeners>
<max_listeners>unlimited</max_listeners>
<public>1</public>
<quality>10.0</quality>
<samplerate>44100</samplerate>
<server_description>RAKFM 1035</server_description>
<server_name>RAKFM Live Stream</server_name>
<slow_listeners>0</slow_listeners>
<source_ip>192.168.11.16</source_ip>

</source>

    <fileserve>1</fileserve>

    <paths>
        <logdir>./log</logdir>
        <webroot>./web</webroot>
        <adminroot>./admin</adminroot>

        <!-- Aliases: treat requests for 'source' path as being for 'dest'
path
             May be made specific to a port or bound address using the
"port"
             and "bind-address" attributes.
          -->
        <!--
        <alias source="/foo" destination="/bar"/>
        -->
        <!-- Aliases: can also be used for simple redirections as well,
             this example will redirect all requests for http://server:port/
to
             the status page
        -->
        <alias source="/" destination="/status.xsl"/>
        <!-- The certificate file needs to contain both public and private
part.
             Both should be PEM encoded.
        <ssl-certificate>./icecast.pem</ssl-certificate>
        -->
    </paths>

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


below is a screenshot of the equipment Z/IPStream R/1
[image: image.png]

port 8000 is open and bond to the equipment IP can you check my script what
I am missing

[image: image.png]

Thanks and regards,

Alvin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20190805/0b4db85f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 79986 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20190805/0b4db85f/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 75514 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20190805/0b4db85f/attachment-0001.png>

From mvandop at xs4all.nl  Tue Aug 13 07:25:41 2019
From: mvandop at xs4all.nl (Michel van Dop)
Date: Tue, 13 Aug 2019 09:25:41 +0200
Subject: [Icecast] Meta Data for opus and FLAC do not work
Message-ID: <a3e178a2268288c2a46709e434d0b552@xs4all.nl>

Hi, 

I try to find out how to update the meta data on a flac or opus stream.

Look like its not support this formats. And update interface do not
work. 

Is there a solution to make this work?  

Best regards, 

Michel

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

From phschafft at de.loewenfelsen.net  Tue Aug 13 08:41:08 2019
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Tue, 13 Aug 2019 08:41:08 +0000
Subject: [Icecast] Meta Data for opus and FLAC do not work
In-Reply-To: <a3e178a2268288c2a46709e434d0b552@xs4all.nl>
References: <a3e178a2268288c2a46709e434d0b552@xs4all.nl>
Message-ID: <1565685668.2367.110.camel@de.loewenfelsen.net>

Good morning,

On Tue, 2019-08-13 at 09:25 +0200, Michel van Dop wrote:
> Hi, 
> 
> I try to find out how to update the meta data on a flac or opus stream.

Metadata is the domain of the encoder.


> Look like its not support this formats.


Opus metadata is fully supported. For FLAC metadata may not be displayed
on the status page but is still passed to the listener.


> And update interface do not work. 

That is *ONLY* for ICY (read: MP3 and AAC) streams as MP3 (and AAC) do
not support metadata.

However for every non-legacy formats such as all Ogg-based, all
Matroska-based, and FLAC metadata is supported by the format itself.
Icecast will happily relay any metadata updates send by the encoder.



> Is there a solution to make this work?  

Yes. Set the metadata in your encoder. See it's documentation on how to
do that.


With best regards,

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

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

From pm at nowster.me.uk  Wed Aug 14 17:10:55 2019
From: pm at nowster.me.uk (Paul Martin)
Date: Wed, 14 Aug 2019 18:10:55 +0100
Subject: [Icecast] Meta Data for opus and FLAC do not work
In-Reply-To: <a3e178a2268288c2a46709e434d0b552@xs4all.nl>
References: <a3e178a2268288c2a46709e434d0b552@xs4all.nl>
Message-ID: <20190814171055.GA10540@thinkpad.nowster.org.uk>

On Tue, Aug 13, 2019 at 09:25:41AM +0200, Michel van Dop wrote:
> I try to find out how to update the meta data on a flac or opus stream.

To expand on the other response.  If there is metadata in the FLAC or
Opus (Ogg) stream, Icecast will not modify it.

> Look like its not support this formats. And update interface do not
> work. 

Icecast's update interface is only implemented for MP3, AAC and
possibly Vorbis streams, as metadata updates for MP3 and AAC are not
possible except as out-of-band ICY updates.

(Yes, it's annoying that there is this inconsistency.)

In addition, many clients are not able to accept metadata updates as
part of the Ogg (FLAC, Vorbis, Opus) stream, expecting ICY metadata
only.

Also, some buggy clients consider a change of metadata in an Ogg
stream (which is usually accompanied by a change in stream serial
number) as being the end of streaming, and will stop playback on a
metadata change.

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


From mvandop at xs4all.nl  Tue Aug 20 08:55:09 2019
From: mvandop at xs4all.nl (Michel van Dop)
Date: Tue, 20 Aug 2019 10:55:09 +0200
Subject: [Icecast] Meta Data for opus and FLAC do not work
In-Reply-To: <20190814171055.GA10540@thinkpad.nowster.org.uk>
References: <a3e178a2268288c2a46709e434d0b552@xs4all.nl>
 <20190814171055.GA10540@thinkpad.nowster.org.uk>
Message-ID: <cd5a120951869c6b695f1a08fe061396@xs4all.nl>

Hi Paul Martin, 

Thank you for the information. I send it to the developer of Playout
software of ProppFrexx on air. 

Best regards, 

Michel 

Paul Martin schreef op 2019-08-14 19:10:

> On Tue, Aug 13, 2019 at 09:25:41AM +0200, Michel van Dop wrote: 
> 
>> I try to find out how to update the meta data on a flac or opus stream.
> 
> To expand on the other response.  If there is metadata in the FLAC or
> Opus (Ogg) stream, Icecast will not modify it.
> 
>> Look like its not support this formats. And update interface do not
>> work.
> 
> Icecast's update interface is only implemented for MP3, AAC and
> possibly Vorbis streams, as metadata updates for MP3 and AAC are not
> possible except as out-of-band ICY updates.
> 
> (Yes, it's annoying that there is this inconsistency.)
> 
> In addition, many clients are not able to accept metadata updates as
> part of the Ogg (FLAC, Vorbis, Opus) stream, expecting ICY metadata
> only.
> 
> Also, some buggy clients consider a change of metadata in an Ogg
> stream (which is usually accompanied by a change in stream serial
> number) as being the end of streaming, and will stop playback on a
> metadata change.

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

From subscription at nextdial.com.br  Fri Aug 23 11:31:12 2019
From: subscription at nextdial.com.br (subscription at nextdial.com.br)
Date: Fri, 23 Aug 2019 08:31:12 -0300
Subject: [Icecast] Release of libshout 2.4.3
In-Reply-To: <1559915835.23485.98.camel@lion.leolix.org>
References: <1559701649.23485.85.camel@lion.leolix.org>
 <1559915835.23485.98.camel@lion.leolix.org>
Message-ID: <cbd5aefa0f0646399143a8c0f1998ed4@nextdial.com.br>

Hello guys, I've been trying to talk to Philipp for days...
  
 Any one near him please tell him to contact me, enter freenode or send me 
a private messag.
  
 Sorry by the off.
  
  
 Best,
 Thiago Fernandes
  
  

----------------------------------------
 From: "Philipp Schafft" <lion at lion.leolix.org>
Sent: Friday, June 7, 2019 10:58 AM
To: icecast at xiph.org
Cc: icecast-dev at xiph.org
Subject: Re: [Icecast] Release of libshout 2.4.3   
Good afternoon, it was brought to our attention (huge thanks to the 
reporter!) that the mirroring failed and therefore the file was not 
downloadable. We fixed this this morning. With best regards, On Wed, 
2019-06-05 at 02:27 +0000, Philipp Schafft wrote: > we're happy to announce 
the release of libshout 2.4.3. The new version > includes several fixes as 
well as improvements. > [...] > > You can find our news entry at: > 
https://icecast.org/news/libshout-release-2_4_3/ > > Downloads can be found 
at: > https://icecast.org/download/#bindings -- Philipp. (Rah of PH2) 
_______________________________________________ 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/20190823/bce79f8b/attachment.htm>

From that.jack.elliott at gmail.com  Tue Aug 27 15:33:13 2019
From: that.jack.elliott at gmail.com (Jack Elliott)
Date: Tue, 27 Aug 2019 08:33:13 -0700
Subject: [Icecast] Anyone using ffmpeg as a source-client?
Message-ID: <681a66d6-79b4-121a-5b92-7e953f3ae1fe@kpov.org>

As described here in ffmpeg's documentation:

http://ffmpeg.org/ffmpeg-all.html#Icecast

-- 
That Jack Elliott
(541) 848 7021
KPOV 88.9 FM High Desert Community radio
Host, The Sunday Classics



From cdgraff at gmail.com  Tue Aug 27 17:58:47 2019
From: cdgraff at gmail.com (Alejandro)
Date: Tue, 27 Aug 2019 14:58:47 -0300
Subject: [Icecast] Anyone using ffmpeg as a source-client?
In-Reply-To: <681a66d6-79b4-121a-5b92-7e953f3ae1fe@kpov.org>
References: <681a66d6-79b4-121a-5b92-7e953f3ae1fe@kpov.org>
Message-ID: <CALJtzxAuYzUK2gHR2GXNpmMsMGaXhBqGb2hXxs28RST-QbBL9g@mail.gmail.com>

When you say as Source Client, means like listener?

i'm using for push and pull the streaming.

For push, we capture from SDR Dongle and LineIn audio card, encode and push
to Icecast server with FFMPEG.

And to play (and process, trascoding too) to multiple bitrate and others
task too.

What is your doubt?

Regards
Alejandro

El mar., 27 de ago. de 2019 a la(s) 12:33, Jack Elliott (
that.jack.elliott at gmail.com) escribi?:

> As described here in ffmpeg's documentation:
>
> http://ffmpeg.org/ffmpeg-all.html#Icecast
>
> --
> That Jack Elliott
> (541) 848 7021
> KPOV 88.9 FM High Desert Community radio
> Host, The Sunday Classics
>
> _______________________________________________
> 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/20190827/613e2e22/attachment.htm>

From webmaster at berean-biblechurch.org  Wed Aug 28 00:25:29 2019
From: webmaster at berean-biblechurch.org (webmaster at berean-biblechurch.org)
Date: Tue, 27 Aug 2019 19:25:29 -0500
Subject: [Icecast] Anyone using ffmpeg as a source-client?
In-Reply-To: <681a66d6-79b4-121a-5b92-7e953f3ae1fe@kpov.org>
References: <681a66d6-79b4-121a-5b92-7e953f3ae1fe@kpov.org>
Message-ID: <b64a96abd3fa238e988f55ce36a9ad73@berean-biblechurch.org>

Yes, I'm using it to capture the audio-in and pushing to Icecast.

On 2019-08-27 10:33, Jack Elliott wrote:
> As described here in ffmpeg's documentation:
> 
> http://ffmpeg.org/ffmpeg-all.html#Icecast


From that.jack.elliott at gmail.com  Wed Aug 28 00:38:25 2019
From: that.jack.elliott at gmail.com (That Jack Elliott)
Date: Tue, 27 Aug 2019 17:38:25 -0700
Subject: [Icecast] Anyone using ffmpeg as a source-client?
In-Reply-To: <b64a96abd3fa238e988f55ce36a9ad73@berean-biblechurch.org>
References: <681a66d6-79b4-121a-5b92-7e953f3ae1fe@kpov.org>
 <b64a96abd3fa238e988f55ce36a9ad73@berean-biblechurch.org>
Message-ID: <62869264-81b4-3f4b-2f02-dc4784fa48a7@gmail.com>

How are you capturing the audio-in?

Jack Elliott

On 8/27/2019 5:25 PM, webmaster at berean-biblechurch.org wrote:
> Yes, I'm using it to capture the audio-in and pushing to Icecast.
>
> On 2019-08-27 10:33, Jack Elliott wrote:
>> As described here in ffmpeg's documentation:
>>
>> http://ffmpeg.org/ffmpeg-all.html#Icecast


From cdgraff at gmail.com  Wed Aug 28 12:22:30 2019
From: cdgraff at gmail.com (Alejandro)
Date: Wed, 28 Aug 2019 09:22:30 -0300
Subject: [Icecast] Anyone using ffmpeg as a source-client?
In-Reply-To: <62869264-81b4-3f4b-2f02-dc4784fa48a7@gmail.com>
References: <681a66d6-79b4-121a-5b92-7e953f3ae1fe@kpov.org>
 <b64a96abd3fa238e988f55ce36a9ad73@berean-biblechurch.org>
 <62869264-81b4-3f4b-2f02-dc4784fa48a7@gmail.com>
Message-ID: <CALJtzxAZVKKMkr8e=CAKO10sH97yOOvuxmy+xUY=Q=bs-RSCfg@mail.gmail.com>

This depend on your device, but almost in my case with audioinjector card
for rpi use:

/usr/bin/arecord -q -N -M -t raw -D hw:audioinjectorpi -c 2 -r 44100 -f
S16_LE | ffmpeg -re -f s16le -ac 2 -ar 44100 -i -
$PUBLIC_LINEIN_FFMPEG_CONFIG | grep -q Error

I try the native way from ffmpeg, without success :( and move to use PIPE
to capture and deliver to ffmpeg.

El mi?., 28 de ago. de 2019 a la(s) 08:23, That Jack Elliott (
that.jack.elliott at gmail.com) escribi?:

> How are you capturing the audio-in?
>
> Jack Elliott
>
> On 8/27/2019 5:25 PM, webmaster at berean-biblechurch.org wrote:
> > Yes, I'm using it to capture the audio-in and pushing to Icecast.
> >
> > On 2019-08-27 10:33, Jack Elliott wrote:
> >> As described here in ffmpeg's documentation:
> >>
> >> http://ffmpeg.org/ffmpeg-all.html#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/20190828/b30c19f7/attachment.htm>

From sytze.visser at gmail.com  Wed Aug 28 12:30:45 2019
From: sytze.visser at gmail.com (Sytze Visser)
Date: Wed, 28 Aug 2019 14:30:45 +0200
Subject: [Icecast] Anyone using ffmpeg as a source-client?
In-Reply-To: <681a66d6-79b4-121a-5b92-7e953f3ae1fe@kpov.org>
References: <681a66d6-79b4-121a-5b92-7e953f3ae1fe@kpov.org>
Message-ID: <5d6673f5.1c69fb81.db392.aebb@mx.google.com>

Hi

Yes and it works extremely well. I take an rtmp stream and output the audio to icecast:

ffmpeg -i rtmp://localhost/live/acc-1024768 -vn -c:a libmp3lame -f mp3 icecast://username:password at icecastserver.com:8000/1024768.mp3 -hide_banner

Hope it helps

Sent from Mail for Windows 10

From: Jack Elliott
Sent: Tuesday, August 27, 2019 5:33 PM
To: icecast at xiph.org
Subject: [Icecast] Anyone using ffmpeg as a source-client?

As described here in ffmpeg's documentation:

http://ffmpeg.org/ffmpeg-all.html#Icecast

-- 
That Jack Elliott
(541) 848 7021
KPOV 88.9 FM High Desert Community radio
Host, The Sunday Classics

_______________________________________________
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/20190828/f6a7d254/attachment.htm>

From that.jack.elliott at gmail.com  Wed Aug 28 15:20:21 2019
From: that.jack.elliott at gmail.com (Jack Elliott)
Date: Wed, 28 Aug 2019 08:20:21 -0700
Subject: [Icecast] Anyone using ffmpeg as a source-client?
In-Reply-To: <CALJtzxAuYzUK2gHR2GXNpmMsMGaXhBqGb2hXxs28RST-QbBL9g@mail.gmail.com>
References: <681a66d6-79b4-121a-5b92-7e953f3ae1fe@kpov.org>
 <CALJtzxAuYzUK2gHR2GXNpmMsMGaXhBqGb2hXxs28RST-QbBL9g@mail.gmail.com>
Message-ID: <f2a73db5-927e-f7d6-95d4-d6097dfc4998@kpov.org>

I'm just wondering if ffmpeg is a reliable Icecast source-client -- a 
"pusher" to send a stream to an Icecast server and runs 24/7/365 dependably.

-- 
That Jack Elliott
(541) 848 7021
KPOV 88.9 FM High Desert Community radio
Host, The Sunday Classics

On 8/27/2019 10:58 AM, Alejandro wrote:
> When you say as Source Client, means like listener?
>
> i'm using for push and pull the streaming.
>
> For push, we capture from SDR Dongle and LineIn audio card, encode and 
> push to Icecast server with FFMPEG.
>
> And to play (and process, trascoding too) to multiple bitrate and 
> others task too.
>
> What is your doubt?
>
> Regards
> Alejandro
>
> El mar., 27 de ago. de 2019 a la(s) 12:33, Jack Elliott 
> (that.jack.elliott at gmail.com <mailto:that.jack.elliott at gmail.com>) 
> escribi?:
>
>     As described here in ffmpeg's documentation:
>
>     http://ffmpeg.org/ffmpeg-all.html#Icecast
>
>     -- 
>     That Jack Elliott
>     (541) 848 7021
>     KPOV 88.9 FM High Desert Community radio
>     Host, The Sunday Classics
>
>     _______________________________________________
>     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/20190828/9c86e8a0/attachment.htm>

From cdgraff at gmail.com  Wed Aug 28 15:55:28 2019
From: cdgraff at gmail.com (Alejandro)
Date: Wed, 28 Aug 2019 12:55:28 -0300
Subject: [Icecast] Anyone using ffmpeg as a source-client?
In-Reply-To: <f2a73db5-927e-f7d6-95d4-d6097dfc4998@kpov.org>
References: <681a66d6-79b4-121a-5b92-7e953f3ae1fe@kpov.org>
 <CALJtzxAuYzUK2gHR2GXNpmMsMGaXhBqGb2hXxs28RST-QbBL9g@mail.gmail.com>
 <f2a73db5-927e-f7d6-95d4-d6097dfc4998@kpov.org>
Message-ID: <CALJtzxAKjzKLEO=9hGxuRO1Hakf_ruY8Ho=5M4s-X9uS4=LFTw@mail.gmail.com>

Yes, it does. I run more than 50 RPI devices around the world shipping
audio to icecast 24/7

The biggest challenge was detect connection issues and fix them (restart)
as ffmpeg don't work well on that side

El El mi?, 28 ago. 2019 a las 12:20, Jack Elliott <
that.jack.elliott at gmail.com> escribi?:

> I'm just wondering if ffmpeg is a reliable Icecast source-client -- a
> "pusher" to send a stream to an Icecast server and runs 24/7/365 dependably.
>
> --
> That Jack Elliott
> (541) 848 7021
> KPOV 88.9 FM High Desert Community radio
> Host, The Sunday Classics
>
> On 8/27/2019 10:58 AM, Alejandro wrote:
>
> When you say as Source Client, means like listener?
>
> i'm using for push and pull the streaming.
>
> For push, we capture from SDR Dongle and LineIn audio card, encode and
> push to Icecast server with FFMPEG.
>
> And to play (and process, trascoding too) to multiple bitrate and others
> task too.
>
> What is your doubt?
>
> Regards
> Alejandro
>
> El mar., 27 de ago. de 2019 a la(s) 12:33, Jack Elliott (
> that.jack.elliott at gmail.com) escribi?:
>
>> As described here in ffmpeg's documentation:
>>
>> http://ffmpeg.org/ffmpeg-all.html#Icecast
>>
>> --
>> That Jack Elliott
>> (541) 848 7021
>> KPOV 88.9 FM High Desert Community radio
>> Host, The Sunday Classics
>>
>> _______________________________________________
>> 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/20190828/405d1366/attachment.htm>

From webmaster at berean-biblechurch.org  Thu Aug 29 01:43:12 2019
From: webmaster at berean-biblechurch.org (webmaster at berean-biblechurch.org)
Date: Wed, 28 Aug 2019 20:43:12 -0500
Subject: [Icecast] Anyone using ffmpeg as a source-client?
In-Reply-To: <62869264-81b4-3f4b-2f02-dc4784fa48a7@gmail.com>
References: <681a66d6-79b4-121a-5b92-7e953f3ae1fe@kpov.org>
 <b64a96abd3fa238e988f55ce36a9ad73@berean-biblechurch.org>
 <62869264-81b4-3f4b-2f02-dc4784fa48a7@gmail.com>
Message-ID: <6bb63dba06caf22a82f93c7724cc7da3@berean-biblechurch.org>

Hi Jack,
I'm on a Windows box.  FFmpeg captures the raw audio-in stream from the 
audio card (we do live broadcasts).  This is the cmd line:

c:\apps\ffmpeg\bin\ffmpeg.exe -f dshow -i audio="Line In (Realtek High 
Definition Audio)" -b:a 16k -ar 32000 -ac 1^
  -ice_name "my name of stream" -ice_description "a nice description" 
-ice_genre "Christianity" -ice_url "https://server.org/live.mp3" 
-user_agent "as you like"^
  icecast://source:IceCast.Source at localhost:8000/live.mp3


Justin

On 2019-08-27 19:38, That Jack Elliott wrote:
> How are you capturing the audio-in?
> 
> Jack Elliott
> 
> On 8/27/2019 5:25 PM, webmaster at berean-biblechurch.org wrote:
>> Yes, I'm using it to capture the audio-in and pushing to Icecast.
>> 
>> On 2019-08-27 10:33, Jack Elliott wrote:
>>> As described here in ffmpeg's documentation:
>>> 
>>> http://ffmpeg.org/ffmpeg-all.html#Icecast


From me at alexhackney.com  Thu Aug 29 03:35:33 2019
From: me at alexhackney.com (Alex Hackney)
Date: Wed, 28 Aug 2019 23:35:33 -0400
Subject: [Icecast] Anyone using ffmpeg as a source-client?
In-Reply-To: <6bb63dba06caf22a82f93c7724cc7da3@berean-biblechurch.org>
References: <681a66d6-79b4-121a-5b92-7e953f3ae1fe@kpov.org>
 <b64a96abd3fa238e988f55ce36a9ad73@berean-biblechurch.org>
 <62869264-81b4-3f4b-2f02-dc4784fa48a7@gmail.com>
 <6bb63dba06caf22a82f93c7724cc7da3@berean-biblechurch.org>
Message-ID: <CALiD=zwcHJDN6Z=23Q9Tg2dgR3oLc-2Yn4bNaR7PAQ6ZdyAFJg@mail.gmail.com>

I'm using ffmpeg for an audio over ip stl project and where I run in to
trouble is doing a stereo stream with a raspberry pi. Mono it works great
but stereo just takes too much cpu.

With that said, I'm sending audio to an icecast server in a vm over the
internet and its been solid for days, no problem.

On Wed, Aug 28, 2019 at 10:21 PM <webmaster at berean-biblechurch.org> wrote:

> Hi Jack,
> I'm on a Windows box.  FFmpeg captures the raw audio-in stream from the
> audio card (we do live broadcasts).  This is the cmd line:
>
> c:\apps\ffmpeg\bin\ffmpeg.exe -f dshow -i audio="Line In (Realtek High
> Definition Audio)" -b:a 16k -ar 32000 -ac 1^
>   -ice_name "my name of stream" -ice_description "a nice description"
> -ice_genre "Christianity" -ice_url "https://server.org/live.mp3"
> -user_agent "as you like"^
>   icecast://source:IceCast.Source at localhost:8000/live.mp3
>
>
> Justin
>
> On 2019-08-27 19:38, That Jack Elliott wrote:
> > How are you capturing the audio-in?
> >
> > Jack Elliott
> >
> > On 8/27/2019 5:25 PM, webmaster at berean-biblechurch.org wrote:
> >> Yes, I'm using it to capture the audio-in and pushing to Icecast.
> >>
> >> On 2019-08-27 10:33, Jack Elliott wrote:
> >>> As described here in ffmpeg's documentation:
> >>>
> >>> http://ffmpeg.org/ffmpeg-all.html#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/20190828/cc338c59/attachment.htm>

From faribbeiro at gmail.com  Fri Aug 30 00:14:30 2019
From: faribbeiro at gmail.com (=?UTF-8?B?RmzDoXZpbyBBbnTDtG5pbyBSaWJlaXJv?=)
Date: Thu, 29 Aug 2019 21:14:30 -0300
Subject: [Icecast] Ref. Questions about using libcurl
Message-ID: <CAEFQ5f=ghO7P0kVbqZCSvmLOtJYF+aaju1xMb_ZKVRTzuG2p7g@mail.gmail.com>

Hello,

I have already installed and active the icecast2 server. But how to use
libcurl with icecast. Already downloaded to the windows version and tried
everything, but could not. Please help me.

Thanks in advance for your time.

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