From acraigwest at gmail.com  Tue Mar  1 02:35:39 2016
From: acraigwest at gmail.com (A. Craig West)
Date: Mon, 29 Feb 2016 21:35:39 -0500
Subject: [Icecast] Metadata in xsl files
In-Reply-To: <AB16814C-2F72-4F3F-BC67-D8E0FB7A05EF@gmail.com>
References: <CAFbfRko81WTo5X7gzz_ANAMjVQb4Q=cPXzizrCKQ7bDr5VR13g@mail.gmail.com>
	<4BBE909D-49ED-4208-BB31-24B55662B256@gmail.com>
	<CAFbfRkq9+Z2JE30BeW1WKBTcXfLUW+Po14u9J3URRCJ_99JfNg@mail.gmail.com>
	<B446D62D-4E1C-4D8B-8D3B-6320804E602E@gmail.com>
	<CAFbfRkoMDmQ45PVZ6L+Z4FtU7S=_XPHh5_9Rk_M1bhO2EJm3KA@mail.gmail.com>
	<AB16814C-2F72-4F3F-BC67-D8E0FB7A05EF@gmail.com>
Message-ID: <CAFbfRkqv9QXGpF8XcRzLZ49D2yuu=2vKjjLA=pYsy6QXcpMO-A@mail.gmail.com>

The ices2 code in many ways seems more limited than the ices0 code,
particularly with metadata. There doesn't seem to be any way to include
metadata at all with icecast2 and playlists, particularly with scripts. Is
there a reason this was removed??

On Fri, Feb 26, 2016 at 3:47 PM, Marvin Scholz <epirat07 at gmail.com> wrote:

> This is not about metadata, just how to connect to the server to
> transmit the stream.
> How metadata is handled is different depending on the format, modern
> formats like Ogg
> don't need the ICY metadata "hack" to work, but MP3 does not support
> metadata at all
> that's why icy metadata is used. If you stream in a format like Ogg with
> a proper
> source client, Icecast will display metadata fine, it's just not
> possible with MP3.
>
> On 26 Feb 2016, at 18:50, A. Craig West wrote:
>
> > The default ices.conf.dist file from the source distribution contains:
> >    <!-- Header protocol to use when communicating with the server.
> >         Shoutcast servers need "icy", icecast 1.x needs "xaudiocast",
> > and
> >     icecast 2.x needs "http". -->
> >    <Protocol>http</Protocol>
> >
> > I haven't checked the code to see if this is used for anything,
> > though...
> >
> > On Fri, Feb 26, 2016 at 12:44 PM, Marvin Scholz <epirat07 at gmail.com>
> > wrote:
> >
> >> Can you show me the context where <Protocol> is used?
> >>
> >> On 26 Feb 2016, at 18:42, A. Craig West wrote:
> >>
> >>> So why does the ices.conf file have <Protocol>http</Protocol> ic it
> >>> is
> >>> going to use icy anyways?
> >>>
> >>> On Fri, Feb 26, 2016 at 2:00 AM, Marvin Scholz <epirat07 at gmail.com>
> >> wrote:
> >>>
> >>>> On 26 Feb 2016, at 7:03, A. Craig West wrote:
> >>>>
> >>>>> I have been trying to access the "artist" and "title" metadata in
> >>>>> the
> >>>>> xml
> >>>>> files as separate entities, But have found thar artist is missing,
> >>>>> and
> >>>>> title contains a combined form.
> >>>>> My source is a modified version of ices-0.4 sending mp3 streams.
> >>>>> The
> >>>>> modification is to attach artist and title metadata instead of
> >>>>> song,
> >>>>> which
> >>>>> seems tobe working, in that both the artist and title are present.
> >>>>> What
> >>>>> does shout_set_metadata do? I have tried to use wireshark to see
> >>>>> what
> >>>>> is
> >>>>> being sent to the server, but it doesn't appear to be anything
> >>>>> obvious...
> >>>>> -Craig
> >>>>
> >>>> For MP3 streaming metadata ICY is used, which is not capable of
> >>>> having
> >>>> separate Artist and Title
> >>>> metadata bust just one single combined string for metadata, as far
> >>>> as I
> >>>> know.
> >>>> So there is no way to get that information if you use MP3, sorry.
> >>>>
> >>>>> _______________________________________________
> >>>>> 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
> >> _______________________________________________
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20160229/68ca4023/attachment.htm>

