From kg84 at dreamwld.com  Wed Jul 13 18:29:23 2011
From: kg84 at dreamwld.com (Kristoffer Gustafsson)
Date: Wed, 13 Jul 2011 20:29:23 +0200
Subject: [Icecast] router help
Message-ID: <002b01cc418a$c9d89b50$0300a8c0@farfar>

Hi.
I think that I've got some prolems with my netgear router.
When I try to play the stream on my own computer it works very well, with http://localhost:8000/stream.ogg
Also, if replasing localhost with the ip adress of the computer it works.
But when trying to access it from outside it doesn't work.
I've opened up port 8000 and 8001 on my router.
Any idea what can be wrong?
Can I have missed something in my netgear router?
/Kristoffer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20110713/68f5223b/attachment.htm>

From sascha.bieler at radiogong.de  Wed Jul 13 18:46:55 2011
From: sascha.bieler at radiogong.de (Sascha Bieler)
Date: Wed, 13 Jul 2011 20:46:55 +0200
Subject: [Icecast] Antw.:  router help
Message-ID: <C76F81AA-0071-4892-853B-538CCBC04887@radiogong.de>

You have to use NAT or port forwarding to your icecast server.

Regards

Sash

----- Reply message -----
Von: "Kristoffer Gustafsson" <kg84 at dreamwld.com>
Datum: Mi., Jul. 13, 2011 20:29
Betreff: [Icecast] router help
An: "icecast at xiph.org" <icecast at xiph.org>

Hi.
I think that I've got some prolems with my netgear router.
When I try to play the stream on my own computer it works very well, with http://localhost:8000/stream.ogg
Also, if replasing localhost with the ip adress of the computer it works.
But when trying to access it from outside it doesn't work.
I've opened up port 8000 and 8001 on my router.
Any idea what can be wrong?
Can I have missed something in my netgear router?
/Kristoffer


*** Email secured by Check Point ***


________________________________
Radio Gong 2000 Programmanbieter GmbH & Co. H?rfunk f?r M?nchen KG
Sitz: Franz-Joseph-Stra?e 14, 80801 M?nchen
Handelsregister M?nchen HRA 64203
USt-IdNr. DE130253082
Pers?nlich haftende Gesellschafterin: Radio Gong 2000 Programmanbieter GmbH
Gesch?ftsf?hrer: Georg Dingler
fon 089 - 38 166 0
home http://www.radiogong.de
mail info at radiogong.de

Diese Information ist ausschlie?lich f?r den Adressaten bestimmt und kann vertraulich oder gesetzlich gesch?tzte Informationen enthalten. Wenn Sie nicht der bestimmungsgem??e Adressat sind, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Anderen als dem bestimmungsgem??en Adressaten ist es untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. Wir verwenden aktuelle Virenschutzprogramme. F?r Sch?den, die dem Empf?nger gleichwohl durch von uns zugesandte mit Viren befallene E-Mails entstehen, schlie?en wir jede Haftung aus.

The information contained in this email is intended only for its addressee and may contain confidential and/or privileged information. If the reader of this email is not the intended recipient, you are hereby notified that reading, saving, distribution or use of the content of this email in any way is prohibited. If you have received this email in error, please notify the sender and delete the email. We use updated antivirus protection software. We do not accept any responsibility for damages caused anyhow by viruses transmitted via email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20110713/fbb10ad4/attachment.htm>

From raylutz at cognisys.com  Tue Jul 19 17:49:37 2011
From: raylutz at cognisys.com (Raymond Lutz)
Date: Tue, 19 Jul 2011 10:49:37 -0700
Subject: [Icecast] Orphan threads with Cellphone (Blackberry) player
Message-ID: <4E25C3B1.4090400@cognisys.com>

Friends:

The icecast server is very robust, but has some goofiness with regard to 
use with cell-phone players. Has anyone else encountered these issues?

