aacPlus Streams Connecting...<HTML>?

JERIC · 27th July 2007, 18:34

I'm having issues with my aacPlus streams. I have the user limit set to 1000 but during peak times people are having a hard time getting in even though the listeners aren't near 1000. What ususally happens is winamp just says

connecting... <HTML> stream address

If I set Winamp to repeat, it will continue to attempt connecting to the stream. After about 30 seconds it finally lets you in. This has happened with several users but just on the aacPlus streams that are busy. MP3, Ogg, WMA all fine.

I'm using SAM 4.2.2 to broadcast to SHOUTcast 1.9.8.

Sawg · 27th July 2007, 19:30

You can't just make up a number for the listener limit. It is based on the bandwidth you have.

JERIC · 27th July 2007, 20:03

PHP Code:


			
; MaxUser.  The maximum number of simultaneous listeners allowed.

MaxUser=1000

My bandwidth limit is my 1G and I'm only using around 55MB/s during peak.

Greg_E · 27th July 2007, 20:25

Either your server isn't keeping up, or your connection isn't keeping up.

What's the bit rate of the stream in question?

fc*uk · 27th July 2007, 20:32

You aure you are not connected to a gigE network and that you really have a 1 gig upstream connection?

go to www.speedtest.net to verify your upstream ....

JERIC · 27th July 2007, 21:29

32k & 64k bitrates are in question. 128k MP3 seems fine. I won't be able to reproduce the problem now since it's not peak anymore.

Here are my bandwidth results:

I have an 8 core system with 4G of RAM and plenty of power to spare. It's a co-located server with no known bandwidth restrictions on a gigE port. I don't have any intro files either. Maybe it has something to do with how many connections windows is allowing over the network? Results are the same with or without firewall.

Thanks for your help so far.

fc*uk · 27th July 2007, 21:38

There are bandwidth restriction ... one server pushed 5M and some change, the other pushed 25.5M....

Take your broadcast bitrate multiply by simult. user and then multiply by 1.1. If you exceed 30M then that is why you buffer.

A T1 (1.5M) can only support 10 listeners at 128k. 10*15 (10 listeners with 15 T1's [15 T1's = 30M]) = 150 users and a 30M line is tanked....

JERIC · 27th July 2007, 22:59

Well, there isn't any buffering. All of the streams are rock solid once they go. The problem seems to be connecting to it to begin with. As far as the 5M, that server in Washington is taxed. You can test it yourself. I'm getting over 25M on most of the other servers. I'm pretty certain it's not a bandwidth issue. I'm aware of bandwidth calculations and I already told you what I'm pushing (55MB/s at peak). Is this inability to connect really a symtom of lack of bandwidth? I never remember SHOUTcast doing this before if there is a bandwidth issue. Usually it would allow you to connect then it would play for a few seconds, buffer, play, repeat. Well that is not my issue. The initial connection is the problem. But once it does connect it plays steady.

Greg_E · 28th July 2007, 02:35

Could be a bad network card jamming you up. I had this with a video server on our LAN. All the tests were supposed to be correct, but as soon as I replaced the card everything worked better. Check your processor load at peak, I remember reading in another thread that ShoutCast was not multithreading properly, so you might be running everything on a single core and simply running out of steam. And if you have another network card it might be worth changing it when the opportunity comes around, or simply add another network card to make sure you spread things around enough.

This is all kind of a shot in the dark, I don't really have a clue what is happening, but those are things I would try.

fc*uk · 28th July 2007, 02:48

Transcoding takes ve y little cpu power. Yes, everything is running on a single core ... but that should not limit you (if nothing else is at play). I have hosted more on less with no issues.

Knowing the last bit of the initial push to connect (sorry that I did not catch it), I would have to agree with Greg_E. Check unusual threads pegging the cpu; maybe replace the nic too ... especially if you are using on-board or generic.

Greg_E · 28th July 2007, 18:10

Since this stuff only runs on a single processor, it makes me think that many smaller less expensive computers is a better choice than a high powered server for running these streams.

I only have a single processor in my server so I'm never going to get to see what is going on.

And I also externally encode to AAC+ so I have no experience with transcoding, and probably never will.

JERIC · 28th July 2007, 19:33

CPU usage is fine and just because SHOUTcast doesn't take advantage of multiple cores doesn't mean that is the problem. Windows knows how to manage multiple cores. When a new process is launched it automatically chooses the lowest CPU used at the time, as long as you don't set the affinity. My CPU usage is steady on all 8 cores. Nothing is bottlenecking on my machine.