From acraigwest at gmail.com  Tue Mar  1 03:44:29 2016
From: acraigwest at gmail.com (A. Craig West)
Date: Mon, 29 Feb 2016 22:44:29 -0500
Subject: [Icecast] Metadata in xsl files
In-Reply-To: <AB16814C-2F72-4F3F-BC67-D8E0FB7A05EF@gmail.com>
References: <CAFbfRko81WTo5X7gzz_ANAMjVQb4Q=cPXzizrCKQ7bDr5VR13g@mail.gmail.com>
	<4BBE909D-49ED-4208-BB31-24B55662B256@gmail.com>
	<CAFbfRkq9+Z2JE30BeW1WKBTcXfLUW+Po14u9J3URRCJ_99JfNg@mail.gmail.com>
	<B446D62D-4E1C-4D8B-8D3B-6320804E602E@gmail.com>
	<CAFbfRkoMDmQ45PVZ6L+Z4FtU7S=_XPHh5_9Rk_M1bhO2EJm3KA@mail.gmail.com>
	<AB16814C-2F72-4F3F-BC67-D8E0FB7A05EF@gmail.com>
Message-ID: <CAFbfRkowwD2Zb+s0xFWJ=-7nqz3kejxTu4DwhthQuR9FksAy=g@mail.gmail.com>

I have just been re-reading the ices0 code, and it appears that if the
protocol in the configuration is set, the complete metadata IS being sent
to the icecast server, using HTTP GET /admin/metadata. Is the server
ignoring this?

On Fri, Feb 26, 2016 at 3:47 PM, Marvin Scholz <epirat07 at gmail.com> wrote:

> This is not about metadata, just how to connect to the server to
> transmit the stream.
> How metadata is handled is different depending on the format, modern
> formats like Ogg
> don't need the ICY metadata "hack" to work, but MP3 does not support
> metadata at all
> that's why icy metadata is used. If you stream in a format like Ogg with
> a proper
> source client, Icecast will display metadata fine, it's just not
> possible with MP3.
>
> On 26 Feb 2016, at 18:50, A. Craig West wrote:
>
> > The default ices.conf.dist file from the source distribution contains:
> >    <!-- Header protocol to use when communicating with the server.
> >         Shoutcast servers need "icy", icecast 1.x needs "xaudiocast",
> > and
> >     icecast 2.x needs "http". -->
> >    <Protocol>http</Protocol>
> >
> > I haven't checked the code to see if this is used for anything,
> > though...
> >
> > On Fri, Feb 26, 2016 at 12:44 PM, Marvin Scholz <epirat07 at gmail.com>
> > wrote:
> >
> >> Can you show me the context where <Protocol> is used?
> >>
> >> On 26 Feb 2016, at 18:42, A. Craig West wrote:
> >>
> >>> So why does the ices.conf file have <Protocol>http</Protocol> ic it
> >>> is
> >>> going to use icy anyways?
> >>>
> >>> On Fri, Feb 26, 2016 at 2:00 AM, Marvin Scholz <epirat07 at gmail.com>
> >> wrote:
> >>>
> >>>> On 26 Feb 2016, at 7:03, A. Craig West wrote:
> >>>>
> >>>>> I have been trying to access the "artist" and "title" metadata in
> >>>>> the
> >>>>> xml
> >>>>> files as separate entities, But have found thar artist is missing,
> >>>>> and
> >>>>> title contains a combined form.
> >>>>> My source is a modified version of ices-0.4 sending mp3 streams.
> >>>>> The
> >>>>> modification is to attach artist and title metadata instead of
> >>>>> song,
> >>>>> which
> >>>>> seems tobe working, in that both the artist and title are present.
> >>>>> What
> >>>>> does shout_set_metadata do? I have tried to use wireshark to see
> >>>>> what
> >>>>> is
> >>>>> being sent to the server, but it doesn't appear to be anything
> >>>>> obvious...
> >>>>> -Craig
> >>>>
> >>>> For MP3 streaming metadata ICY is used, which is not capable of
> >>>> having
> >>>> separate Artist and Title
> >>>> metadata bust just one single combined string for metadata, as far
> >>>> as I
> >>>> know.
> >>>> So there is no way to get that information if you use MP3, sorry.
> >>>>
> >>>>> _______________________________________________
> >>>>> 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
> >> _______________________________________________
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20160229/72a196f3/attachment.htm>

