From abitar.com at gmail.com  Sat Nov  1 05:13:44 2008
From: abitar.com at gmail.com (David Saunders)
Date: Sat, 1 Nov 2008 01:13:44 -0400
Subject: [Icecast] How to killsource from command line?
In-Reply-To: <86a338140810271235x3190ab2bq56996c1153c72abb@mail.gmail.com>
References: <86a338140810271235x3190ab2bq56996c1153c72abb@mail.gmail.com>
Message-ID: <6f779c410810312213j3b76b17ck2c5ad4ea02e4bca1@mail.gmail.com>

They should work :P

but if it the local server  try using 127.0.0.1 for the server name
instead, lot of server are not configure correctly to know what their
address is.

also the syntax  user:Pass at servername    should work also.

I use it allot on a remote control server to force a client to drop.
But one thing you have to make sure is that they not on reconnect in
the client or it will reconnect with in a few seconds.

Also I would add their source IP into the firewall setting for a
temporary ban to the server.  . but that is a totally different.

Also i work with one where i would update the server with a new
username/password fot the mount and reload the server (not reset the
server) then kick them , this will keep them from getting back on.

David

On Mon, Oct 27, 2008 at 3:35 PM,  <chiapas at aktivix.org> wrote:
> Hi
>
> Apologies - this is more of a bash question than an Icecast question.
> When I visit the listmounts.xsl page for my Icecast server, for
> example here:
>
> http://icecast.example.com:8000/admin/listmounts.xsl
>
> I see that each mountpoint is listed like so:
>
>> Mount Point : (/example.mp3)
>> List Clients | Move Listeners |  Update Metadata | Kill Source
>>
>> 35 Listener(s)
>
> The code for the "Kill Source" link resembles something like this:
>
> http://icecast.example.com:8000/admin/killsource.xsl?mount=/example.mp3
>
> So is there a way of invoking this URL from bash - perhaps like this:
>
> lynx -auth user:password
> http://icecast.example.com:8000/admin/killsource.xsl?mount=/example.mp3
>
> Only the above doesn't work.
>
> I would use this for the automated detaching of unwanted mountpoints,
> perhaps in a cron job.
>
> Many thanks in advance.
>
> Chip Scooter
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>


From chiapas at aktivix.org  Sun Nov  2 21:44:34 2008
From: chiapas at aktivix.org (chiapas at aktivix.org)
Date: Sun, 2 Nov 2008 21:44:34 +0000
Subject: [Icecast] How to killsource from command line?
In-Reply-To: <6f779c410810312213j3b76b17ck2c5ad4ea02e4bca1@mail.gmail.com>
References: <86a338140810271235x3190ab2bq56996c1153c72abb@mail.gmail.com>
	<6f779c410810312213j3b76b17ck2c5ad4ea02e4bca1@mail.gmail.com>
Message-ID: <86a338140811021344n7911276ak631c4e371b6c1a0d@mail.gmail.com>

Hi

Many thanks for the helpful replies.

Please see below.

2008/11/1 David Saunders <abitar.com at gmail.com>:
> They should work :P
>
> but if it the local server  try using 127.0.0.1 for the server name
> instead, lot of server are not configure correctly to know what their
> address is.
>
> also the syntax  user:Pass at servername    should work also.

Doesn't yet work for me.

I've tried this from the CLI and it just returns me to a cursor thus:

[root at example ~]# lynx -auth user:password
http://127.0.0.1:8000/admin/killsource.xsl?mount=/example.mp3
>

Same using curl and wget, for example:

[root at example ~]# curl
http://user:password at 127.0.0.1:8000/admin/killsource.xsl?mount=/example.mp3
>

> I use it allot on a remote control server to force a client to drop.
> But one thing you have to make sure is that they not on reconnect in
> the client or it will reconnect with in a few seconds.

Good point.

> Also I would add their source IP into the firewall setting for a
> temporary ban to the server.  . but that is a totally different.

