Bandwidth shortage?
 

During peak hours (more than 50 or 60 listeners) the 128k stream drops frequently, as often as every ~15 seconds as I write this, which makes it pretty much unusable. Don't have this problem with the 56k connection, so that's a workaround, but I'd rather have the 128k work!

Using Winamp3 on ADSL 768/128. Per DSL Reports my line tests consistently at ~630/103, even at peak times, so unless I'm the only person with this problem, I don't think the problem is on my end. I'm the only user on this DSL connection.

That shouldn't be happening. The 56k server is on a completely different server than the 128k subscriber server, so there's no correlation between the two.

The subscriber server is colocated at an ISP with multiple providers, so it has plenty of bandwidth, and from the bandwidth logs, we're only putting out about 500k/sec at the moment.

I can't really test it myself at the moment. Anyone else seeing this?

I would be highly suspect of your connection, though, even though it pasts the tests you mentioned. Are you dropping packets? I know my DSL at home reports high numbers from dslreports.com, but I am barely even able to listen to the 128k stream myself. But again, I can't say what the problem might be.

I don't have the problem either at home (cable modem) or at work (T3 or greater)...

I've gotten this problem whenever tuning in on the 128k at home. I'll try and troubleshoot the issue from my side tonight. Haven't tried it at work yet, but I will tomorrow.

Tommy

Here are results of DSLR's line quality test . Consistent 5 out of 5 tests, and 1 out of 1 a couple weeks ago. FWIW, I was having line problems a few weeks ago, but it's been real clean since SBC fixed it.

There is consistently 1 dropped packet at the last hop from the east coast on each test, but they say that's typical for ADSL and does not represent a problem.

Turning up Winamp's various buffers all the way helps, I think, but it sure isn't solved.

I think there is a correlation between # of users and this problem, though. I've not kept records, but I have checked many times. I'll start keeping track and report what I find. As I write this, there are 62 listeners, but this listener isn't having any problems.

Oops, jinxed it...just dropped. 67 listeners.

testes . . . testes
 

Yeah, I ran the same tests and even went back to check my bandwidth. No packet loss and I have more than enough to pull down the stream without any problems. Dunno, it does keep prebuffering a lot though, about every 3-4 seconds as I've seen.

Tommy

IME every 3-4 seconds is a LOT of pre-buffering. I see it maybe once a minute here, at least right now. I guess I didn't know how good I had it! So I guess you're not able to use the 128k stream at all. That sux.

Do you see any time of day/number of listeners/number of drops correlation?

Just had a drop: 49 listeners. 'Course, I don't know how many of those are 128k listeners. But I'll keep a drop diary for a few days and see if I can spot a pattern anyway.

Including me, there are 5 people on the 128k feed. I know this through the station tools at my fingertips.

Hey Avian, isn't the 128k feed from a simgle server?

Tommy

Yes, the 128k feed, as I said above, is on its own separate server. So, when you say it's related to a lot of listeners, you mean 5 or so for the 128k stream. I'm listening now with no problems (4 listeners, 60 56k listeners even though the number of 56k listeners has no relation to anything). Again, the 56k server can have 10,000 listeners, and it doesn't matter - the 128k stream always have between zero and 7 users or so. And that's nothing for a colocated connection (around 800 k/sec).

The fact that Jim chimed in and said he's isn't having any problems with the 128k at home or work, and at the same time you guys were having problems, still makes me suspicious.

Plus, I think I would get a TON of emails from the other subscribers if it was a server problem - but I haven't (you should see the number of emails I got when the subscriber stream went down because of tech reasons a few weeks ago). I also checked the logs for the subscriber stream, and there were no buffer underruns for any of the listeners when you guys were having problems.

Again, I'm not discounting that there might be a problem - just laying out the evidence and thinking it through.