From acraigwest at gmail.com  Tue Mar  1 04:06:07 2016
From: acraigwest at gmail.com (A. Craig West)
Date: Mon, 29 Feb 2016 23:06:07 -0500
Subject: [Icecast] Metadata in xsl files
In-Reply-To: <CAFbfRkowwD2Zb+s0xFWJ=-7nqz3kejxTu4DwhthQuR9FksAy=g@mail.gmail.com>
References: <CAFbfRko81WTo5X7gzz_ANAMjVQb4Q=cPXzizrCKQ7bDr5VR13g@mail.gmail.com>
	<4BBE909D-49ED-4208-BB31-24B55662B256@gmail.com>
	<CAFbfRkq9+Z2JE30BeW1WKBTcXfLUW+Po14u9J3URRCJ_99JfNg@mail.gmail.com>
	<B446D62D-4E1C-4D8B-8D3B-6320804E602E@gmail.com>
	<CAFbfRkoMDmQ45PVZ6L+Z4FtU7S=_XPHh5_9Rk_M1bhO2EJm3KA@mail.gmail.com>
	<AB16814C-2F72-4F3F-BC67-D8E0FB7A05EF@gmail.com>
	<CAFbfRkowwD2Zb+s0xFWJ=-7nqz3kejxTu4DwhthQuR9FksAy=g@mail.gmail.com>
Message-ID: <CAFbfRkr0zPK-J5=08BimD6iWHemKrMsF8QK=sumMPPSv0A-AFA@mail.gmail.com>

On Mon, Feb 29, 2016 at 10:44 PM, A. Craig West <acraigwest at gmail.com> wrote:
>
> I have just been re-reading the ices0 code, and it appears that if the protocol in the configuration is set, the complete metadata IS being sent to the icecast server, using HTTP GET /admin/metadata. Is the server ignoring this?

It's always fun answering your own questions. After a little more
investigation, it has become apparent that the server, for reasons of
it's own, is discarding the separate artist and title information that
it has. I suspect that is is because the outgoing mp3 stream has no
way of sending this information, but I don't need it to. I plan on
using this information on the server in xsl files.  I am working on a
patch now to generate the calls to stats_event that would be needed to
preserve this information.


From sm at noisynotes.com  Tue Mar  1 18:54:26 2016
From: sm at noisynotes.com (Steve Matzura)
Date: Tue, 01 Mar 2016 13:54:26 -0500
Subject: [Icecast] ezstream question
In-Reply-To: <02b001d16400$11c49ad0$354dd070$@acbradio.org>
References: <019401d1634a$f8ac0d90$ea0428b0$@acbradio.org>
	<alpine.DEB.2.11.1602100831000.879@portkey.home>
	<02b001d16400$11c49ad0$354dd070$@acbradio.org>
Message-ID: <g9obdbt9eli7lecnoc4vtd7baoidekm1gl@4ax.com>

Larry,

On Wed, 10 Feb 2016 12:39:23 +0000, you wrote:

>I am also exploring mp3gain to run across the entire library and see if
>getting all files to the same level will help.