Yes, I am having success with iptables - I have effectively solved my
problem this way but for curiosity's sake I am interested in using
lynx/curl/wget.

> Also i work with one where i would update the server with a new
> username/password fot the mount and reload the server (not reset the
> server) then kick them , this will keep them from getting back on.

Good point but I'm trying to avoid restarting Icecast and dropping all
other active connections - and I presume "killall -HUP icecast" will
_not_ drop the unwanted mountpoint.

> David

Many thanks

Chip Scooter


From lengyel at gmail.com  Mon Nov  3 03:40:58 2008
From: lengyel at gmail.com (FL)
Date: Sun, 2 Nov 2008 22:40:58 -0500
Subject: [Icecast] reloading configuration in icecast chroot jail on a
	redhat system
Message-ID: <d170611f0811021940k5049c2bx60b9324426eacee9@mail.gmail.com>

Hi,

Over the weekend I decided to create an icecast relay for Nicecast. I wanted
this to run in a
chroot jail on a redhat server. There did not seem to be much on the web
about  setting this up;
I'm including some details here. This is my first encounter with icecast;
I'm  hoping to
elicit comments and criticism (e.g., if my post is too long).

First, there did not seem to be a startup script for Red Hat compatible with
chkconfig, much less
such a script with a reload section; I include mine. This handles reloading
the configuration--I'm
wondering if there is a better way to do this.

Also, I have another problem: I want an off the air loop to play exactly
once, after which the
user is disconnected. However, the loop plays indefinitely.

First, here is the startup script (I call this icectl); my configuration
chroots icecast to
/usr/local/share/icecast. The relevant case is reload)

!/bin/sh
#
#
# chkconfig: 2345 70 40
# description: icecast startup script
#
ICECAST=/usr/local/bin/icecast
ICECONFIG=/usr/local/etc/icecast.xml
ICEPIDFILE=/usr/local/share/icecast/icecast.pid

. /etc/rc.d/init.d/functions

RETVAL=0

case "$1" in
   start)
      echo -n "Starting icecast: "
      [ -f $ICECAST ] || exit 1
      [ -f $ICECONFIG ] || exit 1

      daemon --pidfile=$ICEPIDFILE $ICECAST -b -c $ICECONFIG > /dev/null
      RETVAL=$?
      echo
      [ $RETVAL -eq 0 ] && touch /var/lock/subsys/icecast
        ;;

  stop)
      echo -n "Shutting down icecast: "
      killproc -p $ICEPIDFILE $ICECAST
      RETVAL=$?
      echo
      [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/icecast
        ;;

  restart)
        $0 stop
        $0 start
        RETVAL=$?
        ;;

  reload)
        echo -n "Reloading icecast configuration: "
        killproc -p $ICEPIDFILE $ICECAST -HUP
        RETVAL=$?
        echo
        ;;

  status)
        status -p $ICEPIDFILE icecast
        RETVAL=$?
        ;;
  *)
        echo "Usage: $0 {start|stop|restart|reload|status}"
        exit 1
esac

exit $RETVAL

The first problem I had with the reload function is that the location of
the configuration file, /usr/local/etc/icecast.xml, is inaccessible
once the process is chrooted. I resolved this by moving the configuration
file to /usr/local/share/icecast/usr/local/etc/icecast.xml and setting a
symbolic
link to this in /usr/local/etc/. This enabled the icecast process to read
the
configuation on startup, and subsequently relative to the jail root of
/usr/local/share/icecast.

The next problem was that /etc/mime.types was inaccessible after a reload,
but this was fixed by copying this file to /usr/local/share/icecast/etc.
Before adding the mime.types, the /usr/local/share/icecast/etc directory
contained

