Icecast - Jul 2011 - Orphan threads with Cellphone (Blackberry) player

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>