When I use a Blackberry to access the icecast stream, I get orphan and 
duplicate client threads.

Background:
 > testing with Blackberry Curve 9330
 > Access icecast stream by clicking on the link on the website:
http://www.airprogressive.org:8000/stream.m3u
 > Stream consists of mp3 at 32kbps / 22050 Hz.
 > Stock media player launches, stops at "Do you want to open or save 
the item."
 > No threads started yet (viewing "List Clients" page of icecast admin 
interface).
 > Click "open", stream begins playing.
 > Two threads are started instead of just one, always offset by 2 seconds.
     -- but sometimes only one thread starts.
 > FYI, Icecast config: <client-timeout>30</client-timeout>

Here is the output from the "List Clients" page of Icecast2 Admin

*IP*

	
*Seconds Connected*

	
*User Agent*

	
*Action*

68.7.238.55 	406 	WinampMPEG/5.62, Ultravox/2.1 	Kick 
<http://www.airprogressive.org:8000/admin/killclient.xsl?mount=/stream&id=2690> 

74.82.68.16 	6 	Mozilla/4.8 [en] (Windows NT 5.0; U) 	Kick 
<http://www.airprogressive.org:8000/admin/killclient.xsl?mount=/stream&id=2704> 

74.82.68.16 	4 	Mozilla/4.8 [en] (Windows NT 5.0; U) 	Kick 
<http://www.airprogressive.org:8000/admin/killclient.xsl?mount=/stream&id=2709> 



Note the last two entries with the same IP address. This is the 
Blackberry. Top entry is winamp player on PC for reference. Don't know 
why two listener threads are generated.

 > Stream is "Stopped" (i.e. click stop)
 > Stream is restarted (i.e. click Play)
 > A new thread is started, this time with a new +1 IP address.

*IP*

	
*Seconds Connected*

	
*User Agent*

	
*Action*

68.7.238.55 	687 	WinampMPEG/5.62, Ultravox/2.1 	Kick 
<http://www.airprogressive.org:8000/admin/killclient.xsl?mount=/stream&id=2690> 

74.82.68.16 	287 	Mozilla/4.8 [en] (Windows NT 5.0; U) 	Kick 
<http://www.airprogressive.org:8000/admin/killclient.xsl?mount=/stream&id=2704> 

74.82.68.16 	285 	Mozilla/4.8 [en] (Windows NT 5.0; U) 	Kick 
<http://www.airprogressive.org:8000/admin/killclient.xsl?mount=/stream&id=2709> 

74.82.68.17 	8 	Mozilla/4.8 [en] (Windows NT 5.0; U) 	Kick 
<http://www.airprogressive.org:8000/admin/killclient.xsl?mount=/stream&id=2718> 



I can understand that the player may continue to communicate when 
"stopped" to fill the lookahead buffer, but when it is restarted, it 
should use the same connection and not start a new one.


 > Click Stop.
 > Click Play.


*IP*

	
*Seconds Connected*

	
*User Agent*

	
*Action*

68.7.238.55 	803 	WinampMPEG/5.62, Ultravox/2.1 	Kick 
<http://www.airprogressive.org:8000/admin/killclient.xsl?mount=/stream&id=2690> 

74.82.68.16 	403 	Mozilla/4.8 [en] (Windows NT 5.0; U) 	Kick 
<http://www.airprogressive.org:8000/admin/killclient.xsl?mount=/stream&id=2704> 

74.82.68.16 	401 	Mozilla/4.8 [en] (Windows NT 5.0; U) 	Kick 
<http://www.airprogressive.org:8000/admin/killclient.xsl?mount=/stream&id=2709> 

74.82.68.17 	124 	Mozilla/4.8 [en] (Windows NT 5.0; U) 	Kick 
<http://www.airprogressive.org:8000/admin/killclient.xsl?mount=/stream&id=2718> 