[root at myhost etc]# ls -latrs
total 56
8 -rw-r--r-- 1 nobody nogroup  113 Nov  1 21:08 resolv.conf
8 -rw-r--r-- 1 nobody nogroup   38 Nov  1 21:28 passwd
8 -rw-r--r-- 1 nobody nogroup   17 Nov  1 21:28 group
8 -rw-r--r-- 1 nobody nogroup 1693 Nov  1 21:42 nsswitch.conf
8 drwxr-xr-x 9 nobody nogroup 4096 Nov  1 21:50 ..
8 -rw-r--r-- 1 nobody nogroup  607 Nov  1 21:58 hosts
8 drwxr-xr-x 2 nobody nogroup 4096 Nov  1 21:58 .

Where the files were edited to contain (close to) the minimum necessary.
For example, passwd and group were obtained with
  getent passwd nobody > passwd
  getent group  nogroup > group
and nsswitch.conf had all references to ldap removed.

/etc/hosts was copied to /usr/local/share/icecast/etc/hosts, and most
entries were removed; however I added an entry for dir.xiph.org. No doubt
I did not completely populate my chroot jail with all the needed libraries,
since
I seemed to need this hosts file entry for the lookup to succeed.


The lib directory was populated using the ldd command to locate
needed libraries; symbolic links were added as needed

[root at myhost etc]# ldd /usr/local/bin/icecast libcurl.so.2 =>
/opt/grid/prima
/lib/libcurl.so.2 (0x00002b3811c8b000)
        libssl.so.6 => /lib64/libssl.so.6 (0x0000003a01200000)
        libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00000039fc400000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00000039f4400000)
        libvorbis.so.0 => /usr/lib64/libvorbis.so.0 (0x00000039f5800000)
        libxslt.so.1 => /usr/lib64/libxslt.so.1 (0x0000003d14400000)
        libxml2.so.2 => /opt/grid/apache/lib/libxml2.so.2
(0x00002b3811ed4000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00000039f4c00000)
        libm.so.6 => /lib64/libm.so.6 (0x00000039f4000000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00000039f4800000)
        libc.so.6 => /lib64/libc.so.6 (0x00000039f3c00000)
        libogg.so.0 => /usr/lib64/libogg.so.0 (0x00002b381227e000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2
(0x00000039ff6000
00)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00000039fc800000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00000039f9000000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00000039fb000000)
        /lib64/ld-linux-x86-64.so.2 (0x00000039f3800000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0
(0x00000039ffa000
00)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00000039fee00000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00000039fa000000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00000039f5400000)
        libsepol.so.1 => /lib64/libsepol.so.1 (0x00002b3812487000)

The libraries were copied with

for file in $(ldd /usr/local/bin/icecast | awk '{print $3}'); do
        cp $file lib;
done


For name resolution, additional libraries were needed in lib

  cp /lib/libnss_files-2.5.so .
  ln -s libnss_files-2.5.so libnss_files.so.2

  cp /lib/libnss_dns-2.5.so .
  ln -s libnss_dns-2.5.so libnss_dns.so.2

I may need to include directories for locales since the time logged is in
UTC.

This whole procedure follows the typical thing one does for jailing apache
or bind.

-----------------------------------------------------------------------

Now with the reload function working in the chroot jail, I was able to
experiment
with changing the icecast.xml configuration without restarting the server
and breaking
connections.

But, the following <mount> sections in my icecast.xml configuration left me
with
the mount point OffTheAir.mp3 looping indefinitely

<mount>
        <mount-name>/listen</mount-name>
        <!-- Not known how to avoid an infinite loop
             with a short fallback mount. Setting
             max-listener-duration did not work
          -->
        <fallback-mount>OffTheAir.mp3</fallback-mount>
        <fallback-override>1</fallback-override>
        <intro>/intro.mp3</intro>
    </mount>

    <mount>
        <mount-name>/OffTheAir.mp3</mount-name>
        <max-listener-duration>3</max-listener-duration>
        <hidden>1</hidden>
    </mount>


I wanted the fallback mountpoint to play once, and then disconnect the user.
However, the  <max-listener-duration> parameter seems to work only for
connections directly to the OffTheAir.mp3 mountpoint, but not if this is
the fallback mountpoint.

