From un at dom.de  Sat May  3 16:14:47 2014
From: un at dom.de (unosonic)
Date: Sat, 3 May 2014 18:14:47 +0200
Subject: [Icecast] html5/js source client?
Message-ID: <20140503161447.GB521@aporee.org>


hello,

now that html5 audio becomes usable in some browsers, for example
http://webaudiodemos.appspot.com/AudioRecorder/index.html ...

has anybody thought about to implement a web based source client 
for icecast? that's for now beyond my coding skills, unfortunately...

thx, uno 




From toots at rastageeks.org  Sat May  3 16:24:16 2014
From: toots at rastageeks.org (Romain Beauxis)
Date: Sat, 3 May 2014 11:24:16 -0500
Subject: [Icecast] html5/js source client?
In-Reply-To: <20140503161447.GB521@aporee.org>
References: <20140503161447.GB521@aporee.org>
Message-ID: <CABWZ6ORZAunhYAWuW8UimOhk7kmyAOsFe6j0TA829o2JJ-gmcQ@mail.gmail.com>

2014-05-03 11:14 GMT-05:00 unosonic <un at dom.de>:
>
> hello,
>
> now that html5 audio becomes usable in some browsers, for example
> http://webaudiodemos.appspot.com/AudioRecorder/index.html ...
>
> has anybody thought about to implement a web based source client
> for icecast? that's for now beyond my coding skills, unfortunately...

I worked on that with Samuel last summer but the implementation(s) and
API(s) across browsers were too young at that time.. Haven't checked
it since then.

We had a websocket-based streaming protocol supported in liquidsoap:
https://github.com/webcast/webcast.js

And a test client: https://github.com/webcast/webcaster that was kinda
working on firefox nightly and chrome canary..

Romain


From brad at musatcha.com  Sat May  3 16:40:44 2014
From: brad at musatcha.com (Brad Isbell)
Date: Sat, 3 May 2014 11:40:44 -0500
Subject: [Icecast] html5/js source client?
In-Reply-To: <20140503161447.GB521@aporee.org>
References: <20140503161447.GB521@aporee.org>
Message-ID: <CAELR-fDXnMDRLBOdbZfObYE6PXXz+FXSSn7=vv4NvMPjxJpJtw@mail.gmail.com>

I have built a web-based source client using the Web Audio API and
getUserMedia, called the AudioPump Web Encoder.  It uses the SHOUTcast
source protocol for now, but I have the code nearly ready for the Icecast
source protocol for when someone needs it.

You can see a demo here:  http://demo.audiopump.co:3000/

The Web Encoder is built with a jQuery Mobile UI optimized for mobile
devices at the moment.  It's compatible with Chrome (desktop and latest of
mobile), Firefox (desktop and mobile), and Opera (desktop only).  Binary
web sockets are used for sending audio to the server, where it is encoded
into the desired codec(s) and sent off to Icecast/SHOUTcast servers.

The general idea was to make a really simple source client that could be
launched with a single click (such as from a hosting provider's admin
panel).  The client accepts parameters on the query-string for configuring
so that in a real-world environment, the user would not have to configure
anything.  It is also built in such a way that the UI can be thrown away,
leaving the back-end code to integrate into another application.

Let me know if there is interest.  I can easily add the native Icecast
compatibility.

Brad Isbell
brad at musatcha.com
http://www.musatcha.com


On Sat, May 3, 2014 at 11:14 AM, unosonic <un at dom.de> wrote:

>
> hello,
>
> now that html5 audio becomes usable in some browsers, for example
> http://webaudiodemos.appspot.com/AudioRecorder/index.html ...
>
> has anybody thought about to implement a web based source client
> for icecast? that's for now beyond my coding skills, unfortunately...
>
> thx, uno
>
>
> _______________________________________________
> 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/20140503/d6992c3e/attachment.htm>

From un at dom.de  Sat May  3 17:04:44 2014
From: un at dom.de (unosonic)
Date: Sat, 3 May 2014 19:04:44 +0200
Subject: [Icecast] html5/js source client?
In-Reply-To: <CAELR-fDXnMDRLBOdbZfObYE6PXXz+FXSSn7=vv4NvMPjxJpJtw@mail.gmail.com>
References: <20140503161447.GB521@aporee.org>
	<CAELR-fDXnMDRLBOdbZfObYE6PXXz+FXSSn7=vv4NvMPjxJpJtw@mail.gmail.com>
Message-ID: <20140503170444.GC521@aporee.org>




Brad Isbell:
> I have built a web-based source client using the Web Audio API and
> You can see a demo here:  http://demo.audiopump.co:3000/

oh my, that looks great!!!

> Let me know if there is interest.  I can easily add the native Icecast
> compatibility.

definitely! i've only an icecast server available...

thx, uno






From jake at dai5ychain.net  Sat May  3 17:05:25 2014
From: jake at dai5ychain.net (Jake Elliott)
Date: Sat, 3 May 2014 12:05:25 -0500
Subject: [Icecast] html5/js source client?
In-Reply-To: <20140503170444.GC521@aporee.org>
References: <20140503161447.GB521@aporee.org>
	<CAELR-fDXnMDRLBOdbZfObYE6PXXz+FXSSn7=vv4NvMPjxJpJtw@mail.gmail.com>
	<20140503170444.GC521@aporee.org>
Message-ID: <CAAy+FgnM0JfjCy1zuZWt2p11a3g2En338n5CmWDhceWKydY9BA@mail.gmail.com>

Hi y'all ---

A browser-based source client sounds fantastic! Brad, I'd love to hear
if you add icecast support; please do keep us posted :)

cya
jake

On Sat, May 3, 2014 at 12:04 PM, unosonic <un at dom.de> wrote:
>
>
>
> Brad Isbell:
>> I have built a web-based source client using the Web Audio API and
>> You can see a demo here:  http://demo.audiopump.co:3000/
>
> oh my, that looks great!!!
>
>> Let me know if there is interest.  I can easily add the native Icecast
>> compatibility.
>
> definitely! i've only an icecast server available...
>
> thx, uno
>
>
>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast


From thomas at ruecker.fi  Sat May  3 17:24:27 2014
From: thomas at ruecker.fi (=?ISO-8859-1?Q?=22Thomas_B=2E_R=FCcker=22?=)
Date: Sat, 03 May 2014 17:24:27 +0000
Subject: [Icecast] html5/js source client?
In-Reply-To: <CAELR-fDXnMDRLBOdbZfObYE6PXXz+FXSSn7=vv4NvMPjxJpJtw@mail.gmail.com>
References: <20140503161447.GB521@aporee.org>
	<CAELR-fDXnMDRLBOdbZfObYE6PXXz+FXSSn7=vv4NvMPjxJpJtw@mail.gmail.com>
Message-ID: <5365264B.4040008@ruecker.fi>

On 05/03/2014 04:40 PM, Brad Isbell wrote:
> I have built a web-based source client using the Web Audio API and
> getUserMedia, called the AudioPump Web Encoder.  It uses the SHOUTcast
> source protocol for now, but I have the code nearly ready for the
> Icecast source protocol for when someone needs it.
>
> You can see a demo here:  http://demo.audiopump.co:3000/

That's pretty impressive.


> The Web Encoder is built with a jQuery Mobile UI optimized for mobile
> devices at the moment.  It's compatible with Chrome (desktop and
> latest of mobile), Firefox (desktop and mobile), and Opera (desktop
> only).  Binary web sockets are used for sending audio to the server,
> where it is encoded into the desired codec(s)

Out of curiosity, what are you using as the intermediate codec? I think
most of those browsers support Opus (for webRTC) and it might be even
possible to go directly to Icecast without the mediating server.


> and sent off to Icecast/SHOUTcast servers.

Please note, that we're about to release version 2.4 and will deprecate
the SOURCE method in favor of plain HTTP1.1 PUT.
Might want to keep that in mind. We're going to support SOURCE still for
a long while, but it might be easier for future source clients to
support PUT.


>
> The general idea was to make a really simple source client that could
> be launched with a single click (such as from a hosting provider's
> admin panel).  The client accepts parameters on the query-string for
> configuring so that in a real-world environment, the user would not
> have to configure anything.  It is also built in such a way that the
> UI can be thrown away, leaving the back-end code to integrate into
> another application.

That's indeed very nice. I will have to ask a question though, will it
be open source or is this a commercial solution?


> Let me know if there is interest.  I can easily add the native Icecast
> compatibility.

I think the echo on the list speaks for itself. :-)

Cheers

Thomas


From toots at rastageeks.org  Sat May  3 19:45:42 2014
From: toots at rastageeks.org (Romain Beauxis)
Date: Sat, 3 May 2014 14:45:42 -0500
Subject: [Icecast] html5/js source client?
In-Reply-To: <CAELR-fDXnMDRLBOdbZfObYE6PXXz+FXSSn7=vv4NvMPjxJpJtw@mail.gmail.com>
References: <20140503161447.GB521@aporee.org>
	<CAELR-fDXnMDRLBOdbZfObYE6PXXz+FXSSn7=vv4NvMPjxJpJtw@mail.gmail.com>
Message-ID: <CABWZ6OT_LbWKMhRVJ34nO--ntbwhfeOr2eQPuLJFoCCVr1EJPw@mail.gmail.com>

Hi Brad,

2014-05-03 11:40 GMT-05:00 Brad Isbell <brad at musatcha.com>:
> I have built a web-based source client using the Web Audio API and
> getUserMedia, called the AudioPump Web Encoder.  It uses the SHOUTcast
> source protocol for now, but I have the code nearly ready for the Icecast
> source protocol for when someone needs it.
>
> You can see a demo here:  http://demo.audiopump.co:3000/
>
> The Web Encoder is built with a jQuery Mobile UI optimized for mobile
> devices at the moment.  It's compatible with Chrome (desktop and latest of
> mobile), Firefox (desktop and mobile), and Opera (desktop only).  Binary web
> sockets are used for sending audio to the server, where it is encoded into
> the desired codec(s) and sent off to Icecast/SHOUTcast servers.
>
> The general idea was to make a really simple source client that could be
> launched with a single click (such as from a hosting provider's admin
> panel).  The client accepts parameters on the query-string for configuring
> so that in a real-world environment, the user would not have to configure
> anything.  It is also built in such a way that the UI can be thrown away,
> leaving the back-end code to integrate into another application.
>
> Let me know if there is interest.  I can easily add the native Icecast
> compatibility.

That looks very promising. Do you have any code/documentation
available? I'd be very curious to see how you guys work this out..

Romain


From toots at rastageeks.org  Sat May  3 19:46:31 2014
From: toots at rastageeks.org (Romain Beauxis)
Date: Sat, 3 May 2014 14:46:31 -0500
Subject: [Icecast] html5/js source client?
In-Reply-To: <5365264B.4040008@ruecker.fi>
References: <20140503161447.GB521@aporee.org>
	<CAELR-fDXnMDRLBOdbZfObYE6PXXz+FXSSn7=vv4NvMPjxJpJtw@mail.gmail.com>
	<5365264B.4040008@ruecker.fi>
Message-ID: <CABWZ6OTONq+My8ayWmN12DwmxDgGv+JM2gaYmcros6Cx0fBf3w@mail.gmail.com>

2014-05-03 12:24 GMT-05:00 "Thomas B. R?cker" <thomas at ruecker.fi>:
> On 05/03/2014 04:40 PM, Brad Isbell wrote:
>> I have built a web-based source client using the Web Audio API and
>> getUserMedia, called the AudioPump Web Encoder.  It uses the SHOUTcast
>> source protocol for now, but I have the code nearly ready for the
>> Icecast source protocol for when someone needs it.
>>
>> You can see a demo here:  http://demo.audiopump.co:3000/
>
> That's pretty impressive.
>
>
>> The Web Encoder is built with a jQuery Mobile UI optimized for mobile
>> devices at the moment.  It's compatible with Chrome (desktop and
>> latest of mobile), Firefox (desktop and mobile), and Opera (desktop
>> only).  Binary web sockets are used for sending audio to the server,
>> where it is encoded into the desired codec(s)
>
> Out of curiosity, what are you using as the intermediate codec? I think
> most of those browsers support Opus (for webRTC) and it might be even
> possible to go directly to Icecast without the mediating server.
>
>
>> and sent off to Icecast/SHOUTcast servers.
>
> Please note, that we're about to release version 2.4 and will deprecate
> the SOURCE method in favor of plain HTTP1.1 PUT.
> Might want to keep that in mind. We're going to support SOURCE still for
> a long while, but it might be easier for future source clients to
> support PUT.

That surely is a very exciting news!!

>>
>> The general idea was to make a really simple source client that could
>> be launched with a single click (such as from a hosting provider's
>> admin panel).  The client accepts parameters on the query-string for
>> configuring so that in a real-world environment, the user would not
>> have to configure anything.  It is also built in such a way that the
>> UI can be thrown away, leaving the back-end code to integrate into
>> another application.
>
> That's indeed very nice. I will have to ask a question though, will it
> be open source or is this a commercial solution?
>
>
>> Let me know if there is interest.  I can easily add the native Icecast
>> compatibility.
>
> I think the echo on the list speaks for itself. :-)
>
> Cheers
>
> Thomas
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast


From xoneca+icecast at gmail.com  Sun May  4 15:30:30 2014
From: xoneca+icecast at gmail.com (Xabier Oneca -- xOneca)
Date: Sun, 4 May 2014 17:30:30 +0200
Subject: [Icecast] html5/js source client?
In-Reply-To: <CAELR-fDXnMDRLBOdbZfObYE6PXXz+FXSSn7=vv4NvMPjxJpJtw@mail.gmail.com>
References: <20140503161447.GB521@aporee.org>
	<CAELR-fDXnMDRLBOdbZfObYE6PXXz+FXSSn7=vv4NvMPjxJpJtw@mail.gmail.com>
Message-ID: <CACkgH71QO3GOzHHEjRpiz5bTgS5hhFOjkkgm1XiJCc6PAqH_DA@mail.gmail.com>

2014-05-03 18:40 GMT+02:00 Brad Isbell <brad at musatcha.com>:
> The general idea was to make a really simple source client that could be
> launched with a single click (such as from a hosting provider's admin
> panel).  The client accepts parameters on the query-string for configuring
> so that in a real-world environment, the user would not have to configure
> anything.  It is also built in such a way that the UI can be thrown away,
> leaving the back-end code to integrate into another application.

Wow! That screams for integration with Icecast2 web admin panel if opensourced!!

Cheers,

Xabier Oneca_,,_


From ancsika024 at gmail.com  Sun May  4 20:10:55 2014
From: ancsika024 at gmail.com (Anita Mate)
Date: Sun, 4 May 2014 22:10:55 +0200
Subject: [Icecast] Icecast Digest, Vol 119, Issue 2
In-Reply-To: <mailman.3.1399230002.10232.icecast@xiph.org>
References: <mailman.3.1399230002.10232.icecast@xiph.org>
Message-ID: <CAO80DZ_oooqo9XQGvbsHZG=-H7V27mK7qY1kBR=wYtHSMZ50uA@mail.gmail.com>

 html5/js source client? (Xabier Oneca -- xOneca)


2014-05-04 21:00 GMT+02:00 <icecast-request at xiph.org>:

> Send Icecast mailing list submissions to
>         icecast at xiph.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.xiph.org/mailman/listinfo/icecast
> or, via email, send a message with subject or body 'help' to
>         icecast-request at xiph.org
>
> You can reach the person managing the list at
>         icecast-owner at xiph.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Icecast digest..."
>
>
> Today's Topics:
>
>    1. Re: html5/js source client? (Romain Beauxis)
>    2. Re: html5/js source client? (Romain Beauxis)
>    3. Re: html5/js source client? (Xabier Oneca -- xOneca)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 3 May 2014 14:45:42 -0500
> From: Romain Beauxis <toots at rastageeks.org>
> Subject: Re: [Icecast] html5/js source client?
> To: Icecast streaming server user discussions <icecast at xiph.org>
> Message-ID:
>         <
> CABWZ6OT_LbWKMhRVJ34nO--ntbwhfeOr2eQPuLJFoCCVr1EJPw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Brad,
>
> 2014-05-03 11:40 GMT-05:00 Brad Isbell <brad at musatcha.com>:
> > I have built a web-based source client using the Web Audio API and
> > getUserMedia, called the AudioPump Web Encoder.  It uses the SHOUTcast
> > source protocol for now, but I have the code nearly ready for the Icecast
> > source protocol for when someone needs it.
> >
> > You can see a demo here:  http://demo.audiopump.co:3000/
> >
> > The Web Encoder is built with a jQuery Mobile UI optimized for mobile
> > devices at the moment.  It's compatible with Chrome (desktop and latest
> of
> > mobile), Firefox (desktop and mobile), and Opera (desktop only).  Binary
> web
> > sockets are used for sending audio to the server, where it is encoded
> into
> > the desired codec(s) and sent off to Icecast/SHOUTcast servers.
> >
> > The general idea was to make a really simple source client that could be
> > launched with a single click (such as from a hosting provider's admin
> > panel).  The client accepts parameters on the query-string for
> configuring
> > so that in a real-world environment, the user would not have to configure
> > anything.  It is also built in such a way that the UI can be thrown away,
> > leaving the back-end code to integrate into another application.
> >
> > Let me know if there is interest.  I can easily add the native Icecast
> > compatibility.
>
> That looks very promising. Do you have any code/documentation
> available? I'd be very curious to see how you guys work this out..
>
> Romain
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 3 May 2014 14:46:31 -0500
> From: Romain Beauxis <toots at rastageeks.org>
> Subject: Re: [Icecast] html5/js source client?
> To: Icecast streaming server user discussions <icecast at xiph.org>
> Message-ID:
>         <
> CABWZ6OTONq+My8ayWmN12DwmxDgGv+JM2gaYmcros6Cx0fBf3w at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 2014-05-03 12:24 GMT-05:00 "Thomas B. R?cker" <thomas at ruecker.fi>:
> > On 05/03/2014 04:40 PM, Brad Isbell wrote:
> >> I have built a web-based source client using the Web Audio API and
> >> getUserMedia, called the AudioPump Web Encoder.  It uses the SHOUTcast
> >> source protocol for now, but I have the code nearly ready for the
> >> Icecast source protocol for when someone needs it.
> >>
> >> You can see a demo here:  http://demo.audiopump.co:3000/
> >
> > That's pretty impressive.
> >
> >
> >> The Web Encoder is built with a jQuery Mobile UI optimized for mobile
> >> devices at the moment.  It's compatible with Chrome (desktop and
> >> latest of mobile), Firefox (desktop and mobile), and Opera (desktop
> >> only).  Binary web sockets are used for sending audio to the server,
> >> where it is encoded into the desired codec(s)
> >
> > Out of curiosity, what are you using as the intermediate codec? I think
> > most of those browsers support Opus (for webRTC) and it might be even
> > possible to go directly to Icecast without the mediating server.
> >
> >
> >> and sent off to Icecast/SHOUTcast servers.
> >
> > Please note, that we're about to release version 2.4 and will deprecate
> > the SOURCE method in favor of plain HTTP1.1 PUT.
> > Might want to keep that in mind. We're going to support SOURCE still for
> > a long while, but it might be easier for future source clients to
> > support PUT.
>
> That surely is a very exciting news!!
>
> >>
> >> The general idea was to make a really simple source client that could
> >> be launched with a single click (such as from a hosting provider's
> >> admin panel).  The client accepts parameters on the query-string for
> >> configuring so that in a real-world environment, the user would not
> >> have to configure anything.  It is also built in such a way that the
> >> UI can be thrown away, leaving the back-end code to integrate into
> >> another application.
> >
> > That's indeed very nice. I will have to ask a question though, will it
> > be open source or is this a commercial solution?
> >
> >
> >> Let me know if there is interest.  I can easily add the native Icecast
> >> compatibility.
> >
> > I think the echo on the list speaks for itself. :-)
> >
> > Cheers
> >
> > Thomas
> > _______________________________________________
> > Icecast mailing list
> > Icecast at xiph.org
> > http://lists.xiph.org/mailman/listinfo/icecast
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 4 May 2014 17:30:30 +0200
> From: Xabier Oneca  --  xOneca <xoneca+icecast at gmail.com>
> Subject: Re: [Icecast] html5/js source client?
> To: Icecast streaming server user discussions <icecast at xiph.org>
> Message-ID:
>         <
> CACkgH71QO3GOzHHEjRpiz5bTgS5hhFOjkkgm1XiJCc6PAqH_DA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 2014-05-03 18:40 GMT+02:00 Brad Isbell <brad at musatcha.com>:
> > The general idea was to make a really simple source client that could be
> > launched with a single click (such as from a hosting provider's admin
> > panel).  The client accepts parameters on the query-string for
> configuring
> > so that in a real-world environment, the user would not have to configure
> > anything.  It is also built in such a way that the UI can be thrown away,
> > leaving the back-end code to integrate into another application.
>
> Wow! That screams for integration with Icecast2 web admin panel if
> opensourced!!
>
> Cheers,
>
> Xabier Oneca_,,_
>
>
> ------------------------------
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>
>
> End of Icecast Digest, Vol 119, Issue 2
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20140504/0797ea9b/attachment.htm>