74.82.68.18 	24 	Mozilla/4.8 [en] (Windows NT 5.0; U) 	Kick 
<http://www.airprogressive.org:8000/admin/killclient.xsl?mount=/stream&id=2735> 



 > Yet another thread  is started with a new "listener".
 > Click "back" to exit from browser in Blackberry.
 > All threads continue.
     --> I have tested this many times and the threads continue without 
being cleaned up indefinitely, even though the player is stopped and the 
stream is not "playing" on the handset.
 > Turn off mobile network. Handset not communicating.
 > Threads continue
 > Handheld turned off.

*IP*

	
*Seconds Connected*

	
*User Agent*

	
*Action*

68.7.238.55 	995 	WinampMPEG/5.62, Ultravox/2.1 	Kick 
<http://www.airprogressive.org:8000/admin/killclient.xsl?mount=/stream&id=2690> 

74.82.68.16 	595 	Mozilla/4.8 [en] (Windows NT 5.0; U) 	Kick 
<http://www.airprogressive.org:8000/admin/killclient.xsl?mount=/stream&id=2704> 

74.82.68.16 	593 	Mozilla/4.8 [en] (Windows NT 5.0; U) 	Kick 
<http://www.airprogressive.org:8000/admin/killclient.xsl?mount=/stream&id=2709> 

74.82.68.17 	316 	Mozilla/4.8 [en] (Windows NT 5.0; U) 	Kick 
<http://www.airprogressive.org:8000/admin/killclient.xsl?mount=/stream&id=2718> 

74.82.68.18 	216 	Mozilla/4.8 [en] (Windows NT 5.0; U) 	Kick 
<http://www.airprogressive.org:8000/admin/killclient.xsl?mount=/stream&id=2735> 




Finally, after over 300 seconds, the threads are finally cleaned up.

*IP*

	
*Seconds Connected*

	
*User Agent*

	
*Action*

68.7.238.55 	1139 	WinampMPEG/5.62, Ultravox/2.1 	Kick 
<http://www.airprogressive.org:8000/admin/killclient.xsl?mount=/stream&id=2690> 



So, to stop icecast server from communicating with the Blackberry 
handset, you must either turn it off or disable mobile network for at 
least 5 minutes.

It appears that the handset continues to transfer data (and therefore 
incur charges, if the user does not have an unlimited data plan) if the 
handset is not turned off or mobile network disabled for at least five 
minutes. It also runs down the battery much faster because the radio 
transmitter is actively being used, even if the user is not listening to 
the stream.

The Blackberry network has intervening servers that continue to receive 
data from the icecast server even if the handset is off. This behavior 
likely has utility to deal with the realities of the cellphone network, 
to allow the stream to be transferred from one cell to another, and deal 
with the possibility that the handset may be out of range for up to 5 
minutes without "interruption." However, it is hard to turn off the stream.

I looked at the icecast sourcecode and there is no use of cookies or any 
identifier (that I could see) when managing the listener threads.

QUESTIONS:
1. I am curious why two listener entries are created for each Blackberry 
listener. Ideas?
2. I don't have any theory as to why new threads are started even though 
the old threads persist. (they continue redundantly until the handset is 
turned off for at least 5 minutes, which appears only to bog down the 
icecast server with unnecessary listener threads). Ideas?
3. Is there any good way to deal with this? I was thinking the following 
might be possible:
     a. maintain a cookie on the user device (Blackberry Browser) 
related to each thread that is started.
     b. If the user attempts to start more than one thread, kill any old 
threads, update the cookie.
     c. Provide a way to kill the thread from the browser interface, 
such as sending a message to the server when the user exits the web 
page, utilizing cookie information.
     comments??

THANKS!

--Ray Lutz

-- 
---------------------------------------
Raymond Lutz
Cognisys, Inc.
1010 Old Chase Ave., Bldg B
El Cajon (San Diego Cty), CA 92020 USA
Voice 619-447-3246
http//www.cognisys.com

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