Thanks for bearing with me.

FL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20081102/1a342253/attachment.htm>

From Geoff at QuiteLikely.com  Mon Nov  3 08:46:16 2008
From: Geoff at QuiteLikely.com (Geoff Shang)
Date: Mon, 3 Nov 2008 10:46:16 +0200 (IST)
Subject: [Icecast] reloading configuration in icecast chroot jail on a
 redhat system
In-Reply-To: <d170611f0811021940k5049c2bx60b9324426eacee9@mail.gmail.com>
References: <d170611f0811021940k5049c2bx60b9324426eacee9@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0811031042570.3513@data.home>

FL wrote:

> Also, I have another problem: I want an off the air loop to play exactly
> once, after which the
> user is disconnected. However, the loop plays indefinitely.

hmmm.  You could achieve this using aliases I guess.  You could have an 
alias that pointed to the stream when it is up and to your off the air 
message when it isn't, and have on-connect and on-disconnect events be 
scripts to make the appropriate changes and reload the config.

Geoff.



From lengyel at gmail.com  Mon Nov  3 16:29:02 2008
From: lengyel at gmail.com (FL)
Date: Mon, 3 Nov 2008 11:29:02 -0500
Subject: [Icecast] reloading configuration in icecast chroot jail on a
	redhat system
In-Reply-To: <Pine.LNX.4.64.0811031042570.3513@data.home>
References: <d170611f0811021940k5049c2bx60b9324426eacee9@mail.gmail.com>
	<Pine.LNX.4.64.0811031042570.3513@data.home>
Message-ID: <d170611f0811030829i21b9baa6q693bed010a27fff0@mail.gmail.com>

How would that be implemented?  What is the syntax for using an alias in
icecast
to point to a stream? How do you detect when it is up?

The kind of fallback message I would like would be an announcement when
the next scheduled program would run...

In any case, I have noticed that <max-listener-duration> works in a mount
point
that the user connects to directly, and not through the fallback-mount
mechanism.
A <play-once-then-disconnect> tag would be nice (defaulted to 0 for all
mount
points); and unlike <max-listener-duration>, this should work even for a
<fallback-mount>. Perhaps I should consider modifying the source.

Loading alternate config files when the main stream disconnects does not
sound as if it would scale very well...

On Mon, Nov 3, 2008 at 3:46 AM, Geoff Shang <Geoff at quitelikely.com> wrote:

> FL wrote:
>
> > Also, I have another problem: I want an off the air loop to play exactly
> > once, after which the
> > user is disconnected. However, the loop plays indefinitely.
>
> hmmm.  You could achieve this using aliases I guess.  You could have an
> alias that pointed to the stream when it is up and to your off the air
> message when it isn't, and have on-connect and on-disconnect events be
> scripts to make the appropriate changes and reload the config.
>
> Geoff.
>
> _______________________________________________
> 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/20081103/47d98e4d/attachment.htm>

From toots at rastageeks.org  Sun Nov  9 23:42:34 2008
From: toots at rastageeks.org (Romain Beauxis)
Date: Mon, 10 Nov 2008 00:42:34 +0100
Subject: [Icecast] Ogg skeletons with speex and vorbis..
Message-ID: <200811100042.34780.toots@rastageeks.org>

	Hi all !

While implementing skeleton support in our application, I came to issue that 
ogg speex and vorbis streams do not seem to work on icecast with a skeleton.

The symptoms are that data is sent, and icecast accepts it, but nothing can be 
received by listeners, or even simply dumped.

You can find two test streams there:
  http://www.rastageeks.org/~toots/icecast/

The issue can be reproduced with oggfwd for instance. So far, I couldn't spot 
an issue in our generated ogg streams, with ogginfo, or the oggz tools.


Romain