From brad at musatcha.com  Mon May  5 23:01:19 2014
From: brad at musatcha.com (Brad Isbell)
Date: Mon, 5 May 2014 18:01:19 -0500
Subject: [Icecast] html5/js source client?
In-Reply-To: <CACkgH71QO3GOzHHEjRpiz5bTgS5hhFOjkkgm1XiJCc6PAqH_DA@mail.gmail.com>
References: <20140503161447.GB521@aporee.org>
	<CAELR-fDXnMDRLBOdbZfObYE6PXXz+FXSSn7=vv4NvMPjxJpJtw@mail.gmail.com>
	<CACkgH71QO3GOzHHEjRpiz5bTgS5hhFOjkkgm1XiJCc6PAqH_DA@mail.gmail.com>
Message-ID: <CAELR-fDXWp6vYJ+wOohQKBJdh3Wwq6X_Sr6n8Zjauy8REQbQ3A@mail.gmail.com>

Thanks everyone!  I will answer your questions regarding the AudioPump Web
Encoder (http://demo.audiopump.co:3000/):

*> Can you please explain the process exactly? what is the encoding server?*

There is a server built on Node.js that receives audio data, control data,
and metadata from the client over a binary websocket.  All of these are
multiplexed down the same connection.  When the server receives audio data,
it will pass it off to an external encoder via STDIO.  For testing
purposes, I am using FFmpeg, but you can use anything you want.  All that
matters is that it accepts PCM and outputs something that I can send to the
streaming server.

*> is your code production-ready?*

It is close.  The code works well for the users that are using it in
production today, but I would certainly like to test with more users and
browsers.  One challenge are browser bugs that I can't do much about.  For
instance, the VU metering doesn't work in stereo on Firefox because the
Firefox splitter node is broken.  Some folks have used this software to do
live remotes on both mobile and desktop with success.  Most of the issues I
have seen have been already patched in development versions of the
browsers, so it is just a matter of time before they are handled in the
releases.

*> can it work with Icecast?*

Yes, you can use SHOUTcast mode with Icecast currently.  Due to requests
from the community, I will implement HTTP PUT support to add compatibility
with Icecast 2.4.  This shouldn't be too hard to finish... it's a feature I
had been planning for.  I will e-mail the list again when this
functionality is enabled (or if that is considered spam, let me know and I
will only e-mail those that replied to me).

*> Out of curiosity, what are you using as the intermediate codec?*

Only PCM is possible today, with the Web Audio API.  Even if the browser
supports the codec, it is only accessible with WebRTC calls.  I originally
went down the path of a server-side WebRTC client.  This proved to be a
nightmare and not really feasible at the moment.  One guy seems to have
gotten it working over a year ago by importing a huge chunk of Chromium
(libjingle and all that), but that code doesn't seem to work anymore due to
the internal structure of Chromium changing dramatically.  Running the
binaries he built result in segfault.  If anyone knows of a way to record
WebRTC server-side, please let me know.  I'm sure this will be possible in
the near future, but for now it's too difficult (at least for me).  In the
mean time, I am sticking with PCM.  I convert the 32-bit floating point
samples from the Web Audio API into 16-bit or 8-bit samples, and then
convert them back up server-side.  The intent is to adjust for bandwidth
conditions on the fly, but for now I just let the user pick the desired bit
depth.  Since the server converts it back up to 32-bit before sending to
the encoder, you can change bit-depth on the fly mid-stream.  In the
future, I hope to add some client-side codec (at least FLAC).  I also need
to be cautious of licensing, if I am going to include a codec via
JavaScript.  If there is a silver lining, it's that you only compress once
with this method, giving you better quality audio than re-compressing
something that was already encoded lossy.

*>  will it be open source or is this a commercial solution?*

Commercial.  I am developing software to help improve internet radio, and
have just started AudioPump, Inc. <http://audiopump.co> to help with that
goal.  If at some point I can make other products more profitable, I would
love to open source some of my work.  But, that is not something I can do
at the moment.  If you have interest in using this or part of it
commercially, please contact me at brad at audiopump.co.  with information on
your project and we can chat about it.

*> Wow! That screams for integration with Icecast2 web admin panel if
opensourced!!*

Thanks for the note, but even if open sourced, I don't think it would be a
good candidate for integration due to its reliance on Node.js.  Icecast
developers could certainly develop something similar, however.  If I were a
C++ developer, I would definitely consider contributing.  If any Icecast
developers have questions about the implementation, I am happy to help with
any information I can provide.




Brad Isbell
brad at musatcha.com
http://www.musatcha.com


On Sun, May 4, 2014 at 10:30 AM, Xabier Oneca -- xOneca <
xoneca+icecast at gmail.com> wrote:

> 2014-05-03 18:40 GMT+02:00 Brad Isbell <brad at musatcha.com>:
> > The general idea was to make a really simple source client that could be
> > launched with a single click (such as from a hosting provider's admin
> > panel).  The client accepts parameters on the query-string for
> configuring
> > so that in a real-world environment, the user would not have to configure
> > anything.  It is also built in such a way that the UI can be thrown away,
> > leaving the back-end code to integrate into another application.
>
> Wow! That screams for integration with Icecast2 web admin panel if
> opensourced!!
>
> Cheers,
>
> Xabier Oneca_,,_
> _______________________________________________
> 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/20140505/9f25ae81/attachment.htm>

From toots at rastageeks.org  Tue May  6 14:06:32 2014
From: toots at rastageeks.org (Romain Beauxis)
Date: Tue, 6 May 2014 09:06:32 -0500
Subject: [Icecast] html5/js source client?
In-Reply-To: <CAELR-fDXWp6vYJ+wOohQKBJdh3Wwq6X_Sr6n8Zjauy8REQbQ3A@mail.gmail.com>
References: <20140503161447.GB521@aporee.org>
	<CAELR-fDXnMDRLBOdbZfObYE6PXXz+FXSSn7=vv4NvMPjxJpJtw@mail.gmail.com>
	<CACkgH71QO3GOzHHEjRpiz5bTgS5hhFOjkkgm1XiJCc6PAqH_DA@mail.gmail.com>
	<CAELR-fDXWp6vYJ+wOohQKBJdh3Wwq6X_Sr6n8Zjauy8REQbQ3A@mail.gmail.com>
Message-ID: <CABWZ6OTwZxTEfqsnwCVN3OrvKPum3O9w5dC0oKp9hk3yL43iKA@mail.gmail.com>

Hi,

2014-05-05 18:01 GMT-05:00 Brad Isbell <brad at musatcha.com>:
> Thanks everyone!  I will answer your questions regarding the AudioPump Web
> Encoder (http://demo.audiopump.co:3000/):
>
>> Can you please explain the process exactly? what is the encoding server?
>
> There is a server built on Node.js that receives audio data, control data,
> and metadata from the client over a binary websocket.  All of these are
> multiplexed down the same connection.  When the server receives audio data,
> it will pass it off to an external encoder via STDIO.  For testing purposes,
> I am using FFmpeg, but you can use anything you want.  All that matters is
> that it accepts PCM and outputs something that I can send to the streaming
> server.
>
>> is your code production-ready?
>
> It is close.  The code works well for the users that are using it in
> production today, but I would certainly like to test with more users and
> browsers.  One challenge are browser bugs that I can't do much about.  For
> instance, the VU metering doesn't work in stereo on Firefox because the
> Firefox splitter node is broken.  Some folks have used this software to do
> live remotes on both mobile and desktop with success.  Most of the issues I
> have seen have been already patched in development versions of the browsers,
> so it is just a matter of time before they are handled in the releases.
>
>> can it work with Icecast?
>
> Yes, you can use SHOUTcast mode with Icecast currently.  Due to requests
> from the community, I will implement HTTP PUT support to add compatibility
> with Icecast 2.4.  This shouldn't be too hard to finish... it's a feature I
> had been planning for.  I will e-mail the list again when this functionality
> is enabled (or if that is considered spam, let me know and I will only
> e-mail those that replied to me).
>
>> Out of curiosity, what are you using as the intermediate codec?
>
> Only PCM is possible today, with the Web Audio API.  Even if the browser
> supports the codec, it is only accessible with WebRTC calls.  I originally
> went down the path of a server-side WebRTC client.  This proved to be a
> nightmare and not really feasible at the moment.  One guy seems to have
> gotten it working over a year ago by importing a huge chunk of Chromium
> (libjingle and all that), but that code doesn't seem to work anymore due to
> the internal structure of Chromium changing dramatically.  Running the
> binaries he built result in segfault.  If anyone knows of a way to record
> WebRTC server-side, please let me know.  I'm sure this will be possible in
> the near future, but for now it's too difficult (at least for me).  In the
> mean time, I am sticking with PCM.  I convert the 32-bit floating point
> samples from the Web Audio API into 16-bit or 8-bit samples, and then
> convert them back up server-side.  The intent is to adjust for bandwidth
> conditions on the fly, but for now I just let the user pick the desired bit
> depth.  Since the server converts it back up to 32-bit before sending to the
> encoder, you can change bit-depth on the fly mid-stream.  In the future, I
> hope to add some client-side codec (at least FLAC).  I also need to be
> cautious of licensing, if I am going to include a codec via JavaScript.  If
> there is a silver lining, it's that you only compress once with this method,
> giving you better quality audio than re-compressing something that was
> already encoded lossy.
>
>>  will it be open source or is this a commercial solution?
>
> Commercial.  I am developing software to help improve internet radio, and
> have just started AudioPump, Inc. to help with that goal.  If at some point
> I can make other products more profitable, I would love to open source some
> of my work.  But, that is not something I can do at the moment.  If you have
> interest in using this or part of it commercially, please contact me at
> brad at audiopump.co.  with information on your project and we can chat about
> it.
>
>> Wow! That screams for integration with Icecast2 web admin panel if
>> opensourced!!
>
> Thanks for the note, but even if open sourced, I don't think it would be a
> good candidate for integration due to its reliance on Node.js.  Icecast
> developers could certainly develop something similar, however.  If I were a
> C++ developer, I would definitely consider contributing.  If any Icecast
> developers have questions about the implementation, I am happy to help with
> any information I can provide.

Thanks for these information. For the webcast.js project, we chose to
implement a client-side mp3 encoding, using emscripten and the shine
mp3 encoder. This works fine on firefox where asm.js is supported but
is borderline real time on chrome.. See:
https://github.com/webcast/webcast.js/blob/master/API.md and
https://github.com/savonet/shine/tree/master/js

A convenient client-side native Javascript API for encoding audio
would be much desirable but, unfortunately, there was nothing mature
and/or usable last time I checked..

Romain


From www.mail at ntlworld.com  Fri May  9 22:34:43 2014
From: www.mail at ntlworld.com (www.mail)
Date: Fri, 09 May 2014 23:34:43 +0100
Subject: [Icecast] DeaDBeeF Player For Linux And Android
In-Reply-To: <145e31e1250.277c.2207739ce3352e80bc3c83bb078774b7@ntlworld.com>
Message-ID: <145e31fc3e8.277c.2207739ce3352e80bc3c83bb078774b7@ntlworld.com>

Hi,

I would like to propose the addition of DeaDBeeF Player for Linux and 
Android, to the table entitled, "Media Players That Support Icecast 
Streaming" at http://www.icecast.org/3rdparty.php on the Icecast website.

DeaDBeeF for Linux can be downloaded from http://deadbeef.sourceforge.net/ 
and for Android from 
https://play.google.com/store/apps/details?id=org.deadbeef.android

If there are any issues which need to be addressed before the application 
can be listed on the Icecast website, or if there is a specific procedure 
for submission, please let me know.

Thanks for your help.

Regards,
Jacko




From un at dom.de  Sun May 11 09:39:37 2014
From: un at dom.de (uno)
Date: Sun, 11 May 2014 11:39:37 +0200
Subject: [Icecast] dynamic source auth?
Message-ID: <20140511093937.GA7963@aporee.org>


hello,
i'm sure that this has been asked before, but can't find it...
is there a way to authenticate a source dynamically, i.e. from a script/
database? i only see the static option in the icecast config xml.
thanks, uno


From yahav.shasha at gmail.com  Sun May 11 09:47:51 2014
From: yahav.shasha at gmail.com (Yahav Shasha)
Date: Sun, 11 May 2014 12:47:51 +0300
Subject: [Icecast] dynamic source auth?
In-Reply-To: <20140511093937.GA7963@aporee.org>
References: <20140511093937.GA7963@aporee.org>
Message-ID: <CABuab=SLfxuh3upwMKb5AfbBgLMK-qc1ox5EnbgaQQGBXXpnuw@mail.gmail.com>

Search the docs for Url auth
?????? 11 ???? 2014 12:39, "uno" <un at dom.de> ???:

>
> hello,
> i'm sure that this has been asked before, but can't find it...
> is there a way to authenticate a source dynamically, i.e. from a script/
> database? i only see the static option in the icecast config xml.
> thanks, uno
> _______________________________________________
> 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/20140511/15144141/attachment.htm>

From un at dom.de  Sun May 11 10:07:39 2014
From: un at dom.de (uno)
Date: Sun, 11 May 2014 12:07:39 +0200
Subject: [Icecast] dynamic source auth?
In-Reply-To: <CABuab=SLfxuh3upwMKb5AfbBgLMK-qc1ox5EnbgaQQGBXXpnuw@mail.gmail.com>
References: <20140511093937.GA7963@aporee.org>
	<CABuab=SLfxuh3upwMKb5AfbBgLMK-qc1ox5EnbgaQQGBXXpnuw@mail.gmail.com>
Message-ID: <20140511100738.GA10664@aporee.org>

Yahav Shasha:
> Search the docs for Url auth

for a *source* ? can't find it. is that a feature maybe of newer 
versions of icecast? thx, u.



> ?????? 11 ???? 2014 12:39, "uno" <un at dom.de> ???:
> 
> >
> > hello,
> > i'm sure that this has been asked before, but can't find it...
> > is there a way to authenticate a source dynamically, i.e. from a script/
> > database? i only see the static option in the icecast config xml.
> > thanks, uno



From thomas at ruecker.fi  Sun May 11 10:12:57 2014
From: thomas at ruecker.fi (=?ISO-8859-1?Q?=22Thomas_B=2E_R=FCcker=22?=)
Date: Sun, 11 May 2014 10:12:57 +0000
Subject: [Icecast] dynamic source auth?
In-Reply-To: <20140511093937.GA7963@aporee.org>
References: <20140511093937.GA7963@aporee.org>
Message-ID: <536F4D29.1030806@ruecker.fi>

On 05/11/2014 09:39 AM, uno wrote:
> hello,
> i'm sure that this has been asked before, but can't find it...
> is there a way to authenticate a source dynamically, i.e. from a script/
> database? i only see the static option in the icecast config xml.
Not only was it asked before, it was even implemented years ago. ;-)
It got first released in 2.3.3, but there was no proper documentation.

http://icecast.org/docs/icecast-2.4.0/icecast2_auth.html
(scroll to the very bottom)

2.4.0 has a bit more documentation. Essentially it's very similar to
listener URL authentication. Which is also documented there.

Cheers

Thomas


From un at dom.de  Mon May 12 10:40:21 2014
From: un at dom.de (uno)
Date: Mon, 12 May 2014 12:40:21 +0200
Subject: [Icecast] dynamic source auth?
In-Reply-To: <536F4D29.1030806@ruecker.fi>
References: <20140511093937.GA7963@aporee.org>
 <536F4D29.1030806@ruecker.fi>
Message-ID: <20140512104021.GA23848@aporee.org>

"Thomas B. R?cker":
> > is there a way to authenticate a source dynamically, i.e. from a script/

> Not only was it asked before, it was even implemented years ago. ;-)
> It got first released in 2.3.3, but there was no proper documentation.

oh my. i've to upgrade, using a debian 2.3.2 so far...
looks just perfect, thanks!

u.

> http://icecast.org/docs/icecast-2.4.0/icecast2_auth.html
> (scroll to the very bottom)
>
> 2.4.0 has a bit more documentation. Essentially it's very similar to
> listener URL authentication. Which is also documented there.


From thomas.ruecker at tieto.com  Mon May 12 10:50:29 2014
From: thomas.ruecker at tieto.com (=?UTF-8?Q?Thomas_R=C3=BCcker?=)
Date: Mon, 12 May 2014 13:50:29 +0300
Subject: [Icecast] dynamic source auth?
In-Reply-To: <20140512104021.GA23848@aporee.org>
References: <20140511093937.GA7963@aporee.org> <536F4D29.1030806@ruecker.fi>
	<20140512104021.GA23848@aporee.org>
Message-ID: <CAL0v=_69UmEYKrWqD_yw8JV1jxtb5VXJvt4dFXcNc+mGs8UDzw@mail.gmail.com>

On 12 May 2014 13:40, uno <un at dom.de> wrote:

> "Thomas B. R?cker":
> > > is there a way to authenticate a source dynamically, i.e. from a
> script/
>
> > Not only was it asked before, it was even implemented years ago. ;-)
> > It got first released in 2.3.3, but there was no proper documentation.
>
> oh my. i've to upgrade, using a debian 2.3.2 so far...
> looks just perfect, thanks!
>
>
2.3.3 is in backports
2.4.0 might appear in the near future in SID and later in backports as we
released last week.

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

From gany at fsmail.net  Wed May 21 22:51:44 2014
From: gany at fsmail.net (David Hendry)
Date: Thu, 22 May 2014 00:51:44 +0200
Subject: [Icecast] Icecast2, ezstream and reverse proxy
Message-ID: <15246737.20641400712704635.JavaMail.www@wwinf3715>

Hello
Ezstream is working well locally with Icecast2 on port 8000 on a Debian Wheezy platform. However, I use a reverse proxy (Pound) to pass all requests from the Internet for x.mysite.com to backend localhost:8000 i.e. my Icecast2 server. This works fine, i.e. x.mysite.com brings up the Icecast2 Status page. My problem is with the ezstream xml configuration <url></url> setting which must have a port number, and if I put <url>x.mysite.com:8000</url> icecast2 does not get the stream. If I use NAT on my router to bypass the reverse proxy, x.mysite.com:8000 goes straight to Icecast2 and everything works; but I don't want to do it this way. Do you have any ideas as to what I can do to get  ezstream working with icecast2 and my reverse proxy?

Thanks

David


From glaivy at yandex.com  Thu May 22 20:47:21 2014
From: glaivy at yandex.com (Guido Budack)
Date: Thu, 22 May 2014 22:47:21 +0200
Subject: [Icecast] Icecast 'client'
Message-ID: <537E6259.4010109@yandex.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi folks,

actually and once again quite busy I'd really appreciate a quick hint
or explanation...
Somehow I dont get it... :-/
Although I'll soon (as soon I have a more powerful server - actually a
friend of mine is hosting my site in a small cluster) install and use
the icecast-server for my streaming-purposes I don't understand how to
listen to the streams.
What kind of 'clients' do you use or recommend?
Please if possible give me some more options for linux and
windows-OS's because I use dual-OS-Systems.
Can't be true that it is necessary to use the 'concurrent' client
winamp to receive the Icecast-streams isn't it?


Visit my Site!
Feel free to contact me if you want to participate or contribute...



Greets


Gee



- -- 
Guido Budack
- - Designer -
Apache/ColdFusion Web-Server Administration
normalized, well scaled Database-design
Application-Programming in C++
Hardware one-off Productions
Flash/AS3, HTML/JScript
Intrusion-detection
Radio

Ward 4/757
Minglanilla/ Cebu
Philippines
Tel.: +41/76-756 9208
Tel.: +63/915-381 9544
www.pirate-radio.eu
www.adecco.ph

Skype: pirate-radio.eu
Dalnet: #pirate-radio.eu
Undernet: #pirate-radio.eu

Email: glaivy at yandex.com
Email: budack at bluewin.ch
Email: guido.budack at yahoo.de
Email: admin at pirate-radio.eu

