Raymond Lutz
2011-Jul-19 17:49 UTC
[Icecast] Orphan threads with Cellphone (Blackberry) player
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>
Maybe Matching Threads
Wisdom of the Ancients