From abitar.com at gmail.com  Mon Nov 10 00:53:20 2008
From: abitar.com at gmail.com (David Saunders)
Date: Sun, 9 Nov 2008 19:53:20 -0500
Subject: [Icecast] How to killsource from command line?
In-Reply-To: <86a338140811021344n7911276ak631c4e371b6c1a0d@mail.gmail.com>
References: <86a338140810271235x3190ab2bq56996c1153c72abb@mail.gmail.com>
	<6f779c410810312213j3b76b17ck2c5ad4ea02e4bca1@mail.gmail.com>
	<86a338140811021344n7911276ak631c4e371b6c1a0d@mail.gmail.com>
Message-ID: <6f779c410811091653p36ebfef6g1aa445da5fc5e837@mail.gmail.com>

I use the command thru curl( since i set up http links in php using curl)
http://{adminname}:{adminpass}@{server}:8000/admin/killsource.xsl?mount={mountname}

and it will work, but if the source client is set up for reconnect its
possible it will be back before you can verify it gone, just look at
stream_start to see if it was changed :) THe source clients we use for
most of our streams reconnect soon as they loose connection then if
they cant it goes into a countdown to try again.

Since i use fedora I use the init.d command to reload after i updated
the icecast.xml with a new password.  Then i kick the source. Using
the above command.
David


On Sun, Nov 2, 2008 at 4:44 PM,  <chiapas at aktivix.org> wrote:
> Hi
>
> Many thanks for the helpful replies.
>
> Please see below.
>
> 2008/11/1 David Saunders <abitar.com at gmail.com>:
>> They should work :P
>>
>> but if it the local server  try using 127.0.0.1 for the server name
>> instead, lot of server are not configure correctly to know what their
>> address is.
>>
>> also the syntax  user:Pass at servername    should work also.
>
> Doesn't yet work for me.
>
> I've tried this from the CLI and it just returns me to a cursor thus:
>
> [root at example ~]# lynx -auth user:password
> http://127.0.0.1:8000/admin/killsource.xsl?mount=/example.mp3
>>
>
> Same using curl and wget, for example:
>
> [root at example ~]# curl
> http://user:password at 127.0.0.1:8000/admin/killsource.xsl?mount=/example.mp3
>>
>
>> I use it allot on a remote control server to force a client to drop.
>> But one thing you have to make sure is that they not on reconnect in
>> the client or it will reconnect with in a few seconds.
>
> Good point.
>
>> Also I would add their source IP into the firewall setting for a
>> temporary ban to the server.  . but that is a totally different.
>
> Yes, I am having success with iptables - I have effectively solved my
> problem this way but for curiosity's sake I am interested in using
> lynx/curl/wget.
>
>> Also i work with one where i would update the server with a new
>> username/password fot the mount and reload the server (not reset the
>> server) then kick them , this will keep them from getting back on.
>
> Good point but I'm trying to avoid restarting Icecast and dropping all
> other active connections - and I presume "killall -HUP icecast" will
> _not_ drop the unwanted mountpoint.
>
>> David
>
> Many thanks
>
> Chip Scooter
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>


From sviluppo at audiias.com  Thu Nov 13 00:59:02 2008
From: sviluppo at audiias.com (=?UTF-8?B?UGllcnBhb2xvIGd1bGzCiGE=?=)
Date: Thu, 13 Nov 2008 01:59:02 +0100
Subject: [Icecast] icecast documentation in pdf format
Message-ID: <491B7BD6.9020104@audiias.com>

Hi guys ,

I want to stdy better the good icecast2 documentation , so I want to 
print it , do you know a site where I can find it in pdf format or similar?

Thanks for the help

Bye

Pierpaolo




From chiapas at aktivix.org  Thu Nov 13 21:26:11 2008
From: chiapas at aktivix.org (chiapas at aktivix.org)
Date: Thu, 13 Nov 2008 21:26:11 +0000
Subject: [Icecast] icecast documentation in pdf format
In-Reply-To: <491B7BD6.9020104@audiias.com>
References: <491B7BD6.9020104@audiias.com>
Message-ID: <86a338140811131326p64298d74o3501f97f1d041271@mail.gmail.com>