We use Debian 6.0, UbuntuStudio 12
and a Snort IP-System on a
Quad-core dedicated Server

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.11 (GNU/Linux)
mQENBFMSzBEBCADLPBwdQ2vDYBNvoH50Z0eUjRHUVhzKzpgRT2rlgJ+inrwsP8w1
m6WzCgLFq7iljVp3FxEgTEV/K3Kh6I9Sk13tPx4bkhZ006R+We152eS+q7yiGwhJ
vwTecl1oAQ7ce+PGGng8TRw3evBO2kRs/qc5CuV7OfsBxwPU+OSjOaaBFp4O0F4b
CrWczQZEjShOvWePHXnLxqnY3y1o2JpjE+fnikXsbm9owTuMLyLy/b9ZfGBaRVa7
gyy2N1GPKti68esU5gMfnoCVCKqF6C+0wc+dJV0dPzW1Ps2t1uffZ8OjG/3QZRq/
oq0bO6+J30bCgYIh6XtgXxtcRb77Bjhw7VpxABEBAAG0H0d1aWRvIEJ1ZGFjayA8
Z2xhaXZ5QGdtYWlsLmNvbT6JATgEEwECACIFAlMSzBECGw8GCwkIBwMCBhUIAgkK
CwQWAgMBAh4BAheAAAoJEIxjGe3OdnLOM7UH/i46VPSPIufgPuKq8bb9YlbhoE1H
ThaBREJyUeCRYrq1crdaO0Sr5FHoN7VTmC7XQm2W+zPOKTttx5dDD3ywshzphHlC
SJlN/s7lePf230zR3DePa7UYwvO1cW2lclZ7VDnkmb8317SPOECDJcn0l8A6eScT
FoYhzkeVwlroQFz7W9R56Z8HbNXBPqIOS93WVyCGNiTqFI9tvs44jiOIv4rIINrI
V7RG8gXDOjhfwDOhpSVReV8Xf7Eki/s2/wQV8z3XfOpPsbu2hrYeu1esRg1bCjRP
KFBpqQIlByg1ulBR6nZtM8qWPD7p5wYxloc/wLG4NjhXEuOWNERGPQa0DKg=
=r1R3
- -----END PGP PUBLIC KEY BLOCK-----


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTfmJZAAoJEIxjGe3OdnLOKWIIALqaURN9kim50d1Os19T+5Og
OH3jZWQ/IvKxi+TcztV6cWhLEcLZojNVzNStithy2GTAUPZEs7CZzq7LyTtfQcad
fk37HOMWKuYTcP5McVpOX0x2Bb/Knw4OkDECWmJW/ptK+dPUDHYlk3KHAhBBJP7I
1h2vBAX85Q/z40wfKMkMPeLKpwf0/lEu91Z7u1rTFrAXGJDyzucGJ4YZmXIIhNjD
k8BYHLtZAD4SDHe5eozu1raNWxqgtQAacTGTiaYBjU110WN6SwjzrNSyXRT4veIK
ISe7fJRn6+tMLcLjFxXmqvFyWrcbqUKZmle2SH0SUJIL/jHtthYk6+OuquELoQ0=
=TOdc
-----END PGP SIGNATURE-----


From denis at smajlovic.dk  Thu May 22 21:49:58 2014
From: denis at smajlovic.dk (Denis Smajlovic)
Date: Thu, 22 May 2014 23:49:58 +0200
Subject: [Icecast] Icecast 'client'
In-Reply-To: <537E6259.4010109@yandex.com>
References: <537E6259.4010109@yandex.com>
Message-ID: <DDA6DBDE-BD1B-4801-BEE5-7777D475E483@smajlovic.dk>

Hi,

What is wrong with listening to the stream using HTTP on port 8000 on your server?

And what is wrong with using VLC?

/Denis :-)
On 22 May 2014, at 22:47, Guido Budack <glaivy at yandex.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi folks,
> 
> actually and once again quite busy I'd really appreciate a quick hint
> or explanation...
> Somehow I dont get it... :-/
> Although I'll soon (as soon I have a more powerful server - actually a
> friend of mine is hosting my site in a small cluster) install and use
> the icecast-server for my streaming-purposes I don't understand how to
> listen to the streams.
> What kind of 'clients' do you use or recommend?
> Please if possible give me some more options for linux and
> windows-OS's because I use dual-OS-Systems.
> Can't be true that it is necessary to use the 'concurrent' client
> winamp to receive the Icecast-streams isn't it?
> 
> 
> Visit my Site!
> Feel free to contact me if you want to participate or contribute...
> 
> 
> 
> Greets
> 
> 
> Gee
> 
> 
> 
> - -- 
> Guido Budack
> - - Designer -
> Apache/ColdFusion Web-Server Administration
> normalized, well scaled Database-design
> Application-Programming in C++
> Hardware one-off Productions
> Flash/AS3, HTML/JScript
> Intrusion-detection
> Radio
> 
> Ward 4/757
> Minglanilla/ Cebu
> Philippines
> Tel.: +41/76-756 9208
> Tel.: +63/915-381 9544
> www.pirate-radio.eu
> www.adecco.ph
> 
> Skype: pirate-radio.eu
> Dalnet: #pirate-radio.eu
> Undernet: #pirate-radio.eu
> 
> Email: glaivy at yandex.com
> Email: budack at bluewin.ch
> Email: guido.budack at yahoo.de
> Email: admin at pirate-radio.eu
> 
> We use Debian 6.0, UbuntuStudio 12
> and a Snort IP-System on a
> Quad-core dedicated Server
> 
> - -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> mQENBFMSzBEBCADLPBwdQ2vDYBNvoH50Z0eUjRHUVhzKzpgRT2rlgJ+inrwsP8w1
> m6WzCgLFq7iljVp3FxEgTEV/K3Kh6I9Sk13tPx4bkhZ006R+We152eS+q7yiGwhJ
> vwTecl1oAQ7ce+PGGng8TRw3evBO2kRs/qc5CuV7OfsBxwPU+OSjOaaBFp4O0F4b
> CrWczQZEjShOvWePHXnLxqnY3y1o2JpjE+fnikXsbm9owTuMLyLy/b9ZfGBaRVa7
> gyy2N1GPKti68esU5gMfnoCVCKqF6C+0wc+dJV0dPzW1Ps2t1uffZ8OjG/3QZRq/
> oq0bO6+J30bCgYIh6XtgXxtcRb77Bjhw7VpxABEBAAG0H0d1aWRvIEJ1ZGFjayA8
> Z2xhaXZ5QGdtYWlsLmNvbT6JATgEEwECACIFAlMSzBECGw8GCwkIBwMCBhUIAgkK
> CwQWAgMBAh4BAheAAAoJEIxjGe3OdnLOM7UH/i46VPSPIufgPuKq8bb9YlbhoE1H
> ThaBREJyUeCRYrq1crdaO0Sr5FHoN7VTmC7XQm2W+zPOKTttx5dDD3ywshzphHlC
> SJlN/s7lePf230zR3DePa7UYwvO1cW2lclZ7VDnkmb8317SPOECDJcn0l8A6eScT
> FoYhzkeVwlroQFz7W9R56Z8HbNXBPqIOS93WVyCGNiTqFI9tvs44jiOIv4rIINrI
> V7RG8gXDOjhfwDOhpSVReV8Xf7Eki/s2/wQV8z3XfOpPsbu2hrYeu1esRg1bCjRP
> KFBpqQIlByg1ulBR6nZtM8qWPD7p5wYxloc/wLG4NjhXEuOWNERGPQa0DKg=
> =r1R3
> - -----END PGP PUBLIC KEY BLOCK-----
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJTfmJZAAoJEIxjGe3OdnLOKWIIALqaURN9kim50d1Os19T+5Og
> OH3jZWQ/IvKxi+TcztV6cWhLEcLZojNVzNStithy2GTAUPZEs7CZzq7LyTtfQcad
> fk37HOMWKuYTcP5McVpOX0x2Bb/Knw4OkDECWmJW/ptK+dPUDHYlk3KHAhBBJP7I
> 1h2vBAX85Q/z40wfKMkMPeLKpwf0/lEu91Z7u1rTFrAXGJDyzucGJ4YZmXIIhNjD
> k8BYHLtZAD4SDHe5eozu1raNWxqgtQAacTGTiaYBjU110WN6SwjzrNSyXRT4veIK
> ISe7fJRn6+tMLcLjFxXmqvFyWrcbqUKZmle2SH0SUJIL/jHtthYk6+OuquELoQ0=
> =TOdc
> -----END PGP SIGNATURE-----
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast



From glaivy at yandex.com  Thu May 22 22:35:21 2014
From: glaivy at yandex.com (Guido Budack)
Date: Fri, 23 May 2014 00:35:21 +0200
Subject: [Icecast] Icecast 'client'
In-Reply-To: <DDA6DBDE-BD1B-4801-BEE5-7777D475E483@smajlovic.dk>
References: <537E6259.4010109@yandex.com>
	<DDA6DBDE-BD1B-4801-BEE5-7777D475E483@smajlovic.dk>
Message-ID: <537E7BA9.9000401@yandex.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I just mind that Icecast has its own client...
Have been surprised as I found out they there is no...
Strange...

Whatever...

Am 22.05.2014 23:49, schrieb Denis Smajlovic:
> Hi,
> 
> What is wrong with listening to the stream using HTTP on port 8000
> on your server?
> 
> And what is wrong with using VLC?
> 
> /Denis :-) On 22 May 2014, at 22:47, Guido Budack
> <glaivy at yandex.com> wrote:
> 
> Hi folks,
> 
> actually and once again quite busy I'd really appreciate a quick
> hint or explanation... Somehow I dont get it... :-/ Although I'll
> soon (as soon I have a more powerful server - actually a friend of
> mine is hosting my site in a small cluster) install and use the
> icecast-server for my streaming-purposes I don't understand how to 
> listen to the streams. What kind of 'clients' do you use or
> recommend? Please if possible give me some more options for linux
> and windows-OS's because I use dual-OS-Systems. Can't be true that
> it is necessary to use the 'concurrent' client winamp to receive
> the Icecast-streams isn't it?
> 
> 
> Visit my Site! Feel free to contact me if you want to participate
> or contribute...
> 
> 
> 
> Greets
> 
> 
> Gee
> 
> 
> 
>> _______________________________________________ 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
> 

- -- 
Guido Budack
- - Designer -
Apache/ColdFusion Web-Server Administration
normalized, well scaled Database-design
Application-Programming in C++
Hardware one-off Productions
Flash/AS3, HTML/JScript
Intrusion-detection
Radio

Ward 4/757
Minglanilla/ Cebu
Philippines
Tel.: +41/76-756 9208
Tel.: +63/915-381 9544
www.pirate-radio.eu
www.adecco.ph

Skype: pirate-radio.eu
Dalnet: #pirate-radio.eu
Undernet: #pirate-radio.eu

Email: glaivy at yandex.com
Email: budack at bluewin.ch
Email: guido.budack at yahoo.de
Email: admin at pirate-radio.eu

We use Debian 6.0, UbuntuStudio 12
and a Snort IP-System on a
Quad-core dedicated Server

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.11 (GNU/Linux)
mQENBFMSzBEBCADLPBwdQ2vDYBNvoH50Z0eUjRHUVhzKzpgRT2rlgJ+inrwsP8w1
m6WzCgLFq7iljVp3FxEgTEV/K3Kh6I9Sk13tPx4bkhZ006R+We152eS+q7yiGwhJ
vwTecl1oAQ7ce+PGGng8TRw3evBO2kRs/qc5CuV7OfsBxwPU+OSjOaaBFp4O0F4b
CrWczQZEjShOvWePHXnLxqnY3y1o2JpjE+fnikXsbm9owTuMLyLy/b9ZfGBaRVa7
gyy2N1GPKti68esU5gMfnoCVCKqF6C+0wc+dJV0dPzW1Ps2t1uffZ8OjG/3QZRq/
oq0bO6+J30bCgYIh6XtgXxtcRb77Bjhw7VpxABEBAAG0H0d1aWRvIEJ1ZGFjayA8
Z2xhaXZ5QGdtYWlsLmNvbT6JATgEEwECACIFAlMSzBECGw8GCwkIBwMCBhUIAgkK
CwQWAgMBAh4BAheAAAoJEIxjGe3OdnLOM7UH/i46VPSPIufgPuKq8bb9YlbhoE1H
ThaBREJyUeCRYrq1crdaO0Sr5FHoN7VTmC7XQm2W+zPOKTttx5dDD3ywshzphHlC
SJlN/s7lePf230zR3DePa7UYwvO1cW2lclZ7VDnkmb8317SPOECDJcn0l8A6eScT
FoYhzkeVwlroQFz7W9R56Z8HbNXBPqIOS93WVyCGNiTqFI9tvs44jiOIv4rIINrI
V7RG8gXDOjhfwDOhpSVReV8Xf7Eki/s2/wQV8z3XfOpPsbu2hrYeu1esRg1bCjRP
KFBpqQIlByg1ulBR6nZtM8qWPD7p5wYxloc/wLG4NjhXEuOWNERGPQa0DKg=
=r1R3
- -----END PGP PUBLIC KEY BLOCK-----


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTfnupAAoJEIxjGe3OdnLOC7YIAKMBGDsYw2gQM3k/3RYCH+/a
jxrOHjDjapi3MVHKi5+FgH1cB0vU7HxxpSeqt2jDk+xm6P77zYzBIng/2G/hXJTY
vY3waw9rjk6FbiKXVGzk8OcGWFRJJprdnUy4Pmg+8f9Ca0dTD5NS+Ue2p+YJXfyY
KAgXD4n6/J5Pdz9PSEPyqQAwTlgcJOp90cHDKwkl9e9Q8IgljQgP+zY0TwNHI8Kg
zcHM/G6w4iVpxs1fMc1JS+cQac3ak5cGC9vB55EtjCnI7iNovuICeQdYDicadFIm
tEsBQdqBwq0B03daKek0HbyeRyYWkUp3VT7a/vUdyVSckhADwlY4e6iEX/rIUg0=
=/YBm
-----END PGP SIGNATURE-----


From epicanis+icecast at dogphilosophy.net  Thu May 22 22:39:59 2014
From: epicanis+icecast at dogphilosophy.net (epicanis+icecast at dogphilosophy.net)
Date: Thu, 22 May 2014 18:39:59 -0400
Subject: [Icecast] Icecast 'client'
In-Reply-To: <537E6259.4010109@yandex.com>
References: <537E6259.4010109@yandex.com>
Message-ID: <1727271.yY0d0Nom7x@squirrel>

On Thursday, May 22, 2014 10:47:21 PM Guido Budack wrote:
> Hi folks,
> 
> actually and once again quite busy I'd really appreciate a quick hint
> or explanation...
> Somehow I dont get it... :-/
> Although I'll soon (as soon I have a more powerful server - actually a
> friend of mine is hosting my site in a small cluster) install and use
> the icecast-server for my streaming-purposes I don't understand how to
> listen to the streams.
> What kind of 'clients' do you use or recommend?
> Please if possible give me some more options for linux and
> windows-OS's because I use dual-OS-Systems.
> Can't be true that it is necessary to use the 'concurrent' client
> winamp to receive the Icecast-streams isn't it?

Mozilla Firefox and Chrom(ium|e) both handle all of the audio formats that
icecast will serve, including .opus - I know I have connected directly to my 
icecast feed and listened in Firefox.

Someone else mentioned VLC, which also works well for streams and is
also cross-platform. On the Linux side I think a large fraction (possibly
even a majority) of "media players" will handle streams from URLs. Certainly
anything based off of mplayer or ffmpeg ought to be able to, and I know
that amarok (and it's old-school sibling Clementine) do, among others.
I'm not sure about other Windows media players, but Amarok and Clementine
are both available for Windows as well.



From denis at smajlovic.dk  Fri May 23 06:00:26 2014
From: denis at smajlovic.dk (Denis Smajlovic)
Date: Fri, 23 May 2014 08:00:26 +0200
Subject: [Icecast] Icecast 'client'
In-Reply-To: <537E7BA9.9000401@yandex.com>
References: <537E6259.4010109@yandex.com>
	<DDA6DBDE-BD1B-4801-BEE5-7777D475E483@smajlovic.dk>
	<537E7BA9.9000401@yandex.com>
Message-ID: <3DD6EAE4-CE54-4E4F-ABC1-E2310AB90044@smajlovic.dk>

Hi,

Where do you see advantages of such a client? Everyone these days has a web browser, or even know how to setup their own player.



/Denis

> Den 23/05/2014 kl. 00.35 skrev Guido Budack <glaivy at yandex.com>:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I just mind that Icecast has its own client...
> Have been surprised as I found out they there is no...
> Strange...
> 
> Whatever...
> 
> Am 22.05.2014 23:49, schrieb Denis Smajlovic:
>> Hi,
>> 
>> What is wrong with listening to the stream using HTTP on port 8000
>> on your server?
>> 
>> And what is wrong with using VLC?
>> 
>> /Denis :-) On 22 May 2014, at 22:47, Guido Budack
>> <glaivy at yandex.com> wrote:
>> 
>> Hi folks,
>> 
>> actually and once again quite busy I'd really appreciate a quick
>> hint or explanation... Somehow I dont get it... :-/ Although I'll
>> soon (as soon I have a more powerful server - actually a friend of
>> mine is hosting my site in a small cluster) install and use the
>> icecast-server for my streaming-purposes I don't understand how to 
>> listen to the streams. What kind of 'clients' do you use or
>> recommend? Please if possible give me some more options for linux
>> and windows-OS's because I use dual-OS-Systems. Can't be true that
>> it is necessary to use the 'concurrent' client winamp to receive
>> the Icecast-streams isn't it?
>> 
>> 
>> Visit my Site! Feel free to contact me if you want to participate
>> or contribute...
>> 
>> 
>> 
>> Greets
>> 
>> 
>> Gee
>> 
>> 
>> 
>>> _______________________________________________ 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
> 
> - -- 
> Guido Budack
> - - Designer -
> Apache/ColdFusion Web-Server Administration
> normalized, well scaled Database-design
> Application-Programming in C++
> Hardware one-off Productions
> Flash/AS3, HTML/JScript
> Intrusion-detection
> Radio
> 
> Ward 4/757
> Minglanilla/ Cebu
> Philippines
> Tel.: +41/76-756 9208
> Tel.: +63/915-381 9544
> www.pirate-radio.eu
> www.adecco.ph
> 
> Skype: pirate-radio.eu
> Dalnet: #pirate-radio.eu
> Undernet: #pirate-radio.eu
> 
> Email: glaivy at yandex.com
> Email: budack at bluewin.ch
> Email: guido.budack at yahoo.de
> Email: admin at pirate-radio.eu
> 
> We use Debian 6.0, UbuntuStudio 12
> and a Snort IP-System on a
> Quad-core dedicated Server
> 
> - -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> mQENBFMSzBEBCADLPBwdQ2vDYBNvoH50Z0eUjRHUVhzKzpgRT2rlgJ+inrwsP8w1
> m6WzCgLFq7iljVp3FxEgTEV/K3Kh6I9Sk13tPx4bkhZ006R+We152eS+q7yiGwhJ
> vwTecl1oAQ7ce+PGGng8TRw3evBO2kRs/qc5CuV7OfsBxwPU+OSjOaaBFp4O0F4b
> CrWczQZEjShOvWePHXnLxqnY3y1o2JpjE+fnikXsbm9owTuMLyLy/b9ZfGBaRVa7
> gyy2N1GPKti68esU5gMfnoCVCKqF6C+0wc+dJV0dPzW1Ps2t1uffZ8OjG/3QZRq/
> oq0bO6+J30bCgYIh6XtgXxtcRb77Bjhw7VpxABEBAAG0H0d1aWRvIEJ1ZGFjayA8
> Z2xhaXZ5QGdtYWlsLmNvbT6JATgEEwECACIFAlMSzBECGw8GCwkIBwMCBhUIAgkK
> CwQWAgMBAh4BAheAAAoJEIxjGe3OdnLOM7UH/i46VPSPIufgPuKq8bb9YlbhoE1H
> ThaBREJyUeCRYrq1crdaO0Sr5FHoN7VTmC7XQm2W+zPOKTttx5dDD3ywshzphHlC
> SJlN/s7lePf230zR3DePa7UYwvO1cW2lclZ7VDnkmb8317SPOECDJcn0l8A6eScT
> FoYhzkeVwlroQFz7W9R56Z8HbNXBPqIOS93WVyCGNiTqFI9tvs44jiOIv4rIINrI
> V7RG8gXDOjhfwDOhpSVReV8Xf7Eki/s2/wQV8z3XfOpPsbu2hrYeu1esRg1bCjRP
> KFBpqQIlByg1ulBR6nZtM8qWPD7p5wYxloc/wLG4NjhXEuOWNERGPQa0DKg=
> =r1R3
> - -----END PGP PUBLIC KEY BLOCK-----
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJTfnupAAoJEIxjGe3OdnLOC7YIAKMBGDsYw2gQM3k/3RYCH+/a
> jxrOHjDjapi3MVHKi5+FgH1cB0vU7HxxpSeqt2jDk+xm6P77zYzBIng/2G/hXJTY
> vY3waw9rjk6FbiKXVGzk8OcGWFRJJprdnUy4Pmg+8f9Ca0dTD5NS+Ue2p+YJXfyY
> KAgXD4n6/J5Pdz9PSEPyqQAwTlgcJOp90cHDKwkl9e9Q8IgljQgP+zY0TwNHI8Kg
> zcHM/G6w4iVpxs1fMc1JS+cQac3ak5cGC9vB55EtjCnI7iNovuICeQdYDicadFIm
> tEsBQdqBwq0B03daKek0HbyeRyYWkUp3VT7a/vUdyVSckhADwlY4e6iEX/rIUg0=
> =/YBm
> -----END PGP SIGNATURE-----
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast


From denis at smajlovic.dk  Fri May 23 06:03:04 2014
From: denis at smajlovic.dk (Denis Smajlovic)
Date: Fri, 23 May 2014 08:03:04 +0200
Subject: [Icecast] Icecast 'client'
In-Reply-To: <537E7BA9.9000401@yandex.com>
References: <537E6259.4010109@yandex.com>
	<DDA6DBDE-BD1B-4801-BEE5-7777D475E483@smajlovic.dk>
	<537E7BA9.9000401@yandex.com>
Message-ID: <60EF3118-E309-4B42-9286-3AAF39815A54@smajlovic.dk>

Hi,

Do you see any advantages of such a client? Is there a reason why you think it would exist?

/Denis :-)