From raylutz at cognisys.com  Tue Jul 19 19:38:19 2011
From: raylutz at cognisys.com (Raymond Lutz)
Date: Tue, 19 Jul 2011 12:38:19 -0700
Subject: [Icecast] Orphan threads with Cellphone (Blackberry) player
In-Reply-To: <CAB=BY8vFGBkTj8ENYXgQDPGn7xQrZ8JyAVVn4QThkJfp7w6p+g@mail.gmail.com>
References: <4E25C3B1.4090400@cognisys.com>
	<CAB=BY8vFGBkTj8ENYXgQDPGn7xQrZ8JyAVVn4QThkJfp7w6p+g@mail.gmail.com>
Message-ID: <4E25DD2B.30606@cognisys.com>

Thanks Mike, for your prompt reply.

On 7/19/2011 11:12 AM, Michael Smith wrote:
> On Tue, Jul 19, 2011 at 10:49 AM, Raymond Lutz <raylutz at cognisys.com 
> <mailto:raylutz at cognisys.com>> wrote:
>
>     QUESTIONS:
>     1. I am curious why two listener entries are created for each
>     Blackberry listener. Ideas?
>
>
> Icecast doesn't make any attempt to ensure that only one connection is 
> made from any one IP - that can be entirely legitimate for many 
> reasons. This means two things are connecting to icecast. It could be 
> a blackberry bug.
I did not want to imply that it was always incorrect for the same IP 
address to be connected, but in this case, I know that it is the 
blackberry device and the earlier connections are orphans and 
unnecessary (because I've killed them and the device continues to play 
the stream.)
>
>     2. I don't have any theory as to why new threads are started even
>     though the old threads persist. (they continue redundantly until
>     the handset is turned off for at least 5 minutes, which appears
>     only to bog down the icecast server with unnecessary listener
>     threads). Ideas?
>
>
> You've consistently used "threads" here where there are most certainly 
> no additional threads being started. There are additional connections, 
> though. Icecast scales very well with more connections; it's not 
> really accurate to suggest that this "bogs down" the server.
("threads" is a term that is probably technically incorrect.)
Each listener connection "bogs down" the server to the extent that one 
additional worthless listener connection is being maintained. This means 
bandwidth being used that does no good. Have 10,000 blackberrys 
listening and it will be like 50,000 or 100,000 regular listeners. My 
calculations are that with the bandwidth I have allocated, I can stand 
21,000 listeners, but I have a feeling icecast will choke in some other 
way long before that.
>
> This is because something is keeping the connection alive. Probably a 
> blackberry problem.
Clearly, it is likely because we don't have a direct connection between 
the icecast server and the listener device since it goes through the 
wireless providers intermediate servers (in this case, Verizon), and 
they maintain the connection with icecast even though the final target 
device has dropped the connection.
>
>
>     3. Is there any good way to deal with this? I was thinking the
>     following might be possible:
>         a. maintain a cookie on the user device (Blackberry Browser)
>     related to each thread that is started.
>         b. If the user attempts to start more than one thread, kill
>     any old threads, update the cookie.
>         c. Provide a way to kill the thread from the browser
>     interface, such as sending a message to the server when the user
>     exits the web page, utilizing cookie information.
>         comments??
>
>
> You could build such an interface external to icecast, and manage 
> killing listeners through the admin interface. This doesn't belong 
> inside icecast. Note also that the vast majority of clients do NOT use 
> a full web stack to connect to icecast so cookies couldn't be used. If 
> you know the blackberry does, you can manage that externally.
Blackberry and most clients that I know of use cookies when they access 
my website page before a player is started. I don't know what they do 
once the player is started. (Computer-based players don't seem to have 
the problem I am reporting) and with that, it would be at least possible 
to do the cookie trick to allow the user to click on a disconnect button 
and stop the connection, as well as ensuring only one connection per user.

Another option I have been thinking of is making a App that could be 
downloaded in Blackberry App World and installed on the device. The 
stream would be started and "cleaned up" by the App when the user stops it.