2008/11/13 Pierpaolo gull?a <sviluppo at audiias.com>:
> Hi guys ,

Hi

> I want to stdy better the good icecast2 documentation , so I want to
> print it , do you know a site where I can find it in pdf format or similar?

Not PDF but this should help.

http://www.gnuware.com/icecast/

> Thanks for the help

No problem.

> Bye
>
> Pierpaolo

Bye

Chip

From petr.pisar at atlas.cz  Wed Nov 19 19:01:10 2008
From: petr.pisar at atlas.cz (Petr Pisar)
Date: Wed, 19 Nov 2008 19:01:10 +0000 (UTC)
Subject: [Icecast] Icecast 2.3.2 doesn't list all mount points
Message-ID: <slrngi8ojm.nul.petr.pisar@album.ics.muni.cz>

Hello,

I've upgraded from 2.3.1 to 2.3.2. I've been used to list all mount
points by <xsl:for-each select="source"/> under /icestats.

Howver now the /icestats elemets contains only source elemets which have
been requested at least once. That means the list (e.g. /stats.xsl under
web directory) is empty after server start.

I've found out this regresion presents only in stylesheets from web
directory. If I copy a stylsheet into admin directory then I get list of
all mount points.

I'd like note I use on-demand mount points.

Is it a bug or a feature? How can I get list of all mount points in
Icecast 2.3.2?

-- Petr




From karl at xiph.org  Thu Nov 20 13:51:30 2008
From: karl at xiph.org (Karl Heyes)
Date: Thu, 20 Nov 2008 13:51:30 +0000
Subject: [Icecast] Icecast 2.3.2 doesn't list all mount points
In-Reply-To: <slrngi8ojm.nul.petr.pisar@album.ics.muni.cz>
References: <slrngi8ojm.nul.petr.pisar@album.ics.muni.cz>
Message-ID: <49256B62.4090201@xiph.org>

Petr Pisar wrote:
> Hello,
> 
> I've upgraded from 2.3.1 to 2.3.2. I've been used to list all mount
> points by <xsl:for-each select="source"/> under /icestats.
> 
> Howver now the /icestats elemets contains only source elemets which have
> been requested at least once. That means the list (e.g. /stats.xsl under
> web directory) is empty after server start.
> 
> I've found out this regresion presents only in stylesheets from web
> directory. If I copy a stylsheet into admin directory then I get list of
> all mount points.
> 
> I'd like note I use on-demand mount points.
> 
> Is it a bug or a feature? How can I get list of all mount points in
> Icecast 2.3.2?

Can you verify whether this is resolved in the trunk code. I did fix a 
couple of issues from 2.3.2 in this area. Does the mount details appear 
after the stream has started at least once?

karl.




From petr.pisar at atlas.cz  Thu Nov 20 14:33:56 2008
From: petr.pisar at atlas.cz (Petr Pisar)
Date: Thu, 20 Nov 2008 14:33:56 +0000 (UTC)
Subject: [Icecast] Icecast 2.3.2 doesn't list all mount points
References: <slrngi8ojm.nul.petr.pisar@album.ics.muni.cz>
	<49256B62.4090201@xiph.org>
Message-ID: <slrngiatak.cld.petr.pisar@album.ics.muni.cz>

On 2008-11-20, Karl Heyes <karl at xiph.org> wrote:
> Petr Pisar wrote:
>> Hello,
>> 
>> I've upgraded from 2.3.1 to 2.3.2. I've been used to list all mount
>> points by <xsl:for-each select="source"/> under /icestats.
>> 
>> Howver now the /icestats elemets contains only source elemets which have
>> been requested at least once. That means the list (e.g. /stats.xsl under
>> web directory) is empty after server start.
>> 
>> I've found out this regresion presents only in stylesheets from web
>> directory. If I copy a stylsheet into admin directory then I get list of
>> all mount points.
>> 
>> I'd like note I use on-demand mount points.
>> 
>> Is it a bug or a feature? How can I get list of all mount points in
>> Icecast 2.3.2?
>
> Can you verify whether this is resolved in the trunk code. I did fix a 
> couple of issues from 2.3.2 in this area. Does the mount details appear 
> after the stream has started at least once?
>
Great. Trunk revision r15462 is not affected.

