[Icecast] Orphan threads with Cellphone (Blackberry) player

Tue Jul 19 17:49:37 UTC 2011

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>