So, in a general sense, is there any means for a given listener to know 
which connection they are on (i.e. the number which is not listed in the 
Admin "List Clients" display but is displayed when you kill a listener) 
and a way to kill the named listener?
>
> It'd be better to figure out why the blackberry is misbehaving and fix 
> that.
Indeed. And if someone has information about how to deal with this 
issue, that is what I am interested in finding out. It is not 
necessarily a problem with the icecast server component, but at the same 
time, if a cell-phone player does not work "out of the box" then 
something is wrong with the entire solution.

Blackberrys work this way, and so in a sense, they are not 
"misbehaving". This sort of behavior is what we will need to deal with, 
as it will be all but impossible to change the behavior of 70 million 
(or whatever the number is) players.

I note that on the Blackberry website, it does not support RTSP protocol 
for mp3 format.
http://docs.blackberry.com/en/smartphone_users/deliverables/18349/711-01774-123_Supported_Media_Types_on_BlackBerry_Smartphones.pdf

I wonder if you could comment on RTSP protocol and whether this may be 
the issue (although I was under the impression that icecast did not rely 
on RTSP protocol.)

THANKS!
--Ray

>
> Mike
>
>
>
>
>

-- 
---------------------------------------
Raymond Lutz
Cognisys, Inc.
1010 Old Chase Ave., Bldg B
El Cajon (San Diego Cty), CA 92020 USA
Voice 619-447-3246
http//www.cognisys.com

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

From stargate7thsymbol at live.co.uk  Sun Jul 24 07:34:52 2011
From: stargate7thsymbol at live.co.uk (Me Myself and I)
Date: Sun, 24 Jul 2011 18:04:52 +1030
Subject: [Icecast] Questions about ICAST and Web Development
Message-ID: <BAY159-W24C6A22EEBDC71176CD283D0300@phx.gbl>


-HOW does ICECAST stream content?  
-Can it stream sound being spoken live over a microphone?
-Can this live audio be streamed in an MP3 format?
-Can this audio be streamed to HTTP Web browsers (including XMLHttpRequest techniques)?
-How does an HTML file being served by Apache/Tomcat best set up
 so that the browser can correctly accept sound from ICECAST? 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20110724/b3553730/attachment.htm>

From michel.memeteau at gmail.com  Sun Jul 24 09:46:53 2011
From: michel.memeteau at gmail.com (michel memeteau)
Date: Sun, 24 Jul 2011 11:46:53 +0200
Subject: [Icecast] Questions about ICAST and Web Development
In-Reply-To: <BAY159-W24C6A22EEBDC71176CD283D0300@phx.gbl>
References: <BAY159-W24C6A22EEBDC71176CD283D0300@phx.gbl>
Message-ID: <CAJbJ1BtQkbC+hsBoYqJ7pQ2WFemedHp7+qTkxMxrLzfSNLf_eA@mail.gmail.com>

Hi !

2011/7/24 Me Myself and I <stargate7thsymbol at live.co.uk>

>  -HOW does ICECAST stream content?
>
Pure Http


> -Can it stream sound being spoken live over a microphone?
>
Yes

> -Can this live audio be streamed in an MP3 format?
>
Yes

> -Can this audio be streamed to HTTP Web browsers (including XMLHttpRequest
> techniques)?
>
Yes (HTML5 audio for example)

> -How does an HTML file being served by Apache/Tomcat best set up
>  so that the browser can correctly accept sound from ICECAST?
>

Nothing special IMO, when opening the stream with the HTML5 browser , it
just plays it , for example pointing your browser to

http://stream.divergence-fm.org:8000/divergence.ogg

Will play it ( real browser not IE9 nor safari )

example of mp3 stream for dumb browsers :
http://radiogalere.org:8080/galere.mp3

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


