Listener connection unexpectedly closes

[JotaSelector]

We are running a SHOUTcast DNAS/Linux v1.9.8 from a hosting service.

The server is set up to only have one listener. (Why just one listener? It's used exclusively for doing remote broadcasts for an FM station.)

On the source-to-server end, everything works great. However we're having issues on the client end. Most of the time it works just fine but on more than a few occasions our lone listener will get dropped.

We have these set:
- Disconnect listeners if source disconnects: 0 ("No" in our CentovaCast control panel)
- Always disconnect listeners after: 0

There are two ways the listener's connection becomes closed.

The first way is when our listener gets kicked/dropped because another random listener tries to listen. Example from the log (with our listener being the xxx.xxx.xxx.160 and the random listener being the bbb.bbb.bbb.219 ):

<01/30/12@13:52:01> [dest: xxx.xxx.xxx.160] starting stream (UID: 176)[L: 1]{A: MPEG OVERRIDE}(P: 0)
<01/30/12@13:56:05> [dest: bbb.bbb.bbb.219] IP in ban list, disconnecting
<01/30/12@13:57:13> [dest: xxx.xxx.xxx.160] service full, disconnecting
<01/30/12@13:57:13> [dest: xxx.xxx.xxx.160] service full, disconnecting
<01/30/12@13:57:13> [dest: xxx.xxx.xxx.160] connection closed (312 seconds) (UID: 176)[L: 0]{Bytes: 5253952}(P: 0)

I have started banning these IPs and their subnets (I'm in the US and they are all from various other countries including France, Australia, Czech Republic, and Romania) and reserved our IP addresses yet, as you can see, this attempted connection seemingly still caused our listener to be dropped.

I've even made it happen from my machine by streaming it on the web proxy and then opening the stream as a Quicktime .qtl file. The web proxy connection becomes closed and the Quicktime starts streaming it. [Note: the random foreign listeners have failed to actually connect-- even before becoming banned-- but still result in our listener's connection closing.]

The second way that the stream disconnects is without any other listener involved. In this case, the listener connects but then gets dropped at a regular interval, 32 seconds. Here's another example from an older log:

<01/26/12@13:27:14> [dest: xxx.xxx.xxx.185] starting stream (UID: 65)[L: 1]{A: QuickTime/6.0}(P: 1)
<01/26/12@13:27:46> [dest: xxx.xxx.xxx.185] connection closed (32 seconds) (UID: 65)[L: 0]{Bytes: 256000}(P: 1)
<01/26/12@13:27:48> [dest: xxx.xxx.xxx.185] starting stream (UID: 66)[L: 1]{A: QuickTime/6.0}(P: 2)
<01/26/12@13:28:20> [dest: xxx.xxx.xxx.185] connection closed (32 seconds) (UID: 66)[L: 0]{Bytes: 256000}(P: 2)
<01/26/12@13:28:22> [dest: xxx.xxx.xxx.185] starting stream (UID: 67)[L: 1]{A: QuickTime/6.0}(P: 0)
<01/26/12@13:28:47> [dest: xxx.xxx.xxx.185] Added to Reserve IP List
<01/26/12@13:28:54> [dest: xxx.xxx.xxx.185] connection closed (32 seconds) (UID: 67)[L: 0]{Bytes: 256000}(P: 0)
<01/26/12@13:28:56> [dest: xxx.xxx.xxx.185] starting stream (UID: 68)[L: 1]{A: QuickTime/6.0}(P: 0)
<01/26/12@13:29:28> [dest: xxx.xxx.xxx.185] connection closed (32 seconds) (UID: 68)[L: 0]{Bytes: 256000}(P: 0)

As you can see, I tried to reserve the IP in hopes of preventing the drop but to no avail. So far, this problem occurs at one machine. And of course it's the only one we NEED to work. (It's the one we're using to send to the FM broadcast.) Maybe some funny setting in the local network is causing it? Firewall?

So regarding these 2 issues:

(A) What is causing shoutcast to drop the existing listener when a new listener tries to connect, successfully or not/banned or not?
What can we do to avoid having our listener dropped in this way?
-- Make our station reserve-only? (Apparently this is not an option in 1.9.8, though.)
-- Make another listening slot available, maybe? (We have added another listener slot since this issue started.)

(B) What do you think may be causing the weird 32 second connections? Is this something anyone has seen or heard about before?

Unfortunately, I do not have access to the .conf files other than through a CentovaCast control panel and am unable to provide debug info.

Let me know if there is any other info I need to provide for you to diagnose these issues.

Thanks in advance for your help.

[JotaSelector]

Guesses?

Just checking back on this. Does anyone have any ideas? A guess?

Maybe just a suspicion as to where--server or client--the problem may be occurring?

Thanks for any insight.

[dotme]

RIPOnly=Yes is required for this.

It's not enough to add your client IP to the Reserve list. It will still get booted if another player tries to connect. You need to set the Shoutcast server to ONLY allow connections from reserved IPs.

MPEG OVERRIDE is a flash player. Avoid that if you're using the connection to do remote broadcasts. Flash leaks memory with Shoutcast streams. QuickTime also isn't all that great if you ask me.

If you're running Windows for the player, use Winamp or iTunes. If a Mac, iTunes is the obvious choice. Good luck.

[jaromanda]

Avoid that if you're using the connection to do remote broadcasts. Flash leaks memory with Shoutcast streams.

Correction: Only poorly written flash shoutcast players, for example, JW Player, leak memory

and, as a broadcaster, why "avoid" what listeners use to listen - that makes no sense

[dotme]

Correction: Only poorly written flash shoutcast players, for example, JW Player, leak memory

and, as a broadcaster, why "avoid" what listeners use to listen - that makes no sense

Did you even bother to read the OP??

It's not for listeners. It's a live feed relay for an FM radio shop. My advice stands - don't use flash players for such purposes.

[JotaSelector]

Dotme: Thanks very much for your help. We will try setting the 'riponly' and see how it goes.

[SCstreaming]

It will still get booted if another player tries to connect.

John, I strongly disagree.

If he has a 1 port Shoutcast 1.9.8 server and it encoding it will not disconnect if someone tries to listen to that IP / Port #.

There is no way SAM will disconnect the encoder. The person trying to listen just gets a server full error and the encoder remains encoding.

[qgazq]

I guess there should be the "upgrade to v2" reply, however I think there are issues with RIP on that, I'm going to do some more investigation and post about that at some point if I confirm what I saw before.

Anyway, it looks as though the server is counting the "new" connection even when it directly rejects it. I'm assuming you have max listeners set to 1?
The easy work around will be to set the max listeners higher, then turn RIPOnly on and add your client to the list.
The RIP list will restrict who can connect so it doesn't matter that max listeners is 10 or so.

As for the second issue, I have no idea.

Regards
QGazQ

[JotaSelector]

The support folks at the hosting service are adamant that there is no way a listener can be dropped when another tries to connect despite the evidence in the log that suggests this has occurred.

When they weren't able to diagnose the problem and seemingly became disinterested in troubleshooting, they sent me to these forums to prove otherwise.

From what you guys, dotme and qgazq, are saying this whole 'listener dropping due to others trying to connect' does not seem to be beyond the realm of possibilities. Correct?

Because we are using a hosting service, I am unable to turn RIPonly on since I do not have access to the .conf files and the CentovaCast console we're using doesn't show that feature. However, this may not be necessary afterall...

...Because there is some good news. Since I started this thread, we have set the max listeners to 2 and it appears that alone may have fixed it. Even if I connect 2 listeners and try to connect a 3rd, there have been no listener drops from my home or office since we made this adjustment. I will test it tomorrow on the FM station's computer (i.e. the only one we really need to work) and see how it goes. ::fingers crossed::

Thanks to everyone for all of your help and suggestions. I really do appreciate the time you have volunteered to help me with this issue. Cheers.