It will, but there's a caveat. I've found that, with OTR programming,
especially if it's of good quality, not re-re-re-re-re-recorded off
the radio and copied a million times, the dialog is softer than the
music. This means that the music will be nice and loud, but the dialog
might not. If you can get SOX to work, I think it's your best bet.


From pm at nowster.me.uk  Wed Mar  2 19:37:29 2016
From: pm at nowster.me.uk (Paul Martin)
Date: Wed, 2 Mar 2016 19:37:29 +0000
Subject: [Icecast] ezstream question
In-Reply-To: <g9obdbt9eli7lecnoc4vtd7baoidekm1gl@4ax.com>
References: <019401d1634a$f8ac0d90$ea0428b0$@acbradio.org>
	<alpine.DEB.2.11.1602100831000.879@portkey.home>
	<02b001d16400$11c49ad0$354dd070$@acbradio.org>
	<g9obdbt9eli7lecnoc4vtd7baoidekm1gl@4ax.com>
Message-ID: <20160302193728.GA5626@thinkpad.nowster.org.uk>

On Tue, Mar 01, 2016 at 01:54:26PM -0500, Steve Matzura wrote:

> It will, but there's a caveat. I've found that, with OTR programming,
> especially if it's of good quality, not re-re-re-re-re-recorded off
> the radio and copied a million times, the dialog is softer than the
> music. This means that the music will be nice and loud, but the dialog
> might not. If you can get SOX to work, I think it's your best bet.

I've found that with ReplayGain too.

BBC used to (and may still) recommend that music peaks between 3 and 4
on their meters and speech should be about 5 and mustn't exceed 6.

BBC-style Peak Programme Meters [PPM] have simple markings of 1 to 7.

0 dBu reference level was about PPM4 and the divisions were (to a first
approximation) 4 dB apart.