BTW I'm not transcoding. I'm using SAM encoders directly to local SHOUTcast servers.

Does anyone have aacPlus streams with at least 100 listeners on them? If so, how does launching them compare to my issues?

fc*uk · 29th July 2007, 00:12

I've fed those numbers transcoding from mp3 to aac+ on something as low as a PIII.

I have never seen anything like this, hence the reason I think that there is something else at play here.

JERIC · 8th August 2007, 12:28

I'm attempting to provide closure to this issue. I think this might be a client side issue though. I haven't pinpointed what it is yet but if I do I'll provide a resolution here.

Thanks everyone!

JERIC · 20th August 2007, 19:47

Answer: Company Firewall

When connecting using the DNS it is blocked, by IP it is not. I can confirm by visiting the SHOUTcast admin control panel. This was happening to a few different clients. Turns out "streaming" or "death" aren't firewall friendly words so more than one company has blocked out DNS names.

Thanks for your help everyone!

john@ROCKNTV1 · 21st August 2007, 22:14

Quote:

Originally posted by JERIC
Answer: Company Firewall

When connecting using the DNS it is blocked, by IP it is not. I can confirm by visiting the SHOUTcast admin control panel. This was happening to a few different clients. Turns out "streaming" or "death" aren't firewall friendly words so more than one company has blocked out DNS names.

Thanks for your help everyone!

just wondering what os your running with all that hardware?

as your answering of you own question has confused me .

w2k
10/100 network

p2 @ 400
256 meg pc133
260kbs video 24/7
gagging the pci bus

JERIC · 21st August 2007, 23:09

Windows 2003 Enterprise

I answered my own question in case anyone else would experience the same problem in the future.

27th July 2007, 18:34	#1
JERIC Junior Member Join Date: Oct 2003 Location: Richmond, VA - USA Posts: 15	aacPlus Streams Connecting...<HTML>? I'm having issues with my aacPlus streams. I have the user limit set to 1000 but during peak times people are having a hard time getting in even though the listeners aren't near 1000. What ususally happens is winamp just says connecting... <HTML> stream address If I set Winamp to repeat, it will continue to attempt connecting to the stream. After about 30 seconds it finally lets you in. This has happened with several users but just on the aacPlus streams that are busy. MP3, Ogg, WMA all fine. I'm using SAM 4.2.2 to broadcast to SHOUTcast 1.9.8.

27th July 2007, 19:30	#2
Sawg Forum King Join Date: Jun 2000 Location: Phoenix, AZ Posts: 7,456	You can't just make up a number for the listener limit. It is based on the bandwidth you have. \| Brought to you by ^V ^C \| The one... the original... no seriously!

27th July 2007, 20:03	#3
JERIC Junior Member Join Date: Oct 2003 Location: Richmond, VA - USA Posts: 15	PHP Code: `; MaxUser. The maximum number of simultaneous listeners allowed. MaxUser=1000` My bandwidth limit is my 1G and I'm only using around 55MB/s during peak.

27th July 2007, 20:25	#4
Greg_E Major Dude Join Date: Nov 2006 Location: USA Posts: 1,687	Either your server isn't keeping up, or your connection isn't keeping up. What's the bit rate of the stream in question? Your mileage may vary!

27th July 2007, 20:32	#5
fcuk Moderator* Join Date: Dec 2005 Location: Atlantic Beach Posts: 8,140	You aure you are not connected to a gigE network and that you really have a 1 gig upstream connection? go to www.speedtest.net to verify your upstream .... Trancectro/electro-house/electro \| Are You Hard?

27th July 2007, 21:29	#6
JERIC Junior Member Join Date: Oct 2003 Location: Richmond, VA - USA Posts: 15	32k & 64k bitrates are in question. 128k MP3 seems fine. I won't be able to reproduce the problem now since it's not peak anymore. Here are my bandwidth results: I have an 8 core system with 4G of RAM and plenty of power to spare. It's a co-located server with no known bandwidth restrictions on a gigE port. I don't have any intro files either. Maybe it has something to do with how many connections windows is allowing over the network? Results are the same with or without firewall. Thanks for your help so far.

27th July 2007, 21:38	#7
fcuk Moderator* Join Date: Dec 2005 Location: Atlantic Beach Posts: 8,140	There are bandwidth restriction ... one server pushed 5M and some change, the other pushed 25.5M.... Take your broadcast bitrate multiply by simult. user and then multiply by 1.1. If you exceed 30M then that is why you buffer. A T1 (1.5M) can only support 10 listeners at 128k. 10*15 (10 listeners with 15 T1's [15 T1's = 30M]) = 150 users and a 30M line is tanked.... Trancectro/electro-house/electro \| Are You Hard?