> Den 23/05/2014 kl. 00.35 skrev Guido Budack <glaivy at yandex.com>:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I just mind that Icecast has its own client...
> Have been surprised as I found out they there is no...
> Strange...
> 
> Whatever...
> 
> Am 22.05.2014 23:49, schrieb Denis Smajlovic:
>> Hi,
>> 
>> What is wrong with listening to the stream using HTTP on port 8000
>> on your server?
>> 
>> And what is wrong with using VLC?
>> 
>> /Denis :-) On 22 May 2014, at 22:47, Guido Budack
>> <glaivy at yandex.com> wrote:
>> 
>> Hi folks,
>> 
>> actually and once again quite busy I'd really appreciate a quick
>> hint or explanation... Somehow I dont get it... :-/ Although I'll
>> soon (as soon I have a more powerful server - actually a friend of
>> mine is hosting my site in a small cluster) install and use the
>> icecast-server for my streaming-purposes I don't understand how to 
>> listen to the streams. What kind of 'clients' do you use or
>> recommend? Please if possible give me some more options for linux
>> and windows-OS's because I use dual-OS-Systems. Can't be true that
>> it is necessary to use the 'concurrent' client winamp to receive
>> the Icecast-streams isn't it?
>> 
>> 
>> Visit my Site! Feel free to contact me if you want to participate
>> or contribute...
>> 
>> 
>> 
>> Greets
>> 
>> 
>> Gee
>> 
>> 
>> 
>>> _______________________________________________ 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
> 
> - -- 
> Guido Budack
> - - Designer -
> Apache/ColdFusion Web-Server Administration
> normalized, well scaled Database-design
> Application-Programming in C++
> Hardware one-off Productions
> Flash/AS3, HTML/JScript
> Intrusion-detection
> Radio
> 
> Ward 4/757
> Minglanilla/ Cebu
> Philippines
> Tel.: +41/76-756 9208
> Tel.: +63/915-381 9544
> www.pirate-radio.eu
> www.adecco.ph
> 
> Skype: pirate-radio.eu
> Dalnet: #pirate-radio.eu
> Undernet: #pirate-radio.eu
> 
> Email: glaivy at yandex.com
> Email: budack at bluewin.ch
> Email: guido.budack at yahoo.de
> Email: admin at pirate-radio.eu
> 
> We use Debian 6.0, UbuntuStudio 12
> and a Snort IP-System on a
> Quad-core dedicated Server
> 
> - -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> mQENBFMSzBEBCADLPBwdQ2vDYBNvoH50Z0eUjRHUVhzKzpgRT2rlgJ+inrwsP8w1
> m6WzCgLFq7iljVp3FxEgTEV/K3Kh6I9Sk13tPx4bkhZ006R+We152eS+q7yiGwhJ
> vwTecl1oAQ7ce+PGGng8TRw3evBO2kRs/qc5CuV7OfsBxwPU+OSjOaaBFp4O0F4b
> CrWczQZEjShOvWePHXnLxqnY3y1o2JpjE+fnikXsbm9owTuMLyLy/b9ZfGBaRVa7
> gyy2N1GPKti68esU5gMfnoCVCKqF6C+0wc+dJV0dPzW1Ps2t1uffZ8OjG/3QZRq/
> oq0bO6+J30bCgYIh6XtgXxtcRb77Bjhw7VpxABEBAAG0H0d1aWRvIEJ1ZGFjayA8
> Z2xhaXZ5QGdtYWlsLmNvbT6JATgEEwECACIFAlMSzBECGw8GCwkIBwMCBhUIAgkK
> CwQWAgMBAh4BAheAAAoJEIxjGe3OdnLOM7UH/i46VPSPIufgPuKq8bb9YlbhoE1H
> ThaBREJyUeCRYrq1crdaO0Sr5FHoN7VTmC7XQm2W+zPOKTttx5dDD3ywshzphHlC
> SJlN/s7lePf230zR3DePa7UYwvO1cW2lclZ7VDnkmb8317SPOECDJcn0l8A6eScT
> FoYhzkeVwlroQFz7W9R56Z8HbNXBPqIOS93WVyCGNiTqFI9tvs44jiOIv4rIINrI
> V7RG8gXDOjhfwDOhpSVReV8Xf7Eki/s2/wQV8z3XfOpPsbu2hrYeu1esRg1bCjRP
> KFBpqQIlByg1ulBR6nZtM8qWPD7p5wYxloc/wLG4NjhXEuOWNERGPQa0DKg=
> =r1R3
> - -----END PGP PUBLIC KEY BLOCK-----
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJTfnupAAoJEIxjGe3OdnLOC7YIAKMBGDsYw2gQM3k/3RYCH+/a
> jxrOHjDjapi3MVHKi5+FgH1cB0vU7HxxpSeqt2jDk+xm6P77zYzBIng/2G/hXJTY
> vY3waw9rjk6FbiKXVGzk8OcGWFRJJprdnUy4Pmg+8f9Ca0dTD5NS+Ue2p+YJXfyY
> KAgXD4n6/J5Pdz9PSEPyqQAwTlgcJOp90cHDKwkl9e9Q8IgljQgP+zY0TwNHI8Kg
> zcHM/G6w4iVpxs1fMc1JS+cQac3ak5cGC9vB55EtjCnI7iNovuICeQdYDicadFIm
> tEsBQdqBwq0B03daKek0HbyeRyYWkUp3VT7a/vUdyVSckhADwlY4e6iEX/rIUg0=
> =/YBm
> -----END PGP SIGNATURE-----
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast


From pumahosting at gmail.com  Fri May 23 06:03:39 2014
From: pumahosting at gmail.com (puma hoosting)
Date: Fri, 23 May 2014 08:03:39 +0200
Subject: [Icecast] Icecast 'client'
In-Reply-To: <537E6259.4010109@yandex.com>
References: <537E6259.4010109@yandex.com>
Message-ID: <CABTJJfmO3nUqcTOLpMofWJ7J46xg1QEx6FtzFxnCEa_R0UrkCw@mail.gmail.com>

Hey.
I recommend you to listen it with Winamp.


2014-05-22 22:47 GMT+02:00 Guido Budack <glaivy at yandex.com>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi folks,
>
> actually and once again quite busy I'd really appreciate a quick hint
> or explanation...
> Somehow I dont get it... :-/
> Although I'll soon (as soon I have a more powerful server - actually a
> friend of mine is hosting my site in a small cluster) install and use
> the icecast-server for my streaming-purposes I don't understand how to
> listen to the streams.
> What kind of 'clients' do you use or recommend?
> Please if possible give me some more options for linux and
> windows-OS's because I use dual-OS-Systems.
> Can't be true that it is necessary to use the 'concurrent' client
> winamp to receive the Icecast-streams isn't it?
>
>
> Visit my Site!
> Feel free to contact me if you want to participate or contribute...
>
>
>
> Greets
>
>
> Gee
>
>
>
> - --
> Guido Budack
> - - Designer -
> Apache/ColdFusion Web-Server Administration
> normalized, well scaled Database-design
> Application-Programming in C++
> Hardware one-off Productions
> Flash/AS3, HTML/JScript
> Intrusion-detection
> Radio
>
> Ward 4/757
> Minglanilla/ Cebu
> Philippines
> Tel.: +41/76-756 9208
> Tel.: +63/915-381 9544
> www.pirate-radio.eu
> www.adecco.ph
>
> Skype: pirate-radio.eu
> Dalnet: #pirate-radio.eu
> Undernet: #pirate-radio.eu
>
> Email: glaivy at yandex.com
> Email: budack at bluewin.ch
> Email: guido.budack at yahoo.de
> Email: admin at pirate-radio.eu
>
> We use Debian 6.0, UbuntuStudio 12
> and a Snort IP-System on a
> Quad-core dedicated Server
>
> - -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> mQENBFMSzBEBCADLPBwdQ2vDYBNvoH50Z0eUjRHUVhzKzpgRT2rlgJ+inrwsP8w1
> m6WzCgLFq7iljVp3FxEgTEV/K3Kh6I9Sk13tPx4bkhZ006R+We152eS+q7yiGwhJ
> vwTecl1oAQ7ce+PGGng8TRw3evBO2kRs/qc5CuV7OfsBxwPU+OSjOaaBFp4O0F4b
> CrWczQZEjShOvWePHXnLxqnY3y1o2JpjE+fnikXsbm9owTuMLyLy/b9ZfGBaRVa7
> gyy2N1GPKti68esU5gMfnoCVCKqF6C+0wc+dJV0dPzW1Ps2t1uffZ8OjG/3QZRq/
> oq0bO6+J30bCgYIh6XtgXxtcRb77Bjhw7VpxABEBAAG0H0d1aWRvIEJ1ZGFjayA8
> Z2xhaXZ5QGdtYWlsLmNvbT6JATgEEwECACIFAlMSzBECGw8GCwkIBwMCBhUIAgkK
> CwQWAgMBAh4BAheAAAoJEIxjGe3OdnLOM7UH/i46VPSPIufgPuKq8bb9YlbhoE1H
> ThaBREJyUeCRYrq1crdaO0Sr5FHoN7VTmC7XQm2W+zPOKTttx5dDD3ywshzphHlC
> SJlN/s7lePf230zR3DePa7UYwvO1cW2lclZ7VDnkmb8317SPOECDJcn0l8A6eScT
> FoYhzkeVwlroQFz7W9R56Z8HbNXBPqIOS93WVyCGNiTqFI9tvs44jiOIv4rIINrI
> V7RG8gXDOjhfwDOhpSVReV8Xf7Eki/s2/wQV8z3XfOpPsbu2hrYeu1esRg1bCjRP
> KFBpqQIlByg1ulBR6nZtM8qWPD7p5wYxloc/wLG4NjhXEuOWNERGPQa0DKg=
> =r1R3
> - -----END PGP PUBLIC KEY BLOCK-----
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTfmJZAAoJEIxjGe3OdnLOKWIIALqaURN9kim50d1Os19T+5Og
> OH3jZWQ/IvKxi+TcztV6cWhLEcLZojNVzNStithy2GTAUPZEs7CZzq7LyTtfQcad
> fk37HOMWKuYTcP5McVpOX0x2Bb/Knw4OkDECWmJW/ptK+dPUDHYlk3KHAhBBJP7I
> 1h2vBAX85Q/z40wfKMkMPeLKpwf0/lEu91Z7u1rTFrAXGJDyzucGJ4YZmXIIhNjD
> k8BYHLtZAD4SDHe5eozu1raNWxqgtQAacTGTiaYBjU110WN6SwjzrNSyXRT4veIK
> ISe7fJRn6+tMLcLjFxXmqvFyWrcbqUKZmle2SH0SUJIL/jHtthYk6+OuquELoQ0=
> =TOdc
> -----END PGP SIGNATURE-----
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>



-- 
?dv?zlettel,
Mayer Gell?rt Levente
?gyvezet? igazgat?!
Puma-Hosting
Momn? Bt.
Hungary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20140523/dad8f644/attachment.htm>

From denis at smajlovic.dk  Fri May 23 06:05:42 2014
From: denis at smajlovic.dk (Denis Smajlovic)
Date: Fri, 23 May 2014 08:05:42 +0200
Subject: [Icecast] Icecast 'client'
In-Reply-To: <60EF3118-E309-4B42-9286-3AAF39815A54@smajlovic.dk>
References: <537E6259.4010109@yandex.com>
	<DDA6DBDE-BD1B-4801-BEE5-7777D475E483@smajlovic.dk>
	<537E7BA9.9000401@yandex.com>
	<60EF3118-E309-4B42-9286-3AAF39815A54@smajlovic.dk>
Message-ID: <482A3933-3A9A-4F76-A2BD-667FEA614B6E@smajlovic.dk>

Sorry for double posting. My client was weird.

/Denis

> Den 23/05/2014 kl. 08.03 skrev Denis Smajlovic <denis at smajlovic.dk>:
> 
> Hi,
> 
> Do you see any advantages of such a client? Is there a reason why you think it would exist?
> 
> /Denis :-)
> 
>> Den 23/05/2014 kl. 00.35 skrev Guido Budack <glaivy at yandex.com>:
>> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> I just mind that Icecast has its own client...
>> Have been surprised as I found out they there is no...
>> Strange...
>> 
>> Whatever...
>> 
>> Am 22.05.2014 23:49, schrieb Denis Smajlovic:
>>> Hi,
>>> 
>>> What is wrong with listening to the stream using HTTP on port 8000
>>> on your server?
>>> 
>>> And what is wrong with using VLC?
>>> 
>>> /Denis :-) On 22 May 2014, at 22:47, Guido Budack
>>> <glaivy at yandex.com> wrote:
>>> 
>>> Hi folks,
>>> 
>>> actually and once again quite busy I'd really appreciate a quick
>>> hint or explanation... Somehow I dont get it... :-/ Although I'll
>>> soon (as soon I have a more powerful server - actually a friend of
>>> mine is hosting my site in a small cluster) install and use the
>>> icecast-server for my streaming-purposes I don't understand how to 
>>> listen to the streams. What kind of 'clients' do you use or
>>> recommend? Please if possible give me some more options for linux
>>> and windows-OS's because I use dual-OS-Systems. Can't be true that
>>> it is necessary to use the 'concurrent' client winamp to receive
>>> the Icecast-streams isn't it?
>>> 
>>> 
>>> Visit my Site! Feel free to contact me if you want to participate
>>> or contribute...
>>> 
>>> 
>>> 
>>> Greets
>>> 
>>> 
>>> Gee
>>> 
>>> 
>>> 
>>>> _______________________________________________ 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
>> 
>> - -- 
>> Guido Budack
>> - - Designer -
>> Apache/ColdFusion Web-Server Administration
>> normalized, well scaled Database-design
>> Application-Programming in C++
>> Hardware one-off Productions
>> Flash/AS3, HTML/JScript
>> Intrusion-detection
>> Radio
>> 
>> Ward 4/757
>> Minglanilla/ Cebu
>> Philippines
>> Tel.: +41/76-756 9208
>> Tel.: +63/915-381 9544
>> www.pirate-radio.eu
>> www.adecco.ph
>> 
>> Skype: pirate-radio.eu
>> Dalnet: #pirate-radio.eu
>> Undernet: #pirate-radio.eu
>> 
>> Email: glaivy at yandex.com
>> Email: budack at bluewin.ch
>> Email: guido.budack at yahoo.de
>> Email: admin at pirate-radio.eu
>> 
>> We use Debian 6.0, UbuntuStudio 12
>> and a Snort IP-System on a
>> Quad-core dedicated Server
>> 
>> - -----BEGIN PGP PUBLIC KEY BLOCK-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>> mQENBFMSzBEBCADLPBwdQ2vDYBNvoH50Z0eUjRHUVhzKzpgRT2rlgJ+inrwsP8w1
>> m6WzCgLFq7iljVp3FxEgTEV/K3Kh6I9Sk13tPx4bkhZ006R+We152eS+q7yiGwhJ
>> vwTecl1oAQ7ce+PGGng8TRw3evBO2kRs/qc5CuV7OfsBxwPU+OSjOaaBFp4O0F4b
>> CrWczQZEjShOvWePHXnLxqnY3y1o2JpjE+fnikXsbm9owTuMLyLy/b9ZfGBaRVa7
>> gyy2N1GPKti68esU5gMfnoCVCKqF6C+0wc+dJV0dPzW1Ps2t1uffZ8OjG/3QZRq/
>> oq0bO6+J30bCgYIh6XtgXxtcRb77Bjhw7VpxABEBAAG0H0d1aWRvIEJ1ZGFjayA8
>> Z2xhaXZ5QGdtYWlsLmNvbT6JATgEEwECACIFAlMSzBECGw8GCwkIBwMCBhUIAgkK
>> CwQWAgMBAh4BAheAAAoJEIxjGe3OdnLOM7UH/i46VPSPIufgPuKq8bb9YlbhoE1H
>> ThaBREJyUeCRYrq1crdaO0Sr5FHoN7VTmC7XQm2W+zPOKTttx5dDD3ywshzphHlC
>> SJlN/s7lePf230zR3DePa7UYwvO1cW2lclZ7VDnkmb8317SPOECDJcn0l8A6eScT
>> FoYhzkeVwlroQFz7W9R56Z8HbNXBPqIOS93WVyCGNiTqFI9tvs44jiOIv4rIINrI
>> V7RG8gXDOjhfwDOhpSVReV8Xf7Eki/s2/wQV8z3XfOpPsbu2hrYeu1esRg1bCjRP
>> KFBpqQIlByg1ulBR6nZtM8qWPD7p5wYxloc/wLG4NjhXEuOWNERGPQa0DKg=
>> =r1R3
>> - -----END PGP PUBLIC KEY BLOCK-----
>> 
>> 
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.22 (MingW32)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>> 
>> iQEcBAEBAgAGBQJTfnupAAoJEIxjGe3OdnLOC7YIAKMBGDsYw2gQM3k/3RYCH+/a
>> jxrOHjDjapi3MVHKi5+FgH1cB0vU7HxxpSeqt2jDk+xm6P77zYzBIng/2G/hXJTY
>> vY3waw9rjk6FbiKXVGzk8OcGWFRJJprdnUy4Pmg+8f9Ca0dTD5NS+Ue2p+YJXfyY
>> KAgXD4n6/J5Pdz9PSEPyqQAwTlgcJOp90cHDKwkl9e9Q8IgljQgP+zY0TwNHI8Kg
>> zcHM/G6w4iVpxs1fMc1JS+cQac3ak5cGC9vB55EtjCnI7iNovuICeQdYDicadFIm
>> tEsBQdqBwq0B03daKek0HbyeRyYWkUp3VT7a/vUdyVSckhADwlY4e6iEX/rIUg0=
>> =/YBm
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast


From thomas at ruecker.fi  Fri May 23 08:59:36 2014
From: thomas at ruecker.fi (=?ISO-8859-1?Q?=22Thomas_B=2E_R=FCcker=22?=)
Date: Fri, 23 May 2014 08:59:36 +0000
Subject: [Icecast] Icecast2, ezstream and reverse proxy
In-Reply-To: <15246737.20641400712704635.JavaMail.www@wwinf3715>
References: <15246737.20641400712704635.JavaMail.www@wwinf3715>
Message-ID: <537F0DF8.1020407@ruecker.fi>

On 05/21/2014 10:51 PM, David Hendry wrote:
> Ezstream is working well locally with Icecast2 on port 8000 on a Debian Wheezy platform. However, I use a reverse proxy (Pound) to pass all requests from the Internet for x.mysite.com to backend localhost:8000 i.e. my Icecast2 server.

The short answer is: don't put Icecast behind a reverse proxy.

>  This works fine, i.e. x.mysite.com brings up the Icecast2 Status page. My problem is with the ezstream xml configuration <url></url> setting which must have a port number, and if I put <url>x.mysite.com:8000</url> icecast2 does not get the stream. If I use NAT on my router to bypass the reverse proxy, x.mysite.com:8000 goes straight to Icecast2 and everything works; but I don't want to do it this way. Do you have any ideas as to what I can do to get  ezstream working with icecast2 and my reverse proxy?

You are trying to put non-HTTP traffic through a HTTP reverse proxy, I'm
not the least surprised that this fails.
There /might/ be a slim chance to get things working better if you
switch to Icecast 2.4.0 AND use a source client that uses PUT instead of
SOURCE. But only if the reverse proxy supports PUT.

Your reverse proxy might still have problems with the long-lived TCP
connections and other things specific to Icecast.

Cheers

Thomas


From hoggins at radiom.fr  Fri May 23 09:34:12 2014
From: hoggins at radiom.fr (Hoggins!)
Date: Fri, 23 May 2014 11:34:12 +0200
Subject: [Icecast] Icecast2, ezstream and reverse proxy
In-Reply-To: <537F0DF8.1020407@ruecker.fi>
References: <15246737.20641400712704635.JavaMail.www@wwinf3715>
	<537F0DF8.1020407@ruecker.fi>
Message-ID: <537F1614.2010409@radiom.fr>

Hello,

Correct me if I'm wrong, but what you get from Icecast *is* HTTP.
Anyway, we use proxying because on our server, some of our clients
cannot connect to port 8000 without bypassing their company firewall,
and we don't have the possibility to add another public IP. So with
Apache, here is what we do :

########################################################################
#
# VirtualHost for live.radiom.fr proxying on port 80
#
########################################################################
<VirtualHost [::]:80>
        CustomLog /var/log/httpd/sites/radiom.fr/stream_access.log combined
        ErrorLog /var/log/httpd/sites/radiom.fr/stream_error.log
        ServerName live.radiom.fr
        SetEnv downgrade-1.0 1
        SetEnv force-response-1.0 1
        ProxyRequests Off
        ProxyPass / http://localhost:8800/
        ProxyPassReverse / http://localhost:8800/
        ExtFilterDefine fixplaylistport mode=output cmd="/usr/bin/sed -e
's/localhost:8800/live.radiom.fr/g' -e
's/live.radiom.fr:8800/live.radiom.fr/g'"
        <Location />
                Order allow,deny
                Allow from all
                ExtFilterOptions LogStdErr Onfail=remove
                SetOutputFilter fixplaylistport
        </Location>
</VirtualHost>

And it works like a charm, and allows us to benefit from the HTTP 1.1
"Host" header, and use it in a virtual host.
The filter simply rewrites the listening URL served by the Icecast pages
to routable addresses and routable ports.