Is it possible (easy) to isolate the fix to patch 2.3.2 or is the trunk
code good enoung for reguler usage?

-- Petr



From petr.pisar at atlas.cz  Thu Nov 20 15:10:06 2008
From: petr.pisar at atlas.cz (Petr Pisar)
Date: Thu, 20 Nov 2008 15:10:06 +0000 (UTC)
Subject: [Icecast] Icecast 2.3.2 doesn't list all mount points
References: <slrngi8ojm.nul.petr.pisar@album.ics.muni.cz>
	<49256B62.4090201@xiph.org>
	<slrngiatak.cld.petr.pisar@album.ics.muni.cz>
Message-ID: <slrngiavee.cld.petr.pisar@album.ics.muni.cz>

On 2008-11-20, Petr Pisar <petr.pisar at atlas.cz> wrote:
> On 2008-11-20, Karl Heyes <karl at xiph.org> wrote:
>>
>> Can you verify whether this is resolved in the trunk code. I did fix a 
>> couple of issues from 2.3.2 in this area. Does the mount details appear 
>> after the stream has started at least once?
>>
> Great. Trunk revision r15462 is not affected.
>
> Is it possible (easy) to isolate the fix to patch 2.3.2 or is the trunk
> code good enoung for reguler usage?
>
I think revision r15122 fixes this bug.

-- Petr



From abitar.com at gmail.com  Thu Nov 20 18:21:51 2008
From: abitar.com at gmail.com (David Saunders)
Date: Thu, 20 Nov 2008 13:21:51 -0500
Subject: [Icecast] hardware / bandwidth requirements
In-Reply-To: <fb626f6f0810052000s7dcf269cib63d01b681537cf@mail.gmail.com>
References: <fb626f6f0810052000s7dcf269cib63d01b681537cf@mail.gmail.com>
Message-ID: <6f779c410811201021v6a83fda1y23b793f1be70b0cc@mail.gmail.com>

My rule of thumbs is look at the bitrate,  Multiply it by the number
of users and ad 10% as a rule. Then you migth have to tweek it around
alittle. For example we tdo lot of of mono audio brodcasts. at 24k,
and have found out using decated servers we can eastly handle 80 to 90
listeners on a 1M bandwith connection(a cable modem).

I found is the slow listeners start to climb up your reaching the max
you setup can handle. Or there is somehting wrong with the internet
connection.

But this is one kind of bandwidth, The other kind of bandwidth is base
on a month scale,   Then you need to use there caulating tools to
figure out what bandwidth you will use. I have found deferent companys
calculate it deferently. And there is not real rule to go by other
then check htere tools.

WE have managed to squeeze 4 256k videops on out 1M lines but it was a
tight squeeze on a good day, we usely out source to couple of places
that have beter coonectiosn to the internet.

When they finialy install FIOS here we will be elimating lot of our
oursourcing with luck. :)


On Sun, Oct 5, 2008 at 10:00 PM, Gabriel Zea <z3a at randomlab.net> wrote:
> Hi there!!
>
> Any body can drop me some information about the hardware and bandwidth
> requirements  to setup an icecast server to stream real time video
> using OGG/Theora? I'll  setup an production server, and need to
> calculate an estimate number of  maximum clients connections to the
> server.
>
> thanks in advance,
>
> zea
>
>
>
> --
> Gabriel Zea
> mailTo <zeaATrandomlabDOTnet>
> http://zea.randomlab.net
> http://twitter.com/z3a
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>