27th July 2007, 22:59	#8
JERIC Junior Member Join Date: Oct 2003 Location: Richmond, VA - USA Posts: 15	Well, there isn't any buffering. All of the streams are rock solid once they go. The problem seems to be connecting to it to begin with. As far as the 5M, that server in Washington is taxed. You can test it yourself. I'm getting over 25M on most of the other servers. I'm pretty certain it's not a bandwidth issue. I'm aware of bandwidth calculations and I already told you what I'm pushing (55MB/s at peak). Is this inability to connect really a symtom of lack of bandwidth? I never remember SHOUTcast doing this before if there is a bandwidth issue. Usually it would allow you to connect then it would play for a few seconds, buffer, play, repeat. Well that is not my issue. The initial connection is the problem. But once it does connect it plays steady.

28th July 2007, 02:35	#9
Greg_E Major Dude Join Date: Nov 2006 Location: USA Posts: 1,687	Could be a bad network card jamming you up. I had this with a video server on our LAN. All the tests were supposed to be correct, but as soon as I replaced the card everything worked better. Check your processor load at peak, I remember reading in another thread that ShoutCast was not multithreading properly, so you might be running everything on a single core and simply running out of steam. And if you have another network card it might be worth changing it when the opportunity comes around, or simply add another network card to make sure you spread things around enough. This is all kind of a shot in the dark, I don't really have a clue what is happening, but those are things I would try. Your mileage may vary!

28th July 2007, 02:48	#10
fcuk Moderator* Join Date: Dec 2005 Location: Atlantic Beach Posts: 8,140	Transcoding takes ve y little cpu power. Yes, everything is running on a single core ... but that should not limit you (if nothing else is at play). I have hosted more on less with no issues. Knowing the last bit of the initial push to connect (sorry that I did not catch it), I would have to agree with Greg_E. Check unusual threads pegging the cpu; maybe replace the nic too ... especially if you are using on-board or generic. Trancectro/electro-house/electro \| Are You Hard?

28th July 2007, 18:10	#11
Greg_E Major Dude Join Date: Nov 2006 Location: USA Posts: 1,687	Since this stuff only runs on a single processor, it makes me think that many smaller less expensive computers is a better choice than a high powered server for running these streams. I only have a single processor in my server so I'm never going to get to see what is going on. And I also externally encode to AAC+ so I have no experience with transcoding, and probably never will. Your mileage may vary!

28th July 2007, 19:33	#12
JERIC Junior Member Join Date: Oct 2003 Location: Richmond, VA - USA Posts: 15	CPU usage is fine and just because SHOUTcast doesn't take advantage of multiple cores doesn't mean that is the problem. Windows knows how to manage multiple cores. When a new process is launched it automatically chooses the lowest CPU used at the time, as long as you don't set the affinity. My CPU usage is steady on all 8 cores. Nothing is bottlenecking on my machine. BTW I'm not transcoding. I'm using SAM encoders directly to local SHOUTcast servers. Does anyone have aacPlus streams with at least 100 listeners on them? If so, how does launching them compare to my issues?

29th July 2007, 00:12	#13
fcuk Moderator* Join Date: Dec 2005 Location: Atlantic Beach Posts: 8,140	I've fed those numbers transcoding from mp3 to aac+ on something as low as a PIII. I have never seen anything like this, hence the reason I think that there is something else at play here. Trancectro/electro-house/electro \| Are You Hard?

8th August 2007, 12:28	#14
JERIC Junior Member Join Date: Oct 2003 Location: Richmond, VA - USA Posts: 15	I'm attempting to provide closure to this issue. I think this might be a client side issue though. I haven't pinpointed what it is yet but if I do I'll provide a resolution here. Thanks everyone!

20th August 2007, 19:47	#15
JERIC Junior Member Join Date: Oct 2003 Location: Richmond, VA - USA Posts: 15	Answer: Company Firewall When connecting using the DNS it is blocked, by IP it is not. I can confirm by visiting the SHOUTcast admin control panel. This was happening to a few different clients. Turns out "streaming" or "death" aren't firewall friendly words so more than one company has blocked out DNS names. Thanks for your help everyone!

21st August 2007, 23:09	#17
JERIC Junior Member Join Date: Oct 2003 Location: Richmond, VA - USA Posts: 15	Windows 2003 Enterprise I answered my own question in case anyone else would experience the same problem in the future.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Switch to Linear Mode Hybrid Mode Switch to Threaded Mode