I would agree this is not the most elegant way to do, but we don't have
a choice here.

Cheers !

Le 23/05/2014 10:59, "Thomas B. R?cker" a ?crit :
> On 05/21/2014 10:51 PM, David Hendry wrote:
>> Ezstream is working well locally with Icecast2 on port 8000 on a Debian Wheezy platform. However, I use a reverse proxy (Pound) to pass all requests from the Internet for x.mysite.com to backend localhost:8000 i.e. my Icecast2 server.
> The short answer is: don't put Icecast behind a reverse proxy.
>
>>  This works fine, i.e. x.mysite.com brings up the Icecast2 Status page. My problem is with the ezstream xml configuration <url></url> setting which must have a port number, and if I put <url>x.mysite.com:8000</url> icecast2 does not get the stream. If I use NAT on my router to bypass the reverse proxy, x.mysite.com:8000 goes straight to Icecast2 and everything works; but I don't want to do it this way. Do you have any ideas as to what I can do to get  ezstream working with icecast2 and my reverse proxy?
> You are trying to put non-HTTP traffic through a HTTP reverse proxy, I'm
> not the least surprised that this fails.
> There /might/ be a slim chance to get things working better if you
> switch to Icecast 2.4.0 AND use a source client that uses PUT instead of
> SOURCE. But only if the reverse proxy supports PUT.
>
> Your reverse proxy might still have problems with the long-lived TCP
> connections and other things specific to Icecast.
>
> Cheers
>
> Thomas
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>



From thomas at ruecker.fi  Fri May 23 10:44:12 2014
From: thomas at ruecker.fi (=?ISO-8859-1?Q?=22Thomas_B=2E_R=FCcker=22?=)
Date: Fri, 23 May 2014 10:44:12 +0000
Subject: [Icecast] Icecast2, ezstream and reverse proxy
In-Reply-To: <537F1614.2010409@radiom.fr>
References: <15246737.20641400712704635.JavaMail.www@wwinf3715>	<537F0DF8.1020407@ruecker.fi>
	<537F1614.2010409@radiom.fr>
Message-ID: <537F267C.4020407@ruecker.fi>

Hi,

On 05/23/2014 09:34 AM, Hoggins! wrote:
> Hello,
>
> Correct me if I'm wrong, but what you get from Icecast *is* HTTP.

For a listener, Icecast is just an ordinary HTTP 1.0 server.
For a source client Icecast used to be a non-standard extension and used
the SOURCE method. We've deprecated this in 2.4.0 and now support PUT.
He's trying to connect a source through a reverse proxy.

> Anyway, we use proxying because on our server, some of our clients
> cannot connect to port 8000 without bypassing their company firewall,
The preferred method here is to make icecast bind to port 80.

> and we don't have the possibility to add another public IP.

That sucks, but is not an Icecast problem, dirty workarounds ensue.

>  So with
> Apache, here is what we do :
<snip />
Make sure you have a _high_ number of MaxClients or your Apache will
throw a fit after the first few listeners connect and not serve your
websites anymore.
Also Apache is not that great at handling many long-lived connections.
If you really know how to set up an high performance reverse proxy, you
won't have to ask how to handle Icecast, everyone else should really
avoid this kind of setup.

> And it works like a charm, and allows us to benefit from the HTTP 1.1
> "Host" header, and use it in a virtual host.
> The filter simply rewrites the listening URL served by the Icecast pages
> to routable addresses and routable ports.

It will break some features of the web interface, unless you start
messing with the replies on the fly.
Also your Icecast logs will be mostly worthless.

> I would agree this is not the most elegant way to do, but we don't have
> a choice here.

You have a choice, but decided to accept the trade-off. You always have
a choice.


Cheers

Thomas

>
> Cheers !
>
> Le 23/05/2014 10:59, "Thomas B. R?cker" a ?crit :
>> On 05/21/2014 10:51 PM, David Hendry wrote:
>>> Ezstream is working well locally with Icecast2 on port 8000 on a Debian Wheezy platform. However, I use a reverse proxy (Pound) to pass all requests from the Internet for x.mysite.com to backend localhost:8000 i.e. my Icecast2 server.
>> The short answer is: don't put Icecast behind a reverse proxy.
>>
>>>  This works fine, i.e. x.mysite.com brings up the Icecast2 Status page. My problem is with the ezstream xml configuration <url></url> setting which must have a port number, and if I put <url>x.mysite.com:8000</url> icecast2 does not get the stream. If I use NAT on my router to bypass the reverse proxy, x.mysite.com:8000 goes straight to Icecast2 and everything works; but I don't want to do it this way. Do you have any ideas as to what I can do to get  ezstream working with icecast2 and my reverse proxy?
>> You are trying to put non-HTTP traffic through a HTTP reverse proxy, I'm
>> not the least surprised that this fails.
>> There /might/ be a slim chance to get things working better if you
>> switch to Icecast 2.4.0 AND use a source client that uses PUT instead of
>> SOURCE. But only if the reverse proxy supports PUT.
>>
>> Your reverse proxy might still have problems with the long-lived TCP
>> connections and other things specific to Icecast.
>>
>> Cheers
>>
>> Thomas
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
>>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>



From rafaelgomes at quijaua.com.br  Fri May 23 10:58:33 2014
From: rafaelgomes at quijaua.com.br (Rafael Gomes)
Date: Fri, 23 May 2014 07:58:33 -0300
Subject: [Icecast] Icecast2, ezstream and reverse proxy
In-Reply-To: <537F267C.4020407@ruecker.fi>
References: " <15246737.20641400712704635.JavaMail.www@wwinf3715>"
	<537F0DF8.1020407@ruecker.fi> <537F1614.2010409@radiom.fr>
	<537F267C.4020407@ruecker.fi>
Message-ID: <2b634c47cf47b3b21114a81f63d9ccbc@quijaua.com.br>

Hi,

I use a rule in iptables and solves

iptables -A PREROUTING -t nat -p tcp -d 192.168.2.32 --dport 80 -j 
REDIRECT --to-port 8000
iptables-save > /etc/iptables.up.rules
echo 'pre-up iptables-restore < /etc/iptables.up.rules' >> 
/etc/network/interfaces

Regards,
Rafael Gomes


Em 2014-05-23 07:44, Thomas B. R?cker escreveu:
> Hi,
> 
> On 05/23/2014 09:34 AM, Hoggins! wrote:
>> Hello,
>> 
>> Correct me if I'm wrong, but what you get from Icecast *is* HTTP.
> 
> For a listener, Icecast is just an ordinary HTTP 1.0 server.
> For a source client Icecast used to be a non-standard extension and 
> used
> the SOURCE method. We've deprecated this in 2.4.0 and now support PUT.
> He's trying to connect a source through a reverse proxy.
> 
>> Anyway, we use proxying because on our server, some of our clients
>> cannot connect to port 8000 without bypassing their company firewall,
> The preferred method here is to make icecast bind to port 80.
> 
>> and we don't have the possibility to add another public IP.
> 
> That sucks, but is not an Icecast problem, dirty workarounds ensue.
> 
>>  So with
>> Apache, here is what we do :
> <snip />
> Make sure you have a _high_ number of MaxClients or your Apache will
> throw a fit after the first few listeners connect and not serve your
> websites anymore.
> Also Apache is not that great at handling many long-lived connections.
> If you really know how to set up an high performance reverse proxy, you
> won't have to ask how to handle Icecast, everyone else should really
> avoid this kind of setup.
> 
>> And it works like a charm, and allows us to benefit from the HTTP 1.1
>> "Host" header, and use it in a virtual host.
>> The filter simply rewrites the listening URL served by the Icecast 
>> pages
>> to routable addresses and routable ports.
> 
> It will break some features of the web interface, unless you start
> messing with the replies on the fly.
> Also your Icecast logs will be mostly worthless.
> 
>> I would agree this is not the most elegant way to do, but we don't 
>> have
>> a choice here.
> 
> You have a choice, but decided to accept the trade-off. You always have
> a choice.
> 
> 
> Cheers
> 
> Thomas
> 
>> 
>> Cheers !
>> 
>> Le 23/05/2014 10:59, "Thomas B. R?cker" a ?crit :
>>> On 05/21/2014 10:51 PM, David Hendry wrote:
>>>> Ezstream is working well locally with Icecast2 on port 8000 on a 
>>>> Debian Wheezy platform. However, I use a reverse proxy (Pound) to 
>>>> pass all requests from the Internet for x.mysite.com to backend 
>>>> localhost:8000 i.e. my Icecast2 server.
>>> The short answer is: don't put Icecast behind a reverse proxy.
>>> 
>>>>  This works fine, i.e. x.mysite.com brings up the Icecast2 Status 
>>>> page. My problem is with the ezstream xml configuration <url></url> 
>>>> setting which must have a port number, and if I put 
>>>> <url>x.mysite.com:8000</url> icecast2 does not get the stream. If I 
>>>> use NAT on my router to bypass the reverse proxy, x.mysite.com:8000 
>>>> goes straight to Icecast2 and everything works; but I don't want to 
>>>> do it this way. Do you have any ideas as to what I can do to get  
>>>> ezstream working with icecast2 and my reverse proxy?
>>> You are trying to put non-HTTP traffic through a HTTP reverse proxy, 
>>> I'm
>>> not the least surprised that this fails.
>>> There /might/ be a slim chance to get things working better if you
>>> switch to Icecast 2.4.0 AND use a source client that uses PUT instead 
>>> of
>>> SOURCE. But only if the reverse proxy supports PUT.
>>> 
>>> Your reverse proxy might still have problems with the long-lived TCP
>>> connections and other things specific to Icecast.
>>> 
>>> Cheers
>>> 
>>> Thomas
>>> _______________________________________________
>>> 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


From thomas at ruecker.fi  Fri May 23 11:30:37 2014
From: thomas at ruecker.fi (=?UTF-8?B?IlRob21hcyBCLiBSw7xja2VyIg==?=)
Date: Fri, 23 May 2014 11:30:37 +0000
Subject: [Icecast] Icecast2, ezstream and reverse proxy
In-Reply-To: <2b634c47cf47b3b21114a81f63d9ccbc@quijaua.com.br>
References: "
	<15246737.20641400712704635.JavaMail.www@wwinf3715>"	<537F0DF8.1020407@ruecker.fi>
	<537F1614.2010409@radiom.fr>	<537F267C.4020407@ruecker.fi>
	<2b634c47cf47b3b21114a81f63d9ccbc@quijaua.com.br>
Message-ID: <537F315D.6020103@ruecker.fi>

Hi,

On 05/23/2014 10:58 AM, Rafael Gomes wrote:
> I use a rule in iptables and solves
>
> iptables -A PREROUTING -t nat -p tcp -d 192.168.2.32 --dport 80 -j 
> REDIRECT --to-port 8000
> iptables-save > /etc/iptables.up.rules
> echo 'pre-up iptables-restore < /etc/iptables.up.rules' >> 
> /etc/network/interfaces

That is also an unnecessary and problem prone workaround.

Icecast can listen directly to port 80:
- Configure it to listen to port 80 and whatever other ports (e.g. 443
if you use SSL)
- Configure <changeowner> to switch to the proper user AND group
- Start icecast as root

Or configure your OS to allow binding to ports below 1024 by UID!=0

Thomas

> Em 2014-05-23 07:44, Thomas B. R?cker escreveu:
>> Hi,
>>
>> On 05/23/2014 09:34 AM, Hoggins! wrote:
>>> Hello,
>>>
>>> Correct me if I'm wrong, but what you get from Icecast *is* HTTP.
>> For a listener, Icecast is just an ordinary HTTP 1.0 server.
>> For a source client Icecast used to be a non-standard extension and 
>> used
>> the SOURCE method. We've deprecated this in 2.4.0 and now support PUT.
>> He's trying to connect a source through a reverse proxy.
>>
>>> Anyway, we use proxying because on our server, some of our clients
>>> cannot connect to port 8000 without bypassing their company firewall,
>> The preferred method here is to make icecast bind to port 80.
>>
>>> and we don't have the possibility to add another public IP.
>> That sucks, but is not an Icecast problem, dirty workarounds ensue.
>>
>>>  So with
>>> Apache, here is what we do :
>> <snip />
>> Make sure you have a _high_ number of MaxClients or your Apache will
>> throw a fit after the first few listeners connect and not serve your
>> websites anymore.
>> Also Apache is not that great at handling many long-lived connections.
>> If you really know how to set up an high performance reverse proxy, you
>> won't have to ask how to handle Icecast, everyone else should really
>> avoid this kind of setup.
>>
>>> And it works like a charm, and allows us to benefit from the HTTP 1.1
>>> "Host" header, and use it in a virtual host.
>>> The filter simply rewrites the listening URL served by the Icecast 
>>> pages
>>> to routable addresses and routable ports.
>> It will break some features of the web interface, unless you start
>> messing with the replies on the fly.
>> Also your Icecast logs will be mostly worthless.
>>
>>> I would agree this is not the most elegant way to do, but we don't 
>>> have
>>> a choice here.
>> You have a choice, but decided to accept the trade-off. You always have
>> a choice.
>>
>>
>> Cheers
>>
>> Thomas
>>
>>> Cheers !
>>>
>>> Le 23/05/2014 10:59, "Thomas B. R?cker" a ?crit :
>>>> On 05/21/2014 10:51 PM, David Hendry wrote:
>>>>> Ezstream is working well locally with Icecast2 on port 8000 on a 
>>>>> Debian Wheezy platform. However, I use a reverse proxy (Pound) to 
>>>>> pass all requests from the Internet for x.mysite.com to backend 
>>>>> localhost:8000 i.e. my Icecast2 server.
>>>> The short answer is: don't put Icecast behind a reverse proxy.
>>>>
>>>>>  This works fine, i.e. x.mysite.com brings up the Icecast2 Status 
>>>>> page. My problem is with the ezstream xml configuration <url></url> 
>>>>> setting which must have a port number, and if I put 
>>>>> <url>x.mysite.com:8000</url> icecast2 does not get the stream. If I 
>>>>> use NAT on my router to bypass the reverse proxy, x.mysite.com:8000 
>>>>> goes straight to Icecast2 and everything works; but I don't want to 
>>>>> do it this way. Do you have any ideas as to what I can do to get  
>>>>> ezstream working with icecast2 and my reverse proxy?
>>>> You are trying to put non-HTTP traffic through a HTTP reverse proxy, 
>>>> I'm
>>>> not the least surprised that this fails.
>>>> There /might/ be a slim chance to get things working better if you
>>>> switch to Icecast 2.4.0 AND use a source client that uses PUT instead 
>>>> of
>>>> SOURCE. But only if the reverse proxy supports PUT.
>>>>
>>>> Your reverse proxy might still have problems with the long-lived TCP
>>>> connections and other things specific to Icecast.
>>>>



From hoggins at radiom.fr  Fri May 23 11:49:20 2014
From: hoggins at radiom.fr (Hoggins!)
Date: Fri, 23 May 2014 13:49:20 +0200
Subject: [Icecast] Icecast2, ezstream and reverse proxy
In-Reply-To: <537F267C.4020407@ruecker.fi>
References: <15246737.20641400712704635.JavaMail.www@wwinf3715>	<537F0DF8.1020407@ruecker.fi>	<537F1614.2010409@radiom.fr>
	<537F267C.4020407@ruecker.fi>
Message-ID: <537F35C0.8080208@radiom.fr>


Le 23/05/2014 12:44, "Thomas B. R?cker" a ?crit :
> Hi,
>
> On 05/23/2014 09:34 AM, Hoggins! wrote:
>> Hello,
>>
>> Correct me if I'm wrong, but what you get from Icecast *is* HTTP.
> For a listener, Icecast is just an ordinary HTTP 1.0 server.
> For a source client Icecast used to be a non-standard extension and used
> the SOURCE method. We've deprecated this in 2.4.0 and now support PUT.
> He's trying to connect a source through a reverse proxy.
Sorry, my bad. I should read posts more carefully.
>
>> Anyway, we use proxying because on our server, some of our clients
>> cannot connect to port 8000 without bypassing their company firewall,
> The preferred method here is to make icecast bind to port 80.
Of course. It's just that this server already has a service on port 80.
>
>> and we don't have the possibility to add another public IP.
> That sucks, but is not an Icecast problem, dirty workarounds ensue.
It's true. I never said it was an Icecast problem. This is just a recipe
for a dirty workaround.
>
>>  So with
>> Apache, here is what we do :
> <snip />
> Make sure you have a _high_ number of MaxClients or your Apache will
> throw a fit after the first few listeners connect and not serve your
> websites anymore.
> Also Apache is not that great at handling many long-lived connections.
> If you really know how to set up an high performance reverse proxy, you
> won't have to ask how to handle Icecast, everyone else should really
> avoid this kind of setup.
We will, I promise. Right now, adding another public IP to this virtual
server is simply not possible, and that is the only solution as port 80
is already bound.
>
>> And it works like a charm, and allows us to benefit from the HTTP 1.1
>> "Host" header, and use it in a virtual host.
>> The filter simply rewrites the listening URL served by the Icecast pages
>> to routable addresses and routable ports.
> It will break some features of the web interface, unless you start
> messing with the replies on the fly.
> Also your Icecast logs will be mostly worthless.
True here also. It makes me think that I though I had read somewhere
that Icecast would correctly interpret the X-Forwarded-For headers, and
print the client information accordingly. Here, we only have a bunch of
localhost clients.
>
>> I would agree this is not the most elegant way to do, but we don't have
>> a choice here.
> You have a choice, but decided to accept the trade-off. You always have
> a choice.
In our case, more money will allow us to make more choices. Right now,
we have neither of them.
>
>
> Cheers
>
> Thomas
>
>> Cheers !
>>
>> Le 23/05/2014 10:59, "Thomas B. R?cker" a ?crit :
>>> On 05/21/2014 10:51 PM, David Hendry wrote:
>>>> Ezstream is working well locally with Icecast2 on port 8000 on a Debian Wheezy platform. However, I use a reverse proxy (Pound) to pass all requests from the Internet for x.mysite.com to backend localhost:8000 i.e. my Icecast2 server.
>>> The short answer is: don't put Icecast behind a reverse proxy.
>>>
>>>>  This works fine, i.e. x.mysite.com brings up the Icecast2 Status page. My problem is with the ezstream xml configuration <url></url> setting which must have a port number, and if I put <url>x.mysite.com:8000</url> icecast2 does not get the stream. If I use NAT on my router to bypass the reverse proxy, x.mysite.com:8000 goes straight to Icecast2 and everything works; but I don't want to do it this way. Do you have any ideas as to what I can do to get  ezstream working with icecast2 and my reverse proxy?
>>> You are trying to put non-HTTP traffic through a HTTP reverse proxy, I'm
>>> not the least surprised that this fails.
>>> There /might/ be a slim chance to get things working better if you
>>> switch to Icecast 2.4.0 AND use a source client that uses PUT instead of
>>> SOURCE. But only if the reverse proxy supports PUT.
>>>
>>> Your reverse proxy might still have problems with the long-lived TCP
>>> connections and other things specific to Icecast.
>>>
>>> Cheers
>>>
>>> Thomas
>>> _______________________________________________
>>> 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
>



From thomas at ruecker.fi  Fri May 23 12:37:57 2014
From: thomas at ruecker.fi (=?ISO-8859-1?Q?=22Thomas_B=2E_R=FCcker=22?=)
Date: Fri, 23 May 2014 12:37:57 +0000
Subject: [Icecast] X-forwarded-for header Was:[Re:  Icecast2,
 ezstream and reverse proxy]
In-Reply-To: <537F35C0.8080208@radiom.fr>
References: <15246737.20641400712704635.JavaMail.www@wwinf3715>	<537F0DF8.1020407@ruecker.fi>	<537F1614.2010409@radiom.fr>	<537F267C.4020407@ruecker.fi>
	<537F35C0.8080208@radiom.fr>
Message-ID: <537F4125.6000904@ruecker.fi>

On 05/23/2014 11:49 AM, Hoggins! wrote:
> Le 23/05/2014 12:44, "Thomas B. R?cker" a ?crit :
>> Hi,
>>
>> On 05/23/2014 09:34 AM, Hoggins! wrote:
>>> And it works like a charm, and allows us to benefit from the HTTP 1.1
>>> "Host" header, and use it in a virtual host.
>>> The filter simply rewrites the listening URL served by the Icecast pages
>>> to routable addresses and routable ports.
>> It will break some features of the web interface, unless you start
>> messing with the replies on the fly.
>> Also your Icecast logs will be mostly worthless.
> True here also. It makes me think that I though I had read somewhere
> that Icecast would correctly interpret the X-Forwarded-For headers, and
> print the client information accordingly. Here, we only have a bunch of
> localhost clients.

I've seen at least two separate patches, but they didn't address this
fully, IIRC. This needs to be off by default and you need to be able to
control it to ensure security. Else anyone can just inject and override
whatever source address they want.
If someone wants to step up and work on completing a patch, I'd be very
happy to see that.


Cheers

Thomas


From dragonauta.x at gmail.com  Fri May 23 18:55:20 2014
From: dragonauta.x at gmail.com (dragonauta)
Date: Fri, 23 May 2014 15:55:20 -0300
Subject: [Icecast] Hiccup on streaming
Message-ID: <CAGgvmUM8ofM-9f0eVv_d4s5=uDBFV0jmhFGmG5wU1fPRTQU-dA@mail.gmail.com>