-- 
<------------------------------------------------------->
web perso : http://memeteau.com
Boutique Ordinateurs GNU/Linux : http://shop.ekimia.fr
Fixe :  0974763294 Mobile : 0624808051
Visio/jabber/GTalk : xmpp:freechelmi at jabber.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20110724/4b604fcf/attachment.htm>

From raylutz at cognisys.com  Tue Jul 26 17:52:48 2011
From: raylutz at cognisys.com (Raymond Lutz)
Date: Tue, 26 Jul 2011 10:52:48 -0700
Subject: [Icecast] Max Icecast Listeners
Message-ID: <4E2EFEF0.1080301@cognisys.com>

I am curious if anyone has had enough experience to know --> how many 
simultaneous listeners can be supported by typical server boxes, 
assuming unlimited bandwidth is available?

My specific case:
My server (http://www.AirProgressive.org) is on a Linux VPS server 
located in a datacenter and on a optical backbone so that bandwidth is 
not the problem. Each connection I am running is at 32kbps and 22050 Hz 
sampling rate (mono) since the program is "talk radio". The bandwidth 
available per month is 6000 GB and at an average of 4.5 hours per week 
of listening, which is what similar stations had in this area of the 
same genre, I can service about 21,000 listeners per month.  The peak 
would be at least 562 listeners at any one time, which is the average. 
Let's just assume the peak is 10,000 listeners at a time. How many 
servers do I need to support that? (and more importantly, how do I 
figure it out?)

Q2: does icecast provide any warnings when it finds it is unable to keep 
up with the workload? What sort of failure mode will occur? Gaps in the 
transmission, dropped listeners, ?

Thanks for your help.

--Ray Lutz

-- 
---------------------------------------
Raymond Lutz
Cognisys, Inc.
1010 Old Chase Ave., Bldg B
El Cajon (San Diego Cty), CA 92020 USA
Voice 619-447-3246
http//www.cognisys.com



From msmith at xiph.org  Tue Jul 26 18:11:09 2011
From: msmith at xiph.org (Michael Smith)
Date: Tue, 26 Jul 2011 11:11:09 -0700
Subject: [Icecast] Max Icecast Listeners
In-Reply-To: <4E2EFEF0.1080301@cognisys.com>
References: <4E2EFEF0.1080301@cognisys.com>
Message-ID: <CAB=BY8smechyrCdAGG1M07ahZ7SwSFox2ui+oiVEQ0Dj23jLHw@mail.gmail.com>

On Tue, Jul 26, 2011 at 10:52 AM, Raymond Lutz <raylutz at cognisys.com> wrote:
> I am curious if anyone has had enough experience to know --> how many
> simultaneous listeners can be supported by typical server boxes,
> assuming unlimited bandwidth is available?

Icecast scales pretty well, to the point that assuming unlimited
bandwidth is not an appropriate assumption.

>
> My specific case:
> My server (http://www.AirProgressive.org) is on a Linux VPS server
> located in a datacenter and on a optical backbone so that bandwidth is
> not the problem. Each connection I am running is at 32kbps and 22050 Hz
> sampling rate (mono) since the program is "talk radio". The bandwidth
> available per month is 6000 GB and at an average of 4.5 hours per week
> of listening, which is what similar stations had in this area of the
> same genre, I can service about 21,000 listeners per month. ?The peak
> would be at least 562 listeners at any one time, which is the average.
> Let's just assume the peak is 10,000 listeners at a time. How many
> servers do I need to support that? (and more importantly, how do I
> figure it out?)

At 32 kbps? About one. Note that this is well over 300 Mb/s; you
should ensure that your network connection is actually able to sustain
this.

See the load tests on the icecast website that were done quite a few years ago.

>
> Q2: does icecast provide any warnings when it finds it is unable to keep
> up with the workload? What sort of failure mode will occur? Gaps in the
> transmission, dropped listeners, ?
>

The log files will show dropped listeners, but there's no good
high-level interface to show you that cpu load is a problem.

Mike