Streamerp2p Forum

Hi,

Ive not seen anything about this problem posted so far, so I thought I'd drop a quick line here.. its a little difficult to explain, so bear with me and if you dont understand at the end of it, just lemme know and i'll try to clarify further......

The problem seems to occur if there is a client(s) that was previously connected to a stream, say in this case the Stern stream. If that client has disconnected for some reason, say a network outage or a huge number of users disconnected at the same time (say at the end of the live show and before the person streaming plays a recorded replay), this client for some reason, fails to find another source and sits idle BUT is still listed in the cached hosts as being a node on the network for that stream. Consequently, other clients try to connect to this "zombie" client, and others to that client.... this leads to a bunch of "zombie" clients that do nothing and do not broadcast any sound, but are still listed as valid stream nodes. When your client connects to one of these "zombies", the display in the info window to the right of the SP2P player cycles the "Player:" field between Stopped and Init OK.
Your client can do this indefinitely or until the "zombie" node you are connected to disconects from the Internet or closes SP2P, then your client will try find another host, but invariably ends up on another zombie.... The problem is, that other clients that connect to you will also go into this state indefinitely. This leads to a whole new network of zombie nodes that make getting back onto the original stream very tedious.

A quick way that seems to work 75% of the time is for the user to disconnect from the stream, clear their hosts cache and then reconnect to the stream, but this does not work all the time.

Maybe a way to solve this is to have a check when the clients connect to each other that makes sure the client you are connecting to actually has some audio data in its buffer and if it doesn't, to disconnect you and try another client. Once a successful connection is made, maybe send a message to other clients on the stream network to remove the host ip for the "zombie" client from the cache ? I dont really knwo if thats the correct way to fix it or not, but it might help....

If you want a demonstration, try conecting to the stern stream between 6am and 11am (Eastern). If you manage to get on ok.. disconnect and try again, you wil eventually find that you get this problem... especially if you try to connect again in the 5-25 minutes after the live run of the show ends......

I know that all sounds a bit strange, if you need some further clarification, please let me knwo and i'll try to explain it a bit clearer...

Best Regards

Stuart

Nope.. not strange at all Stuart... but I would tend to lean toward it being caused most recently by people that are still using... or trying to use version 1.37. That version is no longer compatible with the current version and will cause exactly the behavior that you describe here.

We have sort of a double whammy going on against us here and can use all the help we can get in getting people to the new version.

Streamer has a built in notification system for updates but because of problems with the website host that we used to have (1and1 internet... don't go there ever), that function got broken in v1.37. We've updated it and re-tested it with version 1.38 and 1.39 and it again works fine. The modifications we made should keep us from having that problem again if/when we change website hosts again.

BUT.. for now we must do everything we can to propogate the word by other methods.

Let's do that and see if this doesn't clear up over just a bit of time.

Hiya,

How about a version check in the handshake when clients connect ?

if $version !> 1.37 then move onto another client. Trouble is this legacy problem could be around for ages and newbies who come along to try the product, might get a bad impression of it due to this very problem

Did this problem exist with 1.37 and lower versions also ? as although it was only once or twice, this behavior had been observed a while back.

All the best

Stuart