Hi all, this is my first time on this list.
I have a very basic icecast2 server installed from Ubuntu repository.
It's running on a linux Ubuntu Studio 12.04 LTS with an Athlon 64 X2 5200+.
This linux box is at a Community FM Radio Station.

We installed a radio automatization software called "Radit".
Radit is developed by a spanish guy and runs very well. It's open source
and multi-platform.

Radit is a four program combo: an automatizer, an encoder, a weather
reporter (get humidity, temp,etc) and a playing grid.
Sorry if I can't describe exactly, english is not my main language.

The encoder uses mp3, ogg and aac+, with bitrates from 32 to 320.

The problem is that we have some hiccups on the streaming.
Example, lets say we listen the phrase: "this is my black pencil"
on the streaming we hear:"this...ak pencil"

I didn't play much with config, just changed user, password and host
The encoder is pointing to localhost and I've tried every combination of
mp3,ogg and aac+ with different bitrates.
We hear hiccups all the time from internet (it's not the buffering hold,
that is normal).

I've checked PC, everything is normal. I didn't have yet the chance to
listen from same lan.
Maybe someone can point me right direction.

thanks
-- 
GPG-Key: 2FFBC43B
Linux Registered User #436806
www.preguntaslinux.org :: supermoderador
bbs.archbang.org :: moderator
jinetedeldragon.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20140523/75eb8b4c/attachment.htm>

From thomas at ruecker.fi  Fri May 23 20:44:29 2014
From: thomas at ruecker.fi (=?ISO-8859-1?Q?=22Thomas_B=2E_R=FCcker=22?=)
Date: Fri, 23 May 2014 20:44:29 +0000
Subject: [Icecast] Hiccup on streaming
In-Reply-To: <CAGgvmUM8ofM-9f0eVv_d4s5=uDBFV0jmhFGmG5wU1fPRTQU-dA@mail.gmail.com>
References: <CAGgvmUM8ofM-9f0eVv_d4s5=uDBFV0jmhFGmG5wU1fPRTQU-dA@mail.gmail.com>
Message-ID: <537FB32D.6030900@ruecker.fi>

On 05/23/2014 06:55 PM, dragonauta wrote:
> Hi all, this is my first time on this list.
> I have a very basic icecast2 server installed from Ubuntu repository.
> It's running on a linux Ubuntu Studio 12.04 LTS with an Athlon 64 X2
> 5200+.
> This linux box is at a Community FM Radio Station.
>
> We installed a radio automatization software called "Radit".
> Radit is developed by a spanish guy and runs very well. It's open
> source and multi-platform.
>
> Radit is a four program combo: an automatizer, an encoder, a weather
> reporter (get humidity, temp,etc) and a playing grid.
> Sorry if I can't describe exactly, english is not my main language.
>
> The encoder uses mp3, ogg and aac+, with bitrates from 32 to 320.
>
> The problem is that we have some hiccups on the streaming.
> Example, lets say we listen the phrase: "this is my black pencil"
> on the streaming we hear:"this...ak pencil"

To get a better idea of where that happens you should check if this
"skipping" is the same for all listeners, if yes, then it comes from the
source client, if not it is something between icecast and the listener
client.


> I didn't play much with config, just changed user, password and host
> The encoder is pointing to localhost and I've tried every combination
> of mp3,ogg and aac+ with different bitrates.
> We hear hiccups all the time from internet (it's not the buffering
> hold, that is normal).
>
> I've checked PC, everything is normal. I didn't have yet the chance to
> listen from same lan.
> Maybe someone can point me right direction.

It could be that the source client skips for some reason, e.g. because
of CPU load. This can easily happen also on a multi-CPU system if the
encoding is single threaded and saturates the core on which it's running.

I don't have an immediate idea where your problem could be coming from,
so it's important to go step by step and rule out each part. It might
help to look at all possible logging, both on the source and on the
icecast (error.log) side.

Good luck fixing your issue!

Thomas





From dragonauta.x at gmail.com  Fri May 23 23:10:38 2014
From: dragonauta.x at gmail.com (dragonauta)
Date: Fri, 23 May 2014 20:10:38 -0300
Subject: [Icecast] Hiccup on streaming
In-Reply-To: <537FB32D.6030900@ruecker.fi>
References: <CAGgvmUM8ofM-9f0eVv_d4s5=uDBFV0jmhFGmG5wU1fPRTQU-dA@mail.gmail.com>
	<537FB32D.6030900@ruecker.fi>
Message-ID: <CAGgvmUN7NasGuOS=Pq18SUw0D2yA7nu5+VL6f0CPWBYPMhYq3A@mail.gmail.com>

Thanks Thomas


2014-05-23 17:44 GMT-03:00 "Thomas B. R?cker" <thomas at ruecker.fi>:

> On 05/23/2014 06:55 PM, dragonauta wrote:
> > Hi all, this is my first time on this list.
> > I have a very basic icecast2 server installed from Ubuntu repository.
> > It's running on a linux Ubuntu Studio 12.04 LTS with an Athlon 64 X2
> > 5200+.
> > This linux box is at a Community FM Radio Station.
> >
> > We installed a radio automatization software called "Radit".
> > Radit is developed by a spanish guy and runs very well. It's open
> > source and multi-platform.
> >
> > Radit is a four program combo: an automatizer, an encoder, a weather
> > reporter (get humidity, temp,etc) and a playing grid.
> > Sorry if I can't describe exactly, english is not my main language.
> >
> > The encoder uses mp3, ogg and aac+, with bitrates from 32 to 320.
> >
> > The problem is that we have some hiccups on the streaming.
> > Example, lets say we listen the phrase: "this is my black pencil"
> > on the streaming we hear:"this...ak pencil"
>
> To get a better idea of where that happens you should check if this
> "skipping" is the same for all listeners, if yes, then it comes from the
> source client, if not it is something between icecast and the listener
> client.
>
>
We tried with muses.org (radio player online) and TuneIn from diferent
locations, even with differents ISP.
Using PC and android smartphone.
Also tested with vlc

If you anyone wants to check:
Look at TuneIn for "Radio Barriletes"
Our player (muses): http://barriletes.org.ar/radio1.html
And direct access: http://radiobarriletes.sytes.net:8000/barriletes.mp3

I didn't tested on site, through lan, because I'm not at that location
right now. It's a test I want to perform.


>
> > I didn't play much with config, just changed user, password and host
> > The encoder is pointing to localhost and I've tried every combination
> > of mp3,ogg and aac+ with different bitrates.
> > We hear hiccups all the time from internet (it's not the buffering
> > hold, that is normal).
> >
> > I've checked PC, everything is normal. I didn't have yet the chance to
> > listen from same lan.
> > Maybe someone can point me right direction.
>
> It could be that the source client skips for some reason, e.g. because
> of CPU load. This can easily happen also on a multi-CPU system if the
> encoding is single threaded and saturates the core on which it's running.
>
> Linux top shows this
Tasks: 174 total,   2 running, 172 sleeping,   0 stopped,   0 zombie
Cpu(s): 27.5%us,  6.8%sy,  0.0%ni, 65.1%id,  0.4%wa,  0.0%hi,  0.2%si,
 0.0%st
Mem:   1931676k total,  1650232k used,   281444k free,   468284k buffers
Swap:  2095100k total,   108644k used,  1986456k free,   890236k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1918 operador  20   0  543m  70m  21m S   14  3.7   5401:22 Radit
 1904 operador  20   0  268m  20m  13m S    6  1.1   2804:29 raditcast
 1739 operador   9 -11  180m 6724 4644 S    4  0.3   2105:52 pulseaudio
24929 operador  20   0  4460 1924  744 S    4  0.1  11:31.26 lame

Radit its the automatizer, raditcast is the wrapper that uses lame to
encode and makes connection to icecast2



> I don't have an immediate idea where your problem could be coming from,
> so it's important to go step by step and rule out each part. It might
> help to look at all possible logging, both on the source and on the
> icecast (error.log) side.
>
> I looked at logs, everything looks normal. Logs are in level 3 (should I
turn debug on?)



> Good luck fixing your issue!
>
> Thomas
>
>
Thank you again

-- 
GPG-Key: 2FFBC43B
Linux Registered User #436806
www.preguntaslinux.org :: supermoderador
bbs.archbang.org :: moderator
jinetedeldragon.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20140523/85cea266/attachment.htm>

From jv_erner at hotmail.com  Sat May 24 23:29:04 2014
From: jv_erner at hotmail.com (Jordan Verner)
Date: Sat, 24 May 2014 19:29:04 -0400
Subject: [Icecast] Keeping icecast + ices 2.X running on a strict schedule?
Message-ID: <COL130-W2100B64DE930D329C30A34E2390@phx.gbl>

Hello,
I'm using Icecast, Ices, and the script module configuration to serve the playlist to the server. Playlists are scheduled once per day with regularely placed events (like spots) which run at specific times.
Unfortunately it's being served too fast, so it's always getting ahead of schedule (gaining about 10 seconds on every hour).
I have tried adjusting the flush-samples setting in ices.xml and the queue size in the icecast.xml file to no avail.
I've had to resort to implementing a forced delay into the php script which feeds the filenames to ices, so that if ices calls it significantly early it'll wait to issue the next filename until it's closer to it's scheduled start time. This was causing disconnects whenever it became deviated beyond 10 seconds. Disabling source timeout fixed this, but still it tries to get as far ahead as physically possible and takes as much wiggle room as I give it plus more.
Is there any fix for this? Streaming for 24 hours would have it calling the script as much as 4 minutes ahead of schedule, forcing my script to hang for all that time before issuing each and every filename.
This is way too much deviation for streams which stick to a schedule. Two weeks of streaming would have everything an hour early.
Thanks,
 
Jordan.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20140524/e989b522/attachment.htm>

From thomas at ruecker.fi  Sun May 25 07:05:42 2014
From: thomas at ruecker.fi (=?ISO-8859-1?Q?=22Thomas_B=2E_R=FCcker=22?=)
Date: Sun, 25 May 2014 07:05:42 +0000
Subject: [Icecast] Keeping icecast + ices 2.X running on a strict
	schedule?
In-Reply-To: <COL130-W2100B64DE930D329C30A34E2390@phx.gbl>
References: <COL130-W2100B64DE930D329C30A34E2390@phx.gbl>
Message-ID: <53819646.1060606@ruecker.fi>

Hi,

On 05/24/2014 11:29 PM, Jordan Verner wrote:
> I'm using Icecast, Ices, and the script module configuration to serve
> the playlist to the server. Playlists are scheduled once per day with
> regularely placed events (like spots) which run at specific times.
> Unfortunately it's being served too fast, so it's always getting ahead
> of schedule (gaining about 10 seconds on every hour).

Sounds like the clocking is faster for some reason.

> I have tried adjusting the flush-samples setting in ices.xml and the
> queue size in the icecast.xml file to no avail.
> I've had to resort to implementing a forced delay into the php script
> which feeds the filenames to ices, so that if ices calls it
> significantly early it'll wait to issue the next filename until it's
> closer to it's scheduled start time. This was causing disconnects
> whenever it became deviated beyond 10 seconds. Disabling source
> timeout fixed this, but still it tries to get as far ahead as
> physically possible and takes as much wiggle room as I give it plus more.

That won't fix it. You're inserting gaps into the stream and that's a
bad thing for your listeners too.

> Is there any fix for this? Streaming for 24 hours would have it
> calling the script as much as 4 minutes ahead of schedule, forcing my
> script to hang for all that time before issuing each and every filename.
> This is way too much deviation for streams which stick to a schedule.
> Two weeks of streaming would have everything an hour early.

So for some reason on your system Ices is running 0.28% faster. I'm not
sure what causes this and where those samples go. Is it by chance a
virtual machine?

You can try to fiddle further with ices settings. If that doesn't fix it
then you could always have your script insert a 10s filler jingle if it
detects that you're out of the timeframe.

Other options would be to explore different automation solutions, but
they might suffer the same problem if it's some underlying clock oddity
on your system.

Cheers

Thomas


From jv_erner at hotmail.com  Sun May 25 13:13:38 2014
From: jv_erner at hotmail.com (Jordan Verner)
Date: Sun, 25 May 2014 09:13:38 -0400
Subject: [Icecast] Keeping icecast + ices 2.X running on a strict
 schedule?
In-Reply-To: <53819646.1060606@ruecker.fi>
References: <COL130-W2100B64DE930D329C30A34E2390@phx.gbl>,
	<53819646.1060606@ruecker.fi>
Message-ID: <COL130-W291E33E56BC1AF72443F7DE2380@phx.gbl>

Hello,
Icecast and Ices are running on the same machine and it is a dedicated server.
It is a Xeon 1270 V2 CPU with 16 GB ram running Centos 64-bit.
Any thoughts on which settings I could try next? I have tried everything that appears to relate to the speed at which the stream occurs to no avail.
One point I forgot to mention is that some tracks bring on more deviation than others. Shorter tracks, like spots, through it off more than longer tracks (I think). There are definitely tracks that inflict this effect more than others.
I haven't experienced any other timing oddities on the machine.
Thanks,
 
Jordan.
 
> Date: Sun, 25 May 2014 07:05:42 +0000
> From: thomas at ruecker.fi
> To: icecast at xiph.org
> Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a strict	schedule?
> 
> Hi,
> 
> On 05/24/2014 11:29 PM, Jordan Verner wrote:
> > I'm using Icecast, Ices, and the script module configuration to serve
> > the playlist to the server. Playlists are scheduled once per day with
> > regularely placed events (like spots) which run at specific times.
> > Unfortunately it's being served too fast, so it's always getting ahead
> > of schedule (gaining about 10 seconds on every hour).
> 
> Sounds like the clocking is faster for some reason.
> 
> > I have tried adjusting the flush-samples setting in ices.xml and the
> > queue size in the icecast.xml file to no avail.
> > I've had to resort to implementing a forced delay into the php script
> > which feeds the filenames to ices, so that if ices calls it
> > significantly early it'll wait to issue the next filename until it's
> > closer to it's scheduled start time. This was causing disconnects
> > whenever it became deviated beyond 10 seconds. Disabling source
> > timeout fixed this, but still it tries to get as far ahead as
> > physically possible and takes as much wiggle room as I give it plus more.
> 
> That won't fix it. You're inserting gaps into the stream and that's a
> bad thing for your listeners too.
> 
> > Is there any fix for this? Streaming for 24 hours would have it
> > calling the script as much as 4 minutes ahead of schedule, forcing my
> > script to hang for all that time before issuing each and every filename.
> > This is way too much deviation for streams which stick to a schedule.
> > Two weeks of streaming would have everything an hour early.
> 
> So for some reason on your system Ices is running 0.28% faster. I'm not
> sure what causes this and where those samples go. Is it by chance a
> virtual machine?
> 
> You can try to fiddle further with ices settings. If that doesn't fix it
> then you could always have your script insert a 10s filler jingle if it
> detects that you're out of the timeframe.
> 
> Other options would be to explore different automation solutions, but
> they might suffer the same problem if it's some underlying clock oddity
> on your system.
> 
> Cheers
> 
> Thomas
> _______________________________________________
> 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/20140525/a482f64b/attachment.htm>

From thomas at ruecker.fi  Sun May 25 13:23:09 2014
From: thomas at ruecker.fi (=?ISO-8859-1?Q?=22Thomas_B=2E_R=FCcker=22?=)
Date: Sun, 25 May 2014 13:23:09 +0000
Subject: [Icecast] Keeping icecast + ices 2.X running on a strict
	schedule?
In-Reply-To: <COL130-W291E33E56BC1AF72443F7DE2380@phx.gbl>
References: <COL130-W2100B64DE930D329C30A34E2390@phx.gbl>,
	<53819646.1060606@ruecker.fi>
	<COL130-W291E33E56BC1AF72443F7DE2380@phx.gbl>
Message-ID: <5381EEBD.8030207@ruecker.fi>

On 05/25/2014 01:13 PM, Jordan Verner wrote:
> Icecast and Ices are running on the same machine and it is a dedicated
> server.
> It is a Xeon 1270 V2 CPU with 16 GB ram running Centos 64-bit.
> Any thoughts on which settings I could try next? I have tried
> everything that appears to relate to the speed at which the stream
> occurs to no avail.
> One point I forgot to mention is that some tracks bring on more
> deviation than others. Shorter tracks, like spots, through it off more
> than longer tracks (I think). There are definitely tracks that inflict
> this effect more than others.

I'm going to revise my guess. It's probably inaccuracies in how you
account for track length in your system. But ultimately it's irrelevant.
I'd suggest to explore the idea of a filler jingle, as pointed out
earlier. If you want to get fancy, you can even have several to
dynamically chose to adjust for the offset more accurately. Although,
I'm going to say that this is overkill and a 10s jingle/sound file
should be just fine, also most listener software will have a buffer of
10-60s anyway, so being "on the dot" doesn't really come out right
anyway. If you want silence, then please note that you should use very
low level noise instead of digital silence. For the listener it will be
indistinguishable, as the noise will probably be below the noise floor
of their sound card, but for the vorbis encoder this makes a crucial
difference. Digital silence compresses down to single bits per second
and will lead to source timeouts and ill effects in listener software
and should be avoided at all cost when streaming.


> I haven't experienced any other timing oddities on the machine.

If you can live with the above, then I'd suggest to take that route.

Cheers

TBR


>  
> > Date: Sun, 25 May 2014 07:05:42 +0000
> > From: thomas at ruecker.fi
> > To: icecast at xiph.org
> > Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a
> strict schedule?
> >
> > Hi,
> >
> > On 05/24/2014 11:29 PM, Jordan Verner wrote:
> > > I'm using Icecast, Ices, and the script module configuration to serve
> > > the playlist to the server. Playlists are scheduled once per day with
> > > regularely placed events (like spots) which run at specific times.
> > > Unfortunately it's being served too fast, so it's always getting ahead
> > > of schedule (gaining about 10 seconds on every hour).
> >
> > Sounds like the clocking is faster for some reason.
> >
> > > I have tried adjusting the flush-samples setting in ices.xml and the
> > > queue size in the icecast.xml file to no avail.
> > > I've had to resort to implementing a forced delay into the php script
> > > which feeds the filenames to ices, so that if ices calls it
> > > significantly early it'll wait to issue the next filename until it's
> > > closer to it's scheduled start time. This was causing disconnects
> > > whenever it became deviated beyond 10 seconds. Disabling source
> > > timeout fixed this, but still it tries to get as far ahead as
> > > physically possible and takes as much wiggle room as I give it
> plus more.
> >
> > That won't fix it. You're inserting gaps into the stream and that's a
> > bad thing for your listeners too.
> >
> > > Is there any fix for this? Streaming for 24 hours would have it
> > > calling the script as much as 4 minutes ahead of schedule, forcing my
> > > script to hang for all that time before issuing each and every
> filename.
> > > This is way too much deviation for streams which stick to a schedule.
> > > Two weeks of streaming would have everything an hour early.
> >
> > So for some reason on your system Ices is running 0.28% faster. I'm not
> > sure what causes this and where those samples go. Is it by chance a
> > virtual machine?
> >
> > You can try to fiddle further with ices settings. If that doesn't fix it
> > then you could always have your script insert a 10s filler jingle if it
> > detects that you're out of the timeframe.
> >
> > Other options would be to explore different automation solutions, but
> > they might suffer the same problem if it's some underlying clock oddity
> > on your system.
> >
> > Cheers
> >
> > Thomas
> > _______________________________________________
> > 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/20140525/745ae1c0/attachment.htm>

From jv_erner at hotmail.com  Sun May 25 14:03:10 2014
From: jv_erner at hotmail.com (Jordan Verner)
Date: Sun, 25 May 2014 10:03:10 -0400
Subject: [Icecast] Keeping icecast + ices 2.X running on a strict
 schedule?
In-Reply-To: <5381EEBD.8030207@ruecker.fi>
References: <COL130-W2100B64DE930D329C30A34E2390@phx.gbl>, ,
	<53819646.1060606@ruecker.fi>,
	<COL130-W291E33E56BC1AF72443F7DE2380@phx.gbl>,
	<5381EEBD.8030207@ruecker.fi>
Message-ID: <COL130-W64AE0D8FB6CCCFDAC0006AE2380@phx.gbl>

Hello,
Regarding accounting for track lengths, could sox (soxi) be getting it wrong?
Here's my approach atm:
$lengths = array();
foreach($files as $val)
{
//Note that $files has already been populated by glob()
$temp = explode(":", shell_exec('soxi -d "'.$val.'"'));
$length = $temp[0] * 60 * 60;//convert the hours to seconds.
$length += ($temp[1] * 60);//convert minutes to seconds
$length += $temp[2];//add the seconds
$length *= 1000;//convert to milliseconds.

$lengths[$val] = $length;
}
With that done, I can retrieve lengths like this:
$test = $lengths["/home/caturria/songs/etc.ogg"];
I'm going to try subtracting a tenth of a second or so from these values just to see if I can get slightly more sane results.
Thanks,
 
Jordan.
 
