kbps limit (bugs)

hmorneau · Post by **hmorneau** » Sat Jun 18, 2005 4:00 pm

Hello,

I start to use your software today, but I see a little problem. I can cap my user at a bittrate (like 128kbps) but the problem is when the DJ change the track in Winamp the kbps sometime go higher than 128, (up to 200kbps in some case). So I think you must add a delay before to kick the source (like 2 minutes). That will solve this issue.

Thanks.

Post by **Jay** » Sat Jun 18, 2005 4:22 pm

I will see about making that customizable.

Yes there will be data spikes so you will have to use something a tad higher then 128 for 128 streams.

hmorneau · Post by **hmorneau** » Sat Jun 18, 2005 4:23 pm

yes, because spike go up to 200kbps when you change the track... a bigger delay will be good

Post by **betatester** » Sat Jun 18, 2005 4:51 pm

I don't see this behavior at all. I watched through 4 title changes at 320kbps...it stayed at 321kbps throughput the entire time.

The only time I see a higher number is when the stream first launches. That *should* be because of the buffer building up, then it settles in at the correct bitrate +/- 1-3kbps

As for how to set the bitrate limiter...

If you are trying to limit someone to say 56kbps...set the limit just below the next highest bitrate (ie; 61kbps). That will prevent a stream of 64kbps, but leave plenty of overhead for 56kbps.

It works best for live streams, I wound up disabling it for relays because of the fluctuation in bandwidth from the master server.

hmorneau · Post by **hmorneau** » Sat Jun 18, 2005 5:10 pm

betatester I use winamp and when I output at 128kbps, if a changed track multiple time, the server go up to 200kbps. If you don't belive me, try it. Anyway, just add this option for a delay and that will be fine.

Thanks

Post by **betatester** » Sat Jun 18, 2005 5:13 pm

How many times are you changing the track per second?

I tried changing 8 songs in 10 seconds and still didn't see it...

I want it to work just as bad as you do

hmorneau · Post by **hmorneau** » Sat Jun 18, 2005 5:15 pm

just 2 song in about 3 second exceed to 170kbps

djclae · Post by **djclae** » Mon Jun 20, 2005 3:05 pm

If you run a 128kbps server, don't make the limit 128. With that you're guaranteed everyone will get kicked off. Just set it to keep the people with really bad connections off. From my short experience since this feature was repaired, I recommend setting this to 200 or higher.

djclae · Post by **djclae** » Mon Jun 20, 2005 9:34 pm

Wait a second, ignore my previous post. What happened to this feature? I want to kick listeners who average a datarate over 200. Why would I want to kick my own source? All I'm seeing here is server limit, which seems to be a cap for the whole server, and source avg bitrate limit. I don't have a use for either. What I want is to automatically kick people with crappy bandwidth-consuming connections. Was this feature just given up on, or will we see it in a later version?

Post by **Jay** » Mon Jun 20, 2005 10:18 pm

well no one can just suck up bandwidth like that as a listener. Listeners all consume it at the same rate as the source after their initial push. The feature we are concerned about here is for host providers more then average users.

djclae · Post by **djclae** » Tue Jun 21, 2005 11:44 am

What happened to the feature in the last version, where you could see Avgdatarate for each listener? The ones that had over 300 had a lot of underruns, and clearly I wanted them gone. It creates server harrassment and overhead on the bandwidth. If this solution isn't a practical one, why not implement a limit to the number of underruns a listener can have before it kicks them off?

Post by **Jay** » Tue Jun 21, 2005 12:23 pm

well for one thing, if you ever saw a listener with significantly more data rate then your source then you saw the bug in the average data rate. This was just bad design on my part. As all it did was take connect time and bytes recieved to figure that value.

If you are still seeing this behavior in the new version then please let me know. The correct bahavior you should see is an initial spike on connection depending on how good your bandwidth is. Then it should level out to the source bitrate after a few seconds.

Either way it is impossible that a "bad" listener is raping your bandwidth. Don't be too trustful of the stats of a beta product

djclae · Post by **djclae** » Tue Jun 21, 2005 3:47 pm

I can't really see any of that stuff anymore in the new version. Anyway, maybe I'm completely wrong, but I believe people with a lot of underruns create extra overhead bandwidth. The constant reconnecting creates extra requests. At any rate, it's a slot I'd rather free up for someone with a working connection. What is the possibility of adding a feature that autokicks listeners after a certain amount of underruns? Couldn't be too hard, I'm sure. Unless you think such a feature is completely useless.

By the way, thanks for adding the listener timer. If I can make SAM3 properly crossfade with all of my voice intro files (and that's a huge if) and they release a version of SAM that supports Steamcast stats, I will change all of my Shoutcast servers to Steamcast soon.

Post by **Jay** » Tue Jun 21, 2005 3:56 pm

I understand but the problem comes in what to do, if you kick they are just going to come back and continue consuming that slot. I'll think on the underrun max, but for now it might be premature just because of the state of steamcast right now.

djclae · Post by **djclae** » Tue Jun 21, 2005 4:01 pm

I understand. It may not necessarily kick them only to have them reconnect to that server, however. Right now I have 3 on Shoutcast.com, including the Steamcast one. A lot of times when I kick someone from one server, they go straight to the next one of my servers in the playlist. It's amazing, sometimes by watching the stats, I have very direct control of pushing almost every single listener from one server to the other at will. At times, this can have positive results. Maybe one server works better for a particular listener due to their location. I also use time limits to urge people to stay off the backup server and keep to the main one unless it's full.