To see how many listeners there are at any time, enter the stream address into your web browser (don't post the subscriber address in the forums).

Please post here if you are having problems today. Post the time and the number of 128k listeners (not 56k listeners).

Have you guys tried other 128k streams to test? Go to http://www.shoutcast.com and click on a few 128k streams (search for prog if you want - there are a few prog 128k streams out there), and see how they do for you.

Also: try to ping and traceroute the subscriber server. Go to a command line and type ping <server address> and tracert <server address> and see what numbers it comes up with. Post them here.

Yeah, the 128k is fine from my work machine. I'll try a few other things at home to suss out what the specific problem is. We shall see.

Tommy

Avian, no offense intended, but the first 3 paragraphs of your message accomplish nothing except to make you sound defensive. The 4th paragraph does little to diminish that effect; actually, it underscores it. Not the first time I've noticed that on this board, either.

Specifically, you keep coming back to the irrelevance of the 56k listener count, but until this last message from you, I had no way to determine the 128k listener count. But I did guess that there is a typical ratio of 56k listeners to 128k listeners and that you might know what that is. Looks like roughly 10%. If so, my observations are relevant, if unavoidably imprecise.

Your last 4 paragraphs are constructive, and all I needed to hear. Here are the answers:

PING

Reply from xxx.xxx.xxx.xxx: bytes=32 time=92ms TTL=109
Reply from xxx.xxx.xxx.xxx: bytes=32 time=82ms TTL=109
Reply from xxx.xxx.xxx.xxx: bytes=32 time=70ms TTL=109
Reply from xxx.xxx.xxx.xxx: bytes=32 time=69ms TTL=109

Ping statistics for 64.202.98.44:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 69ms, Maximum = 92ms, Average = 78ms

================

TRACERT

1 43 ms 37 ms 24 ms adsl-xxx-xxx-xxx-xxx.dsl.hstntx.swbell.net [xxx.xxx.xxx.xxx]
2 19 ms 19 ms 19 ms dist1-vlan60.hstntx.swbell.net [151.164.11.190]
3 20 ms 18 ms 19 ms bb1-g8-0.hstntx.swbell.net [151.164.11.246]
4 20 ms 200 ms 24 ms core1-p6-1.crhstx.sbcglobal.net [151.164.188.5]
5 26 ms 41 ms 23 ms core3-p14-2.crdltx.sbcglobal.net [151.164.188.165]
6 38 ms 47 ms 47 ms core1-p2-0.crdltx.sbcglobal.net [151.164.242.106]
7 38 ms 48 ms 38 ms bb1-p14-2.rcsntx.sbcglobal.net [151.164.240.73]
8 23 ms 26 ms 25 ms bb1-p14-0.pxdltx.sbcglobal.net [151.164.242.142]
9 26 ms 24 ms 27 ms 198.32.114.12
10 63 ms 62 ms 61 ms ge1-2-605m2-chi-b1-00.bb.webusenet.net [64.154.59.177]
11 60 ms 61 ms 62 ms ge1-6.b2.chg.servercentral.net [64.154.39.6]
12 68 ms 95 ms 67 ms server.domain.tld [xxx.xxx.xxx.xxx]

Trace complete.

===================

At this writing, I've been streaming from RadioStorm.com at 128 for 90 minutes.

Flawless.

Not even any prebuffering that I've noticed. This is at 10:30 AM CT, a time at which I often encounter the problem with AM every 3 or 4 minutes. I will stay with RadioStorm this morning and see if I have any problems.

JRV,

Please forgive me - in no way did I intend to be defensive. I'm simply laying out some facts in order that we may solve this problem together. Again, I'm not saying that it's not our server - I'm just trying to figure out what's going on.

Are you getting the prebuffering today (we're just about at peak time as of this writing)? I would try and switch back and forth between AM 128k and Radiostorm 128k to see if there's a difference.

Tommy has said that the stream is fine at work today...

I'm still streaming at home just fine- no prebuffering problems.

From a listener whom I asked about the 128k server this morning (he listens and records it 24/7): "the past 7 days has been real good. (sic)"

Your pings and tracert look good - I assume you're not using anything else that takes up bandwidth?

Avian 3/25: "I know my DSL at home reports high numbers from dslreports.com, but I am barely even able to listen to the 128k stream myself."

Avian 3/26: "I'm still streaming at home just fine- no prebuffering problems."

Ummmm...which is it?

I just switched back to AM. Had my 1st prebuffer at 0:30 seconds, though the drop was short enough I didn't hear it. Just did it again: 2:58, again 9:56.

Problem occurs when there are no foreground Internet apps. Only significant background bandwidth-intensive app is if I'm receiving an e-mail with a large attachment or a Windows Update or some other background update is downloading...but those are fairly rare events. I know it hasn't happened since I started this thread.

Now at 15:45...haven't heard any drops.

20:03, dropped. Nothing bandwidth-intensive happening.
21:20, prebuffered twice.
21:50 (11:41 AM CT) , dropped again.

It's both! I live waaaaayyy out in the country - sometimes my DSL line at home is good, sometimes it's bad. This morning, it's pretty good (CST in USA)

Hmmm...I'm sorry - not sure what time zone you're in... Also, I think I missed what player you're using.

But I think the evidence leans heavily toward this problem being a localized condition for you. I have four reports of the stream being OK (the user I asked above is really connection-intensive, and lets me know when anything is wrong with teh station/stream) .

I've seen this problem before every once in awhile, and I can't really explain it, where people can listen to one internet station, but not other ones. I've experienced it myself in the five years I've been shoutcasting, but never really found out what the problem was. I've seen some correlation with listening to overseas stations.

Keep posting when you're seeing buffering - I'll keep investigating.

Central, just like you. But the times I cited in my last couple messages were minutes & seconds relative to switching back to AM (from the elapsed time indicator in Winamp); the point was that it happened several times within seconds of starting AM and at frequent intervals thereafter.

I'm using Winamp3 (build 488) on WinXP SP1 on a PIII/866, 256MB.

Yeah, that really sounds like this problem is localized to you. I'm listening to Kansas, not too far north of you, really. And the stream has been rock solid (and for the others I've polled too).

Any ideas?

As an aside, I've been toying with the idea of going to a 96k WMA stream - where it would actually sound better than a 128k mp3 stream. And reduce the bandwidth... how would folks feel about that? Or, we could go to a 128k WMA stream - super-quality!

Avian

I guess that would be Kansas, the state, not Kansas, the band.

I'll load Winamp on my notebook later and try it at home and maybe at a client site or two if I can get through their proxies (I know the system administrator, heheheh) and see what happens.

As for WMA, I'm all in favor. Not only for sound quality, but I really like the minimize-to-toolbar feature in WMP9. 96k would be great, 128 would be greater...provided I don't have the same problems as I'm having with SHOUTcast at 128...

And (playing right into Microsoft's grand scheme, here) potential subscribers who don't know how to download and install Real or Winamp won't have to mess with that because they already have WMP, or can get it from Windows Update.

True, but there are some die hard Mac fans that might object (are you out there Paul?). :-)

Avian

What are my alternatives for players for Shoutcast? Is Winamp the only one?