Date: Sun, 25 May 2014 13:23:09 +0000
From: thomas at ruecker.fi
To: icecast at xiph.org
Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a strict	schedule?


  
    
  
  
    On 05/25/2014 01:13 PM, Jordan Verner
      wrote:

    
    
      
      Icecast and Ices are running on the same machine
        and it is a dedicated server.

        It is a Xeon 1270 V2 CPU with 16 GB ram running Centos 64-bit.

        Any thoughts on which settings I could try next? I have tried
        everything that appears to relate to the speed at which the
        stream occurs to no avail.

        One point I forgot to mention is that some tracks bring on more
        deviation than others. Shorter tracks, like spots, through it
        off more than longer tracks (I think). There are definitely
        tracks that inflict this effect more than others.

      
    
    

    I'm going to revise my guess. It's probably inaccuracies in how you
    account for track length in your system. But ultimately it's
    irrelevant.

    I'd suggest to explore the idea of a filler jingle, as pointed out
    earlier. If you want to get fancy, you can even have several to
    dynamically chose to adjust for the offset more accurately.
    Although, I'm going to say that this is overkill and a 10s
    jingle/sound file should be just fine, also most listener software
    will have a buffer of 10-60s anyway, so being "on the dot" doesn't
    really come out right anyway. If you want silence, then please note
    that you should use very low level noise instead of digital silence.
    For the listener it will be indistinguishable, as the noise will
    probably be below the noise floor of their sound card, but for the
    vorbis encoder this makes a crucial difference. Digital silence
    compresses down to single bits per second and will lead to source
    timeouts and ill effects in listener software and should be avoided
    at all cost when streaming.

    

    

    
      I haven't experienced any other timing oddities on
        the machine.

      
    
    

    If you can live with the above, then I'd suggest to take that route.

    

    Cheers

    

    TBR

    

    

    
       

        > Date: Sun, 25 May 2014 07:05:42 +0000

          > From: thomas at ruecker.fi

          > To: icecast at xiph.org

          > Subject: Re: [Icecast] Keeping icecast + ices 2.X running
          on a strict schedule?

          > 

          > Hi,

          > 

          > On 05/24/2014 11:29 PM, Jordan Verner wrote:

          > > I'm using Icecast, Ices, and the script module
          configuration to serve

          > > the playlist to the server. Playlists are scheduled
          once per day with

          > > regularely placed events (like spots) which run at
          specific times.

          > > Unfortunately it's being served too fast, so it's
          always getting ahead

          > > of schedule (gaining about 10 seconds on every
          hour).

          > 

          > Sounds like the clocking is faster for some reason.

          > 

          > > I have tried adjusting the flush-samples setting in
          ices.xml and the

          > > queue size in the icecast.xml file to no avail.

          > > I've had to resort to implementing a forced delay
          into the php script

          > > which feeds the filenames to ices, so that if ices
          calls it

          > > significantly early it'll wait to issue the next
          filename until it's

          > > closer to it's scheduled start time. This was
          causing disconnects

          > > whenever it became deviated beyond 10 seconds.
          Disabling source

          > > timeout fixed this, but still it tries to get as far
          ahead as

          > > physically possible and takes as much wiggle room as
          I give it plus more.

          > 

          > That won't fix it. You're inserting gaps into the stream
          and that's a

          > bad thing for your listeners too.

          > 

          > > Is there any fix for this? Streaming for 24 hours
          would have it

          > > calling the script as much as 4 minutes ahead of
          schedule, forcing my

          > > script to hang for all that time before issuing each
          and every filename.

          > > This is way too much deviation for streams which
          stick to a schedule.

          > > Two weeks of streaming would have everything an hour
          early.

          > 

          > So for some reason on your system Ices is running 0.28%
          faster. I'm not

          > sure what causes this and where those samples go. Is it
          by chance a

          > virtual machine?

          > 

          > You can try to fiddle further with ices settings. If that
          doesn't fix it

          > then you could always have your script insert a 10s
          filler jingle if it

          > detects that you're out of the timeframe.

          > 

          > Other options would be to explore different automation
          solutions, but

          > they might suffer the same problem if it's some
          underlying clock oddity

          > on your system.

          > 

          > Cheers

          > 

          > Thomas

          > _______________________________________________

          > 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/20140525/e3d9a834/attachment.htm>

From dragonauta.x at gmail.com  Sun May 25 21:07:54 2014
From: dragonauta.x at gmail.com (dragonauta)
Date: Sun, 25 May 2014 18:07:54 -0300
Subject: [Icecast] Hiccup on streaming
Message-ID: <CAGgvmUMt-9DSyLG8-MpGQAT=VQxGruYA9Pi-tU2J+RAqhE5qEw@mail.gmail.com>

Ok, tested on LAN: no hiccups, its very fluid stream at 32kbps
tested with TuneIn, VLC and MX Player (for android)

Also tested from Internet for last two days and noticed no hiccup,
so I'm thinking that my ISP is having problems.

Is there a minimum/recommended bandwith for ISP connections when streaming?

Right now I have 3mbps download and 0.60mbps upload.
I know I should have better upload rate, I will go to my ISP to check for
other plans



2014-05-23 20:10 GMT-03:00 dragonauta <dragonauta.x at gmail.com>:

> Thanks Thomas
>
>
> 2014-05-23 17:44 GMT-03:00 "Thomas B. R?cker" <thomas at ruecker.fi>:
>
> On 05/23/2014 06:55 PM, dragonauta wrote:
>> > Hi all, this is my first time on this list.
>> > I have a very basic icecast2 server installed from Ubuntu repository.
>> > It's running on a linux Ubuntu Studio 12.04 LTS with an Athlon 64 X2
>> > 5200+.
>> > This linux box is at a Community FM Radio Station.
>> >
>> > We installed a radio automatization software called "Radit".
>> > Radit is developed by a spanish guy and runs very well. It's open
>> > source and multi-platform.
>> >
>> > Radit is a four program combo: an automatizer, an encoder, a weather
>> > reporter (get humidity, temp,etc) and a playing grid.
>> > Sorry if I can't describe exactly, english is not my main language.
>> >
>> > The encoder uses mp3, ogg and aac+, with bitrates from 32 to 320.
>> >
>> > The problem is that we have some hiccups on the streaming.
>> > Example, lets say we listen the phrase: "this is my black pencil"
>> > on the streaming we hear:"this...ak pencil"
>>
>> To get a better idea of where that happens you should check if this
>> "skipping" is the same for all listeners, if yes, then it comes from the
>> source client, if not it is something between icecast and the listener
>> client.
>>
>>
> We tried with muses.org (radio player online) and TuneIn from diferent
> locations, even with differents ISP.
> Using PC and android smartphone.
> Also tested with vlc
>
> If you anyone wants to check:
> Look at TuneIn for "Radio Barriletes"
> Our player (muses): http://barriletes.org.ar/radio1.html
> And direct access: http://radiobarriletes.sytes.net:8000/barriletes.mp3
>
> I didn't tested on site, through lan, because I'm not at that location
> right now. It's a test I want to perform.
>
>
>>
>> > I didn't play much with config, just changed user, password and host
>> > The encoder is pointing to localhost and I've tried every combination
>> > of mp3,ogg and aac+ with different bitrates.
>> > We hear hiccups all the time from internet (it's not the buffering
>> > hold, that is normal).
>> >
>> > I've checked PC, everything is normal. I didn't have yet the chance to
>> > listen from same lan.
>> > Maybe someone can point me right direction.
>>
>> It could be that the source client skips for some reason, e.g. because
>> of CPU load. This can easily happen also on a multi-CPU system if the
>> encoding is single threaded and saturates the core on which it's running.
>>
>> Linux top shows this
> Tasks: 174 total,   2 running, 172 sleeping,   0 stopped,   0 zombie
> Cpu(s): 27.5%us,  6.8%sy,  0.0%ni, 65.1%id,  0.4%wa,  0.0%hi,  0.2%si,
>  0.0%st
> Mem:   1931676k total,  1650232k used,   281444k free,   468284k buffers
> Swap:  2095100k total,   108644k used,  1986456k free,   890236k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  1918 operador  20   0  543m  70m  21m S   14  3.7   5401:22 Radit
>  1904 operador  20   0  268m  20m  13m S    6  1.1   2804:29 raditcast
>  1739 operador   9 -11  180m 6724 4644 S    4  0.3   2105:52 pulseaudio
> 24929 operador  20   0  4460 1924  744 S    4  0.1  11:31.26 lame
>
> Radit its the automatizer, raditcast is the wrapper that uses lame to
> encode and makes connection to icecast2
>
>
>
>> I don't have an immediate idea where your problem could be coming from,
>> so it's important to go step by step and rule out each part. It might
>> help to look at all possible logging, both on the source and on the
>> icecast (error.log) side.
>>
>> I looked at logs, everything looks normal. Logs are in level 3 (should I
> turn debug on?)
>
>
>
>> Good luck fixing your issue!
>>
>> Thomas
>>
>>
> Thank you again
>
> --
> GPG-Key: 2FFBC43B
> Linux Registered User #436806
> www.preguntaslinux.org :: supermoderador
> bbs.archbang.org :: moderator
> jinetedeldragon.wordpress.com
>
>
>


-- 
GPG-Key: 2FFBC43B
Linux Registered User #436806
www.preguntaslinux.org :: supermoderador
bbs.archbang.org :: moderator
jinetedeldragon.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20140525/b7555eab/attachment.htm>

From jv_erner at hotmail.com  Mon May 26 02:23:35 2014
From: jv_erner at hotmail.com (Jordan Verner)
Date: Sun, 25 May 2014 22:23:35 -0400
Subject: [Icecast] Keeping icecast + ices 2.X running on a strict
 schedule?
In-Reply-To: <COL130-W64AE0D8FB6CCCFDAC0006AE2380@phx.gbl>
References: <COL130-W2100B64DE930D329C30A34E2390@phx.gbl>,
	, , <53819646.1060606@ruecker.fi>, ,
	<COL130-W291E33E56BC1AF72443F7DE2380@phx.gbl>, ,
	<5381EEBD.8030207@ruecker.fi>,
	<COL130-W64AE0D8FB6CCCFDAC0006AE2380@phx.gbl>
Message-ID: <COL130-W715547523C70A1AC34C6F1E23B0@phx.gbl>

Hello,
In conclusion I'm pretty sure this issue is the symptom of a bug, either within Ices or Icecast itself. I decided to try running the same setup on Shoutcast today, and it's working perfectly. An hour of streaming at the time of this message, and absolutely no schedule deviation.
It appears as though Shoutcast has better rate control than Icecast does at the moment or something.
Thanks,
 
Jordan.
 
From: jv_erner at hotmail.com
To: icecast at xiph.org
Date: Sun, 25 May 2014 10:03:10 -0400
Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a strict schedule?




Hello,
Regarding accounting for track lengths, could sox (soxi) be getting it wrong?
Here's my approach atm:
$lengths = array();
foreach($files as $val)
{
//Note that $files has already been populated by glob()
$temp = explode(":", shell_exec('soxi -d "'.$val.'"'));
$length = $temp[0] * 60 * 60;//convert the hours to seconds.
$length += ($temp[1] * 60);//convert minutes to seconds
$length += $temp[2];//add the seconds
$length *= 1000;//convert to milliseconds.

$lengths[$val] = $length;
}
With that done, I can retrieve lengths like this:
$test = $lengths["/home/caturria/songs/etc.ogg"];
I'm going to try subtracting a tenth of a second or so from these values just to see if I can get slightly more sane results.
Thanks,
 
Jordan.
 
Date: Sun, 25 May 2014 13:23:09 +0000
From: thomas at ruecker.fi
To: icecast at xiph.org
Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a strict	schedule?


  
    
  
  
    On 05/25/2014 01:13 PM, Jordan Verner
      wrote:

    
    
      
      Icecast and Ices are running on the same machine
        and it is a dedicated server.

        It is a Xeon 1270 V2 CPU with 16 GB ram running Centos 64-bit.

        Any thoughts on which settings I could try next? I have tried
        everything that appears to relate to the speed at which the
        stream occurs to no avail.

        One point I forgot to mention is that some tracks bring on more
        deviation than others. Shorter tracks, like spots, through it
        off more than longer tracks (I think). There are definitely
        tracks that inflict this effect more than others.

      
    
    

    I'm going to revise my guess. It's probably inaccuracies in how you
    account for track length in your system. But ultimately it's
    irrelevant.

    I'd suggest to explore the idea of a filler jingle, as pointed out
    earlier. If you want to get fancy, you can even have several to
    dynamically chose to adjust for the offset more accurately.
    Although, I'm going to say that this is overkill and a 10s
    jingle/sound file should be just fine, also most listener software
    will have a buffer of 10-60s anyway, so being "on the dot" doesn't
    really come out right anyway. If you want silence, then please note
    that you should use very low level noise instead of digital silence.
    For the listener it will be indistinguishable, as the noise will
    probably be below the noise floor of their sound card, but for the
    vorbis encoder this makes a crucial difference. Digital silence
    compresses down to single bits per second and will lead to source
    timeouts and ill effects in listener software and should be avoided
    at all cost when streaming.

    

    

    
      I haven't experienced any other timing oddities on
        the machine.

      
    
    

    If you can live with the above, then I'd suggest to take that route.

    

    Cheers

    

    TBR

    

    

    
       

        > Date: Sun, 25 May 2014 07:05:42 +0000

          > From: thomas at ruecker.fi

          > To: icecast at xiph.org

          > Subject: Re: [Icecast] Keeping icecast + ices 2.X running
          on a strict schedule?

          > 

          > Hi,

          > 

          > On 05/24/2014 11:29 PM, Jordan Verner wrote:

          > > I'm using Icecast, Ices, and the script module
          configuration to serve

          > > the playlist to the server. Playlists are scheduled
          once per day with

          > > regularely placed events (like spots) which run at
          specific times.

          > > Unfortunately it's being served too fast, so it's
          always getting ahead

          > > of schedule (gaining about 10 seconds on every
          hour).

          > 

          > Sounds like the clocking is faster for some reason.

          > 

          > > I have tried adjusting the flush-samples setting in
          ices.xml and the

          > > queue size in the icecast.xml file to no avail.

          > > I've had to resort to implementing a forced delay
          into the php script

          > > which feeds the filenames to ices, so that if ices
          calls it

          > > significantly early it'll wait to issue the next
          filename until it's

          > > closer to it's scheduled start time. This was
          causing disconnects

          > > whenever it became deviated beyond 10 seconds.
          Disabling source

          > > timeout fixed this, but still it tries to get as far
          ahead as

          > > physically possible and takes as much wiggle room as
          I give it plus more.

          > 

          > That won't fix it. You're inserting gaps into the stream
          and that's a

          > bad thing for your listeners too.

          > 

          > > Is there any fix for this? Streaming for 24 hours
          would have it

          > > calling the script as much as 4 minutes ahead of
          schedule, forcing my

          > > script to hang for all that time before issuing each
          and every filename.

          > > This is way too much deviation for streams which
          stick to a schedule.

          > > Two weeks of streaming would have everything an hour
          early.

          > 

          > So for some reason on your system Ices is running 0.28%
          faster. I'm not

          > sure what causes this and where those samples go. Is it
          by chance a

          > virtual machine?

          > 

          > You can try to fiddle further with ices settings. If that
          doesn't fix it

          > then you could always have your script insert a 10s
          filler jingle if it

          > detects that you're out of the timeframe.

          > 

          > Other options would be to explore different automation
          solutions, but

          > they might suffer the same problem if it's some
          underlying clock oddity

          > on your system.

          > 

          > Cheers

          > 

          > Thomas

          > _______________________________________________

          > 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/20140525/f349af48/attachment.htm>

From brad at musatcha.com  Mon May 26 03:48:49 2014
From: brad at musatcha.com (Brad Isbell)
Date: Sun, 25 May 2014 22:48:49 -0500
Subject: [Icecast] Keeping icecast + ices 2.X running on a strict
	schedule?
In-Reply-To: <COL130-W715547523C70A1AC34C6F1E23B0@phx.gbl>
References: <COL130-W2100B64DE930D329C30A34E2390@phx.gbl>
	<53819646.1060606@ruecker.fi>
	<COL130-W291E33E56BC1AF72443F7DE2380@phx.gbl>
	<5381EEBD.8030207@ruecker.fi>
	<COL130-W64AE0D8FB6CCCFDAC0006AE2380@phx.gbl>
	<COL130-W715547523C70A1AC34C6F1E23B0@phx.gbl>
Message-ID: <CAELR-fAGRv1WWQBAwFJb5w_k6teFUh0Pj=d2wj6uvn5gKqiemQ@mail.gmail.com>