>From that you can see that the BBC advice (at least) would suggest
speech be about 6 dB louder than music on the meters to have the same
perceived loudness. (You knew I'd get there in the end...)

(For the benefit of those on the other side of the Atlantic, 0 VU is
usually +4 dBu, but the response characteristic of a VU meter is
different to that of a PPM.)

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


From saulvillarin1992 at gmail.com  Thu Mar  3 10:29:04 2016
From: saulvillarin1992 at gmail.com (=?UTF-8?B?U2HDumwgVmlsbGFyw61u?=)
Date: Thu, 3 Mar 2016 11:29:04 +0100
Subject: [Icecast] Icecast2 bajo demanda / Icecast2 on demand
In-Reply-To: <56D80B1E.4070609@xiph.org>
References: <CAPBYH-vutVeH6DTdwDc-iD6SoyRS8sMwUueuw8cmNyo+Zz51oQ@mail.gmail.com>
	<56D80B1E.4070609@xiph.org>
Message-ID: <CAPBYH-uf=7+inDKKO7HAYe6EBi3KMwZTYBQEinFabWU_UcVT8A@mail.gmail.com>

2016-03-03 10:59 GMT+01:00 Xiph.org Webmaster <webmaster at xiph.org>:

> On 03/03/2016 07:59 AM, Sa?l Villar?n wrote:
> >
> > Good I wonder if you can send me information on how to mount a
> > icecast2 server on demand. Any information can be useful to me.
>
> Your questions are better directed at the Icecast users mailing list:
> http://lists.xiph.org/mailman/listinfo/icecast
>
> After signing up you can send your question to:
> icecast at xiph.org
>
>
> Best regards,
>
> Xiph.org Webmaster
>



-- 
Un saludo
Saul Villarin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20160303/9544f251/attachment.htm>

From sm at noisynotes.com  Fri Mar  4 13:13:59 2016
From: sm at noisynotes.com (Steve Matzura)
Date: Fri, 04 Mar 2016 08:13:59 -0500
Subject: [Icecast] Icecast and AAC streams
Message-ID: <o72jdbl99ghghj9ltufn03dnpcfp5e42p8@4ax.com>

All the broadcasters on the server which I support deliver their
content in MP3 format. Recently, there's been interest in supplying a
second AAC stream at half the bandwidth but with the same audio
quality (64kbps AAC versus 128kbps MP3) like TuneInRadio does for
delivering their content regardless of the source. I've thought of
using a third-party product called Stream Transcoder, but am dubious
as to whether it will do the job. Does anyone know of a better or more
efficient way to do this? I know the MP3 stream requires re-encoding
into AAC format, but am not sure of the proper tool to use to do it.

As always, thanks in advance.


From dennis at heerema.net  Fri Mar  4 13:48:41 2016
From: dennis at heerema.net (Dennis Heerema)
Date: Fri, 04 Mar 2016 14:48:41 +0100
Subject: [Icecast] Icecast and AAC streams
In-Reply-To: <o72jdbl99ghghj9ltufn03dnpcfp5e42p8@4ax.com>
References: <o72jdbl99ghghj9ltufn03dnpcfp5e42p8@4ax.com>
Message-ID: <3a134ac0-e0bf-4ae6-ba71-6615c37fc3ac@heerema.net>

Great tool to do this: liquidsoap 

Keep in mind that transcoding degrades the quality of tour stream dramaticly. You can avoid this by feeding liquidsoap or stream transcoder with a highquality or even transparant stream and trancode this to the different streaming formats you like. I used to do this by feeding a flac stream to liquidsoap and transcode this to 5 different stream formats i needed. But you might be fine if you feed your transcoder with 320 kbps AAC and transcoder this to lower formats. Maybe experiment with a high quality ogg stream, this might give you beter results due to the use of a different audio compression mask.

Kind regards,

Dennis

Op 4 mrt. 2016 2:21 PM schreef Steve Matzura <sm at noisynotes.com>:

All the broadcasters on the server which I support deliver their
content in MP3 format. Recently, there's been interest in supplying a
second AAC stream at half the bandwidth but with the same audio
quality (64kbps AAC versus 128kbps MP3) like TuneInRadio does for
delivering their content regardless of the source. I've thought of
using a third-party product called Stream Transcoder, but am dubious
as to whether it will do the job. Does anyone know of a better or more
efficient way to do this? I know the MP3 stream requires re-encoding
into AAC format, but am not sure of the proper tool to use to do it.

As always, thanks in advance.
_______________________________________________
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/20160304/70c722d1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20160304/70c722d1/attachment.sig>

From thatjackelliott at kpov.org  Fri Mar  4 22:26:44 2016
From: thatjackelliott at kpov.org (Jack Elliott)
Date: Fri, 4 Mar 2016 14:26:44 -0800
Subject: [Icecast] Use web admin to re-start source?
Message-ID: <56DA0BA4.6010806@kpov.org>

Hi,

I see that I can use the "Kill Source" button on the Icecast admin web 
page to kill our fallback.mp3 file.

Now that I have killed the fallback file, I don't see a way to re-start 
it. Do I need to stop / start the icecast service?

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



From epirat07 at gmail.com  Fri Mar  4 23:10:11 2016
From: epirat07 at gmail.com (Marvin Scholz)
Date: Sat, 05 Mar 2016 00:10:11 +0100
Subject: [Icecast] Use web admin to re-start source?
In-Reply-To: <56DA0BA4.6010806@kpov.org>
References: <56DA0BA4.6010806@kpov.org>
Message-ID: <0A498F37-F17E-441A-B67C-086E62BFDF54@gmail.com>

On 4 Mar 2016, at 23:26, Jack Elliott wrote:

> Hi,
>
> I see that I can use the "Kill Source" button on the Icecast admin web
> page to kill our fallback.mp3 file.
>
> Now that I have killed the fallback file, I don't see a way to 
> re-start
> it. Do I need to stop / start the icecast service?

This has nothing to do with Icecast, it's just that your source client 
has to reconnect.
It depends on the source client how it handles reconnecting to Icecast.
What "kill source" does, is just disconnect the source client, nothing 
else.

>
> -- 
> That Jack Elliott
> (541) 848 7021
> KPOV 88.9 FM High Desert Community radio
> Producer, The Wednesday Point
> Host, The Sunday Classics
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast


From thatjackelliott at kpov.org  Fri Mar  4 23:39:24 2016
From: thatjackelliott at kpov.org (Jack Elliott)
Date: Fri, 4 Mar 2016 15:39:24 -0800
Subject: [Icecast] Use web admin to re-start source?
In-Reply-To: <0A498F37-F17E-441A-B67C-086E62BFDF54@gmail.com>
References: <56DA0BA4.6010806@kpov.org>
	<0A498F37-F17E-441A-B67C-086E62BFDF54@gmail.com>
Message-ID: <56DA1CAC.4000402@kpov.org>

Thank you. In this case, the source client is the fallback mount, which 
is an mp3 file.

I think I found my issue.

The code in icecast.xml looks like this:

  <mount type="normal">
         <mount-name>/stream</mount-name>
         <max-listeners>6</max-listeners>
         <burst-size>65536</burst-size>
         <fallback-mount>/fallback.mp3</fallback-mount>
         <fallback-override>1</fallback-override>
         <fallback-when-full>1</fallback-when-full>
     <stream-name>KPOV private remote stream</stream-name>

When the Icecast source client mount "/stream" is powered off or 
disconnected, the listen client hears the fallback-mount, which is the 
file fallback.mp3 . This is expected behavior.

If I use the "Kill Source" button on the web admin page at 
/admin/listmounts.xsl to kill the fallback, the listen client stops 
playing and the listmounts.xsl page shows

    Message: Source Removed

    Return Code: 1


This also seems like expected behavior.

If I reconnect the listen client, I hear the fallback.mp3 file again.

But if I refresh the listmounts.xsl page (it is still showing the 
"Source Removed" message and Return Code), it kills the stream again. So 
refreshing that page seems to re-issue the "Kill Source" command. This 
is unexpected behavior.

But no big deal: if I first navigate away from listmounts.xsl then 
return (instead of refreshing it) it shows the fallback playing normally.

A RFE: would it be possible for the current stream bitrates to be 
displayed on stats.xsl ?

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

On 03/04/2016 03:10 PM, Marvin Scholz wrote:
> On 4 Mar 2016, at 23:26, Jack Elliott wrote:
>
>> Hi,
>>
>> I see that I can use the "Kill Source" button on the Icecast admin web
>> page to kill our fallback.mp3 file.
>>
>> Now that I have killed the fallback file, I don't see a way to
>> re-start
>> it. Do I need to stop / start the icecast service?
> This has nothing to do with Icecast, it's just that your source client
> has to reconnect.
> It depends on the source client how it handles reconnecting to Icecast.
> What "kill source" does, is just disconnect the source client, nothing
> else.
>
>> -- 
>> That Jack Elliott
>> (541) 848 7021
>> KPOV 88.9 FM High Desert Community radio
>> Producer, The Wednesday Point
>> Host, The Sunday Classics
>>
>> _______________________________________________
>> 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/20160304/c02b1180/attachment.htm>

From epirat07 at gmail.com  Fri Mar  4 23:44:18 2016
From: epirat07 at gmail.com (Marvin Scholz)
Date: Sat, 05 Mar 2016 00:44:18 +0100
Subject: [Icecast] Use web admin to re-start source?
In-Reply-To: <56DA1CAC.4000402@kpov.org>
References: <56DA0BA4.6010806@kpov.org>
	<0A498F37-F17E-441A-B67C-086E62BFDF54@gmail.com>
	<56DA1CAC.4000402@kpov.org>
Message-ID: <F9DEAF10-53DA-416A-BD02-8CEC172E6200@gmail.com>

On 5 Mar 2016, at 0:39, Jack Elliott wrote:

> [?]
> But if I refresh the listmounts.xsl page (it is still showing the 
> "Source Removed" message and Return Code), it kills the stream again. 
> So refreshing that page seems to re-issue the "Kill Source" command. 
> This is unexpected behavior.

I agree, but until we implement HTTP POST support for the Web interface 
there is no way to change that, but it is definitely planned for a 
future release.

>
> But no big deal: if I first navigate away from listmounts.xsl then 
> return (instead of refreshing it) it shows the fallback playing 
> normally.
>
> A RFE: would it be possible for the current stream bitrates to be 
> displayed on stats.xsl ?

Do you mean on the public stats or the admin stats page?


From thatjackelliott at kpov.org  Fri Mar  4 23:49:34 2016
From: thatjackelliott at kpov.org (Jack Elliott)
Date: Fri, 4 Mar 2016 15:49:34 -0800
Subject: [Icecast] Use web admin to re-start source?
In-Reply-To: <F9DEAF10-53DA-416A-BD02-8CEC172E6200@gmail.com>
References: <56DA0BA4.6010806@kpov.org>
	<0A498F37-F17E-441A-B67C-086E62BFDF54@gmail.com>
	<56DA1CAC.4000402@kpov.org>
	<F9DEAF10-53DA-416A-BD02-8CEC172E6200@gmail.com>
Message-ID: <56DA1F0E.9000000@kpov.org>

On 03/04/2016 03:44 PM, Marvin Scholz wrote:
> On 5 Mar 2016, at 0:39, Jack Elliott wrote:
>
>> [?]
>> But if I refresh the listmounts.xsl page (it is still showing the
>> "Source Removed" message and Return Code), it kills the stream again.
>> So refreshing that page seems to re-issue the "Kill Source" command.
>> This is unexpected behavior.
> I agree, but until we implement HTTP POST support for the Web interface
> there is no way to change that, but it is definitely planned for a
> future release.

Thanks, I'll just remember to avoid refreshing the page.

>
>
>
> A RFE: would it be possible for the current stream bitrates to be
> displayed on stats.xsl ?
> Do you mean on the public stats or the admin stats page?

Admin, probably, as I don't normally look at the public page. But it's 
your call.

-- 
Jack Elliott


From mcmillanje at gmail.com  Wed Mar 30 19:17:02 2016
From: mcmillanje at gmail.com (Jesse McMillan)
Date: Wed, 30 Mar 2016 19:17:02 +0000
Subject: [Icecast] Help with port forwarding
Message-ID: <CAB4mcSxtU9nX2vKi_WYv5Qj9Qy28EMKGAYLihrbjnLMcuPtn7A@mail.gmail.com>

I'm using a windows computer as an icecast server. I can successfully
access my stream on my local network using 192.168.0.123:8000/stream. In my
netgear router I set up a port forward from external port 8000 to
192.168.0.123:8000, but when I try to access my stream using <my public
ip>:8000/stream the connection times out.

I've set up firewall rules to allow icecast, and even tried temporarily
disabling the firewall. What else could be causing this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20160330/7a017375/attachment.htm>

From awi3 at live.com  Wed Mar 30 19:44:25 2016
From: awi3 at live.com (Alan Bowness)
Date: Wed, 30 Mar 2016 20:44:25 +0100
Subject: [Icecast] Help with port forwarding
Message-ID: <DUB403-EAS10DFA4FEAEBDC5FD702568EF980@phx.gbl>

Sounds like if you are testing this in the same place where the server is that your router may not be doing ?loopback?.. ask a friend to test it from their end, or at least reboot the router (some are fussy things)
You can also test your ports externally from here:

port tests

regards



From: Jesse McMillan 
Sent: Wednesday, March 30, 2016 8:17 PM
To: icecast at xiph.org 
Subject: [Icecast] Help with port forwarding

I'm using a windows computer as an icecast server. I can successfully access my stream on my local network using 192.168.0.123:8000/stream. In my netgear router I set up a port forward from external port 8000 to 192.168.0.123:8000, but when I try to access my stream using <my public ip>:8000/stream the connection times out. 

I've set up firewall rules to allow icecast, and even tried temporarily disabling the firewall. What else could be causing this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20160330/ee3b8122/attachment.htm>

From abitar.com at gmail.com  Thu Mar 31 11:06:10 2016
From: abitar.com at gmail.com (David Saunders)
Date: Thu, 31 Mar 2016 07:06:10 -0400
Subject: [Icecast] Help with port forwarding
In-Reply-To: <CAB4mcSxtU9nX2vKi_WYv5Qj9Qy28EMKGAYLihrbjnLMcuPtn7A@mail.gmail.com>
References: <CAB4mcSxtU9nX2vKi_WYv5Qj9Qy28EMKGAYLihrbjnLMcuPtn7A@mail.gmail.com>
Message-ID: <CAOjZz+=we-HZucyZEEUhBR8g0pN3gOWigBnLo052fUx5mgTUWA@mail.gmail.com>

Hey,

 A few things can be not working here.

1> Can you get to http://<you public IP>>:8000/  status screen from outside
your local network?

     a> if no make sure your setting are right and forward both udp and
tcp.  And for good measure forward port 8001.
      b> check the widows firewall permissions, you can temporary disable
them to see if it will work then delve into it to make the port access the
internet and not just local network.
     b> still not working, well I am for a loss of ideas if you cant see
the status screen then there something your router is not doing correctly.
There is to many routers out there to tell the exact way of doing it.

2> ok, you see the status screen, then check make sure you allowing UDP on
both windows firewall and router.

 If that not working then try changing the port to something random to see
it it works, its possible somewhere in your test it being block by another
source.  I have found it blocked by the client firewall, the ISP did not
allow connection to the port, and even the "ip" of the server had changed
between testing.

But one last thing,  allot of routers I have found do not let local loop
back of public IP from inside the network. Meaning, you have to test this
on network outside you private LAN. And you private LAN cannot connect to
you public IP.

David.


On Wed, Mar 30, 2016 at 3:17 PM, Jesse McMillan <mcmillanje at gmail.com>
wrote:

> I'm using a windows computer as an icecast server. I can successfully
> access my stream on my local network using 192.168.0.123:8000/stream. In
> my netgear router I set up a port forward from external port 8000 to
> 192.168.0.123:8000, but when I try to access my stream using <my public
> ip>:8000/stream the connection times out.
>
> I've set up firewall rules to allow icecast, and even tried temporarily
> disabling the firewall. What else could be causing this?
>
> _______________________________________________
> 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/20160331/ebf6de35/attachment.htm>

From sebastian.pinero.a at gmail.com  Tue Mar 29 23:41:46 2016
From: sebastian.pinero.a at gmail.com (=?UTF-8?Q?Sebastian_David_Pi=C3=B1ero_Ag=C3=BCero?=)
Date: Tue, 29 Mar 2016 20:41:46 -0300
Subject: [Icecast] Requirements Icecast
Message-ID: <CAN1-pNkLVf8yee5Ckc3__drnsJbxtjx6EB-W2pnO4o+u7Uw9WQ@mail.gmail.com>

Hi , I searched within your page but not meeting the minimum requirements
for proper operation of Icecast . What are the minimum hardware
requirements you need Icecast to operate properly? Best regards

-- 
Sebastian David Pi?ero Ag?ero

Ingeniero SEC Clase A
Ejecuci?n El?ctrica, Electr?nica
Redes & Telecomunicaciones
Tecn?logo en Telecomunicaciones
Universidad de Santiago de Chile

sebastian.pinero.a at gmail.com
https://facebook.com/netforallchile/
https://twitter.com/netforallchile
http://netforallchile.tumblr.com/


   -
      - cl.linkedin.com/in/sebastiandavidpineroaguero/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20160329/ae70ca35/attachment.htm>