The server doesn't control the rate, the source does.  Provided you aren't
getting corrupt stream data (and it doesn't sound like you are), you don't
have a server bug in this case.  At a basic level, the server level takes
the data that comes in from the source, buffers it, and sends it right back
out the door at the rate at which it came in.

It isn't entirely clear to me where you're seeing the timing issue and what
your setup is, but there are a couple other things to think about:

   - Clock drift happens.  It's pretty severe but not unheard of for a
   sound card to play back +/- 1% or so of the rate.  In your case, you're
   looking at a 0.28% difference.  Perhaps there is a problem on the playback
   end?  Are you sure your users are having this trouble?  Even if they all
   aren't, some inevitably will on any station.
   - Measurement in time of lossy audio files is usually not very exact.
    MP3 files in particular have no track length header.
   - Timing tracks down to the second will throw you off by 10 seconds at
   the end of a playlist anyway, due to rounding up/down to the nearest second.
   - If you can, don't plan out your perfect playlist by time.  You need
   something that will automatically adjust things for you as you go.  It's
   unrealistic to assume that you will be able to come up with a playlist
   timed perfectly when dealing with a variety of formats and codecs with an
   encoder that has an artificial clock sending audio to remotes that have
   completely separate clocks.

I don't know what the core of the problem is that you're having, so
hopefully this is helpful.

Brad Isbell
brad at musatcha.com
http://www.musatcha.com


On Sun, May 25, 2014 at 9:23 PM, Jordan Verner <jv_erner at hotmail.com> wrote:

> Hello,
> In conclusion I'm pretty sure this issue is the symptom of a bug, either
> within Ices or Icecast itself. I decided to try running the same setup on
> Shoutcast today, and it's working perfectly. An hour of streaming at the
> time of this message, and absolutely no schedule deviation.
> It appears as though Shoutcast has better rate control than Icecast does
> at the moment or something.
> Thanks,
>
> Jordan.
>
> ------------------------------
> From: jv_erner at hotmail.com
> To: icecast at xiph.org
> Date: Sun, 25 May 2014 10:03:10 -0400
>
> Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a strict
> schedule?
>
> Hello,
> Regarding accounting for track lengths, could sox (soxi) be getting it
> wrong?
> Here's my approach atm:
> $lengths = array();
> foreach($files as $val)
> {
> //Note that $files has already been populated by glob()
> $temp = explode(":", shell_exec('soxi -d "'.$val.'"'));
> $length = $temp[0] * 60 * 60;//convert the hours to seconds.
> $length += ($temp[1] * 60);//convert minutes to seconds
> $length += $temp[2];//add the seconds
> $length *= 1000;//convert to milliseconds.
>
> $lengths[$val] = $length;
> }
> With that done, I can retrieve lengths like this:
> $test = $lengths["/home/caturria/songs/etc.ogg"];
> I'm going to try subtracting a tenth of a second or so from these values
> just to see if I can get slightly more sane results.
> Thanks,
>
> Jordan.
>
> ------------------------------
> Date: Sun, 25 May 2014 13:23:09 +0000
> From: thomas at ruecker.fi
> To: icecast at xiph.org
> Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a strict
> schedule?
>
> On 05/25/2014 01:13 PM, Jordan Verner wrote:
>
> Icecast and Ices are running on the same machine and it is a dedicated
> server.
> It is a Xeon 1270 V2 CPU with 16 GB ram running Centos 64-bit.
> Any thoughts on which settings I could try next? I have tried everything
> that appears to relate to the speed at which the stream occurs to no avail.
> One point I forgot to mention is that some tracks bring on more deviation
> than others. Shorter tracks, like spots, through it off more than longer
> tracks (I think). There are definitely tracks that inflict this effect more
> than others.
>
>
> I'm going to revise my guess. It's probably inaccuracies in how you
> account for track length in your system. But ultimately it's irrelevant.
> I'd suggest to explore the idea of a filler jingle, as pointed out
> earlier. If you want to get fancy, you can even have several to dynamically
> chose to adjust for the offset more accurately. Although, I'm going to say
> that this is overkill and a 10s jingle/sound file should be just fine, also
> most listener software will have a buffer of 10-60s anyway, so being "on
> the dot" doesn't really come out right anyway. If you want silence, then
> please note that you should use very low level noise instead of digital
> silence. For the listener it will be indistinguishable, as the noise will
> probably be below the noise floor of their sound card, but for the vorbis
> encoder this makes a crucial difference. Digital silence compresses down to
> single bits per second and will lead to source timeouts and ill effects in
> listener software and should be avoided at all cost when streaming.
>
>
>  I haven't experienced any other timing oddities on the machine.
>
>
> If you can live with the above, then I'd suggest to take that route.
>
> Cheers
>
> TBR
>
>
>
> > Date: Sun, 25 May 2014 07:05:42 +0000
> > From: thomas at ruecker.fi
> > To: icecast at xiph.org
> > Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a strict
> schedule?
> >
> > Hi,
> >
> > On 05/24/2014 11:29 PM, Jordan Verner wrote:
> > > I'm using Icecast, Ices, and the script module configuration to serve
> > > the playlist to the server. Playlists are scheduled once per day with
> > > regularely placed events (like spots) which run at specific times.
> > > Unfortunately it's being served too fast, so it's always getting ahead
> > > of schedule (gaining about 10 seconds on every hour).
> >
> > Sounds like the clocking is faster for some reason.
> >
> > > I have tried adjusting the flush-samples setting in ices.xml and the
> > > queue size in the icecast.xml file to no avail.
> > > I've had to resort to implementing a forced delay into the php script
> > > which feeds the filenames to ices, so that if ices calls it
> > > significantly early it'll wait to issue the next filename until it's
> > > closer to it's scheduled start time. This was causing disconnects
> > > whenever it became deviated beyond 10 seconds. Disabling source
> > > timeout fixed this, but still it tries to get as far ahead as
> > > physically possible and takes as much wiggle room as I give it plus
> more.
> >
> > That won't fix it. You're inserting gaps into the stream and that's a
> > bad thing for your listeners too.
> >
> > > Is there any fix for this? Streaming for 24 hours would have it
> > > calling the script as much as 4 minutes ahead of schedule, forcing my
> > > script to hang for all that time before issuing each and every
> filename.
> > > This is way too much deviation for streams which stick to a schedule.
> > > Two weeks of streaming would have everything an hour early.
> >
> > So for some reason on your system Ices is running 0.28% faster. I'm not
> > sure what causes this and where those samples go. Is it by chance a
> > virtual machine?
> >
> > You can try to fiddle further with ices settings. If that doesn't fix it
> > then you could always have your script insert a 10s filler jingle if it
> > detects that you're out of the timeframe.
> >
> > Other options would be to explore different automation solutions, but
> > they might suffer the same problem if it's some underlying clock oddity
> > on your system.
> >
> > Cheers
> >
> > Thomas
> > _______________________________________________
> > Icecast mailing list
> > Icecast at xiph.org
> > http://lists.xiph.org/mailman/listinfo/icecast
>
>
> _______________________________________________
> Icecast mailing listIcecast at xiph.orghttp://lists.xiph.org/mailman/listinfo/icecast
>
>
>
> _______________________________________________ Icecast mailing 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/20140525/89e61583/attachment.htm>

From jv_erner at hotmail.com  Mon May 26 04:00:14 2014
From: jv_erner at hotmail.com (Jordan Verner)
Date: Mon, 26 May 2014 00:00:14 -0400
Subject: [Icecast] Keeping icecast + ices 2.X running on a strict
 schedule?
In-Reply-To: <CAELR-fAGRv1WWQBAwFJb5w_k6teFUh0Pj=d2wj6uvn5gKqiemQ@mail.gmail.com>
References: <COL130-W2100B64DE930D329C30A34E2390@phx.gbl>,
	<53819646.1060606@ruecker.fi>,
	<COL130-W291E33E56BC1AF72443F7DE2380@phx.gbl>,
	<5381EEBD.8030207@ruecker.fi>,
	<COL130-W64AE0D8FB6CCCFDAC0006AE2380@phx.gbl>,
	<COL130-W715547523C70A1AC34C6F1E23B0@phx.gbl>,
	<CAELR-fAGRv1WWQBAwFJb5w_k6teFUh0Pj=d2wj6uvn5gKqiemQ@mail.gmail.com>
Message-ID: <COL130-W9044E69BDF870087C9974EE23B0@phx.gbl>

Hello,
Are you saying I should be rounding to the nearest second rather than measuring in milliseconds?
My current approach is to calculate the track lengths by dividing the number of samples by the samplerate, resulting in a value measured in seconds with at least 8 decimal places.
Nevertheless, for some reason a shoutcast + sc_trans setup handles this flawlessly. With Icecast + Ices, data is sent a good bit faster than it can be played. Even if the listener doesn't buffer and fall behind, refreshing after a couple of hours results in a pretty significant jump forward.
From: brad at musatcha.com
Date: Sun, 25 May 2014 22:48:49 -0500
To: icecast at xiph.org
Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a strict	schedule?

The server doesn't control the rate, the source does.  Provided you aren't getting corrupt stream data (and it doesn't sound like you are), you don't have a server bug in this case.  At a basic level, the server level takes the data that comes in from the source, buffers it, and sends it right back out the door at the rate at which it came in.


It isn't entirely clear to me where you're seeing the timing issue and what your setup is, but there are a couple other things to think about:Clock drift happens.  It's pretty severe but not unheard of for a sound card to play back +/- 1% or so of the rate.  In your case, you're looking at a 0.28% difference.  Perhaps there is a problem on the playback end?  Are you sure your users are having this trouble?  Even if they all aren't, some inevitably will on any station.

Measurement in time of lossy audio files is usually not very exact.  MP3 files in particular have no track length header.Timing tracks down to the second will throw you off by 10 seconds at the end of a playlist anyway, due to rounding up/down to the nearest second.

If you can, don't plan out your perfect playlist by time.  You need something that will automatically adjust things for you as you go.  It's unrealistic to assume that you will be able to come up with a playlist timed perfectly when dealing with a variety of formats and codecs with an encoder that has an artificial clock sending audio to remotes that have completely separate clocks.

I don't know what the core of the problem is that you're having, so hopefully this is helpful.Brad Isbell
brad at musatcha.com


http://www.musatcha.com


On Sun, May 25, 2014 at 9:23 PM, Jordan Verner <jv_erner at hotmail.com> wrote:





Hello,
In conclusion I'm pretty sure this issue is the symptom of a bug, either within Ices or Icecast itself. I decided to try running the same setup on Shoutcast today, and it's working perfectly. An hour of streaming at the time of this message, and absolutely no schedule deviation.


It appears as though Shoutcast has better rate control than Icecast does at the moment or something.
Thanks,
 
Jordan.
 


From: jv_erner at hotmail.com
To: icecast at xiph.org
Date: Sun, 25 May 2014 10:03:10 -0400


Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a strict schedule?




Hello,
Regarding accounting for track lengths, could sox (soxi) be getting it wrong?
Here's my approach atm:
$lengths = array();
foreach($files as $val)
{
//Note that $files has already been populated by glob()


$temp = explode(":", shell_exec('soxi -d "'.$val.'"'));
$length = $temp[0] * 60 * 60;//convert the hours to seconds.
$length += ($temp[1] * 60);//convert minutes to seconds
$length += $temp[2];//add the seconds


$length *= 1000;//convert to milliseconds.

$lengths[$val] = $length;
}
With that done, I can retrieve lengths like this:
$test = $lengths["/home/caturria/songs/etc.ogg"];
I'm going to try subtracting a tenth of a second or so from these values just to see if I can get slightly more sane results.


Thanks,
 
Jordan.
 
Date: Sun, 25 May 2014 13:23:09 +0000
From: thomas at ruecker.fi
To: icecast at xiph.org


Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a strict	schedule?


  
    
  
  
    On 05/25/2014 01:13 PM, Jordan Verner
      wrote:

    
    
      
      Icecast and Ices are running on the same machine
        and it is a dedicated server.

        It is a Xeon 1270 V2 CPU with 16 GB ram running Centos 64-bit.

        Any thoughts on which settings I could try next? I have tried
        everything that appears to relate to the speed at which the
        stream occurs to no avail.

        One point I forgot to mention is that some tracks bring on more
        deviation than others. Shorter tracks, like spots, through it
        off more than longer tracks (I think). There are definitely
        tracks that inflict this effect more than others.

      
    
    

    I'm going to revise my guess. It's probably inaccuracies in how you
    account for track length in your system. But ultimately it's
    irrelevant.

    I'd suggest to explore the idea of a filler jingle, as pointed out
    earlier. If you want to get fancy, you can even have several to
    dynamically chose to adjust for the offset more accurately.
    Although, I'm going to say that this is overkill and a 10s
    jingle/sound file should be just fine, also most listener software
    will have a buffer of 10-60s anyway, so being "on the dot" doesn't
    really come out right anyway. If you want silence, then please note
    that you should use very low level noise instead of digital silence.
    For the listener it will be indistinguishable, as the noise will
    probably be below the noise floor of their sound card, but for the
    vorbis encoder this makes a crucial difference. Digital silence
    compresses down to single bits per second and will lead to source
    timeouts and ill effects in listener software and should be avoided
    at all cost when streaming.

    

    

    
      I haven't experienced any other timing oddities on
        the machine.

      
    
    

    If you can live with the above, then I'd suggest to take that route.

    

    Cheers

    

    TBR

    

    

    
       

        > Date: Sun, 25 May 2014 07:05:42 +0000

          > From: thomas at ruecker.fi

          > To: icecast at xiph.org

          > Subject: Re: [Icecast] Keeping icecast + ices 2.X running
          on a strict schedule?

          > 

          > Hi,

          > 

          > On 05/24/2014 11:29 PM, Jordan Verner wrote:

          > > I'm using Icecast, Ices, and the script module
          configuration to serve

          > > the playlist to the server. Playlists are scheduled
          once per day with

          > > regularely placed events (like spots) which run at
          specific times.

          > > Unfortunately it's being served too fast, so it's
          always getting ahead

          > > of schedule (gaining about 10 seconds on every
          hour).

          > 

          > Sounds like the clocking is faster for some reason.

          > 

          > > I have tried adjusting the flush-samples setting in
          ices.xml and the

          > > queue size in the icecast.xml file to no avail.

          > > I've had to resort to implementing a forced delay
          into the php script

          > > which feeds the filenames to ices, so that if ices
          calls it

          > > significantly early it'll wait to issue the next
          filename until it's

          > > closer to it's scheduled start time. This was
          causing disconnects

          > > whenever it became deviated beyond 10 seconds.
          Disabling source

          > > timeout fixed this, but still it tries to get as far
          ahead as

          > > physically possible and takes as much wiggle room as
          I give it plus more.

          > 

          > That won't fix it. You're inserting gaps into the stream
          and that's a

          > bad thing for your listeners too.

          > 

          > > Is there any fix for this? Streaming for 24 hours
          would have it

          > > calling the script as much as 4 minutes ahead of
          schedule, forcing my

          > > script to hang for all that time before issuing each
          and every filename.

          > > This is way too much deviation for streams which
          stick to a schedule.

          > > Two weeks of streaming would have everything an hour
          early.

          > 

          > So for some reason on your system Ices is running 0.28%
          faster. I'm not

          > sure what causes this and where those samples go. Is it
          by chance a

          > virtual machine?

          > 

          > You can try to fiddle further with ices settings. If that
          doesn't fix it

          > then you could always have your script insert a 10s
          filler jingle if it

          > detects that you're out of the timeframe.

          > 

          > Other options would be to explore different automation
          solutions, but

          > they might suffer the same problem if it's some
          underlying clock oddity

          > on your system.

          > 

          > Cheers

          > 

          > Thomas

          > _______________________________________________

          > 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/20140526/99d65eeb/attachment.htm>

From brad at musatcha.com  Mon May 26 14:50:22 2014
From: brad at musatcha.com (Brad Isbell)
Date: Mon, 26 May 2014 09:50:22 -0500
Subject: [Icecast] Keeping icecast + ices 2.X running on a strict
	schedule?
In-Reply-To: <COL130-W9044E69BDF870087C9974EE23B0@phx.gbl>
References: <COL130-W2100B64DE930D329C30A34E2390@phx.gbl>
	<53819646.1060606@ruecker.fi>
	<COL130-W291E33E56BC1AF72443F7DE2380@phx.gbl>
	<5381EEBD.8030207@ruecker.fi>
	<COL130-W64AE0D8FB6CCCFDAC0006AE2380@phx.gbl>
	<COL130-W715547523C70A1AC34C6F1E23B0@phx.gbl>
	<CAELR-fAGRv1WWQBAwFJb5w_k6teFUh0Pj=d2wj6uvn5gKqiemQ@mail.gmail.com>
	<COL130-W9044E69BDF870087C9974EE23B0@phx.gbl>
Message-ID: <CAELR-fAatZ8pRFMoKezi9y+frU3rq=iY24hkKVOe4sp1O27n0Q@mail.gmail.com>

I misunderstood, I thought you were measuring time in whole seconds.

If you use sc_trans with Icecast, I am sure that you will see that the
problem then lies on the source with Ices.

Brad Isbell
brad at musatcha.com
http://www.musatcha.com


On Sun, May 25, 2014 at 11:00 PM, Jordan Verner <jv_erner at hotmail.com>wrote:

> Hello,
> Are you saying I should be rounding to the nearest second rather than
> measuring in milliseconds?
> My current approach is to calculate the track lengths by dividing the
> number of samples by the samplerate, resulting in a value measured in
> seconds with at least 8 decimal places.
> Nevertheless, for some reason a shoutcast + sc_trans setup handles this
> flawlessly. With Icecast + Ices, data is sent a good bit faster than it can
> be played. Even if the listener doesn't buffer and fall behind, refreshing
> after a couple of hours results in a pretty significant jump forward.
> ------------------------------
> From: brad at musatcha.com
> Date: Sun, 25 May 2014 22:48:49 -0500
>
> To: icecast at xiph.org
> Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a strict
> schedule?
>
> The server doesn't control the rate, the source does.  Provided you aren't
> getting corrupt stream data (and it doesn't sound like you are), you don't
> have a server bug in this case.  At a basic level, the server level takes
> the data that comes in from the source, buffers it, and sends it right back
> out the door at the rate at which it came in.
>
> It isn't entirely clear to me where you're seeing the timing issue and
> what your setup is, but there are a couple other things to think about:
>
>    - Clock drift happens.  It's pretty severe but not unheard of for a
>    sound card to play back +/- 1% or so of the rate.  In your case, you're
>    looking at a 0.28% difference.  Perhaps there is a problem on the playback
>    end?  Are you sure your users are having this trouble?  Even if they all
>    aren't, some inevitably will on any station.
>    - Measurement in time of lossy audio files is usually not very exact.
>     MP3 files in particular have no track length header.
>    - Timing tracks down to the second will throw you off by 10 seconds at
>    the end of a playlist anyway, due to rounding up/down to the nearest second.
>    - If you can, don't plan out your perfect playlist by time.  You need
>    something that will automatically adjust things for you as you go.  It's
>    unrealistic to assume that you will be able to come up with a playlist
>    timed perfectly when dealing with a variety of formats and codecs with an
>    encoder that has an artificial clock sending audio to remotes that have
>    completely separate clocks.
>
> I don't know what the core of the problem is that you're having, so
> hopefully this is helpful.
>
> Brad Isbell
> brad at musatcha.com
> http://www.musatcha.com
>
>
> On Sun, May 25, 2014 at 9:23 PM, Jordan Verner <jv_erner at hotmail.com>wrote:
>
> Hello,
> In conclusion I'm pretty sure this issue is the symptom of a bug, either
> within Ices or Icecast itself. I decided to try running the same setup on
> Shoutcast today, and it's working perfectly. An hour of streaming at the
> time of this message, and absolutely no schedule deviation.
> It appears as though Shoutcast has better rate control than Icecast does
> at the moment or something.
> Thanks,
>
> Jordan.
>
> ------------------------------
> From: jv_erner at hotmail.com
> To: icecast at xiph.org
> Date: Sun, 25 May 2014 10:03:10 -0400
>
> Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a strict
> schedule?
>
> Hello,
> Regarding accounting for track lengths, could sox (soxi) be getting it
> wrong?
> Here's my approach atm:
> $lengths = array();
> foreach($files as $val)
> {
> //Note that $files has already been populated by glob()
> $temp = explode(":", shell_exec('soxi -d "'.$val.'"'));
> $length = $temp[0] * 60 * 60;//convert the hours to seconds.
> $length += ($temp[1] * 60);//convert minutes to seconds
> $length += $temp[2];//add the seconds
> $length *= 1000;//convert to milliseconds.
>
> $lengths[$val] = $length;
> }
> With that done, I can retrieve lengths like this:
> $test = $lengths["/home/caturria/songs/etc.ogg"];
> I'm going to try subtracting a tenth of a second or so from these values
> just to see if I can get slightly more sane results.
> Thanks,
>
> Jordan.
>
> ------------------------------
> Date: Sun, 25 May 2014 13:23:09 +0000
> From: thomas at ruecker.fi
> To: icecast at xiph.org
> Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a strict
> schedule?
>
> On 05/25/2014 01:13 PM, Jordan Verner wrote:
>
> Icecast and Ices are running on the same machine and it is a dedicated
> server.
> It is a Xeon 1270 V2 CPU with 16 GB ram running Centos 64-bit.
> Any thoughts on which settings I could try next? I have tried everything
> that appears to relate to the speed at which the stream occurs to no avail.
> One point I forgot to mention is that some tracks bring on more deviation
> than others. Shorter tracks, like spots, through it off more than longer
> tracks (I think). There are definitely tracks that inflict this effect more
> than others.
>
>
> I'm going to revise my guess. It's probably inaccuracies in how you
> account for track length in your system. But ultimately it's irrelevant.
> I'd suggest to explore the idea of a filler jingle, as pointed out
> earlier. If you want to get fancy, you can even have several to dynamically
> chose to adjust for the offset more accurately. Although, I'm going to say
> that this is overkill and a 10s jingle/sound file should be just fine, also
> most listener software will have a buffer of 10-60s anyway, so being "on
> the dot" doesn't really come out right anyway. If you want silence, then
> please note that you should use very low level noise instead of digital
> silence. For the listener it will be indistinguishable, as the noise will
> probably be below the noise floor of their sound card, but for the vorbis
> encoder this makes a crucial difference. Digital silence compresses down to
> single bits per second and will lead to source timeouts and ill effects in
> listener software and should be avoided at all cost when streaming.
>
>
>  I haven't experienced any other timing oddities on the machine.
>
>
> If you can live with the above, then I'd suggest to take that route.
>
> Cheers
>
> TBR
>
>
>
> > Date: Sun, 25 May 2014 07:05:42 +0000
> > From: thomas at ruecker.fi
> > To: icecast at xiph.org
> > Subject: Re: [Icecast] Keeping icecast + ices 2.X running on a strict
> schedule?
> >
> > Hi,
> >
> > On 05/24/2014 11:29 PM, Jordan Verner wrote:
> > > I'm using Icecast, Ices, and the script module configuration to serve
> > > the playlist to the server. Playlists are scheduled once per day with
> > > regularely placed events (like spots) which run at specific times.
> > > Unfortunately it's being served too fast, so it's always getting ahead
> > > of schedule (gaining about 10 seconds on every hour).
> >
> > Sounds like the clocking is faster for some reason.
> >
> > > I have tried adjusting the flush-samples setting in ices.xml and the
> > > queue size in the icecast.xml file to no avail.
> > > I've had to resort to implementing a forced delay into the php script
> > > which feeds the filenames to ices, so that if ices calls it
> > > significantly early it'll wait to issue the next filename until it's
> > > closer to it's scheduled start time. This was causing disconnects
> > > whenever it became deviated beyond 10 seconds. Disabling source
> > > timeout fixed this, but still it tries to get as far ahead as
> > > physically possible and takes as much wiggle room as I give it plus
> more.
> >
> > That won't fix it. You're inserting gaps into the stream and that's a
> > bad thing for your listeners too.
> >
> > > Is there any fix for this? Streaming for 24 hours would have it
> > > calling the script as much as 4 minutes ahead of schedule, forcing my
> > > script to hang for all that time before issuing each and every
> filename.
> > > This is way too much deviation for streams which stick to a schedule.
> > > Two weeks of streaming would have everything an hour early.
> >
> > So for some reason on your system Ices is running 0.28% faster. I'm not
> > sure what causes this and where those samples go. Is it by chance a
> > virtual machine?
> >
> > You can try to fiddle further with ices settings. If that doesn't fix it
> > then you could always have your script insert a 10s filler jingle if it
> > detects that you're out of the timeframe.
> >
> > Other options would be to explore different automation solutions, but
> > they might suffer the same problem if it's some underlying clock oddity
> > on your system.
> >
> > Cheers
> >
> > Thomas
> > _______________________________________________
> > Icecast mailing list
> > Icecast at xiph.org
> > http://lists.xiph.org/mailman/listinfo/icecast
>
>
> _______________________________________________
> Icecast mailing listIcecast at xiph.orghttp://lists.xiph.org/mailman/listinfo/icecast
>
>
>
> _______________________________________________ Icecast mailing 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/20140526/82e87080/attachment.htm>

From vbvbrj at gmail.com  Wed May 28 06:13:35 2014
From: vbvbrj at gmail.com (Mimiko)
Date: Wed, 28 May 2014 09:13:35 +0300
Subject: [Icecast] Compiling icecast with custom libxml2.
Message-ID: <53857E8F.5040900@gmail.com>

Hello.

I've compiled libxml2 v.2.9.1 and libxslt v.1.1.28 in /opt. When 
compiling icecast I can specify --with-xslt-config=/opt/libxslt but can 
not specify the path to libxml2. The compiling fails as in system is 
installed libxml2 v.2.8.0 which seems incompatible with libxslt v.1.1.28.

Could developers add a configure option to specify libxml2 location?

-- 
Mimiko desu.