Upstream dropping... alot!

everettmarshall · 18th January 2005, 17:53

I'm streaming @ 128k using Nicecast through a Netgear WGT624.v2 router over a dynamic DSL line. The SC server is 1.9.5 for Linux.

The router is correctly set to keep the line open (I figgured the constant upstream of data would do that) but the line drops sporadically. It can stay up for a day and a half or it can drop after 30 minutes. There is no obvious pattern.

It also appears that the drop is only affecting the upstream because when I see that the stream is down, I can open a browser on that machine an connect to the net with no problem.

It is also worth mentioning that the connection will also drop when I connect direct to DSL with no router.

The SC stream being lost takes a little more work to recover. Nicecast tries to reconnect, but returns a "login failed" error. The only way to get the streams back up is to ssh to the server and kill the PID, then restart it. I also have to do the same to my relays.

What should I be looking at to run down this problem? My first instinct is that the DSL Dyn IP is changing, causing a drop. DSL is with SBC...could they be watching my datastream? It's only 128k and that is the ONLY use that line gets. I don't even DL software updates on that line.

DJ AmPs · 18th January 2005, 21:00

Do you think the issue could be the remote server? I'm assuming you're using a remote server because you mention only using 128k.

everettmarshall · 18th January 2005, 22:05

I am also looking at that possibilty--in fact HIGHLY probable. What I know is this:

DSL connection is up...
DSL drops...
Nicecast is doing its job: Trying to reconnect when the connection is lost...
DSL is back up...
The remote server is not allowing Nicecast to login again.

I have to kill the sc_serv PID and relaunch SC.

THEN Nicecast can login.

SC isn't releasing the port after the connection is lost so it must think Nicecast is still connected.

I have a feeling that this problem coincides with my server having to be rebuilt. I originally had RedHat 9 and didn't have this problem. When there was a security issue, my host rebuilt the server and installed Fedora--they didn't ask they just changed it.

djSpinnerCee · 19th January 2005, 00:32

Do you notice if the IP of your source changes during this process -- You want to determine if it is in fact an issue with your broadband connection [a brief connectivity loss followed by an IP change would be a sure indication that would not effect browsing], or if there is network congestion somewhere between you and your DNAS.

Since you can still browse -- connect to the DNAS station page [admin.cgi] and kill the source -- this will allow a more graceful recovery, you could also decrease the DNAS source idle timeout, so that the DNAS drops the connection sooner after the source stops sending data -- this will allow you to know when the problem occurs sooner, and your NiceCast may be able to recover faster [it should also have a reconnection timeout that you can decrease].

Lastly, but probably the most important -- You're streaming at your source upload limit -- not likely to work over time -- I would guess that at 96k you would have much better luck. In your case, the source is under-running -- to do what you want, your connection would have to be 110% perfect every minute of every day -- not likely for residential broadband.

everettmarshall · 19th January 2005, 02:08

Source idle timeout is currently 0s. A far as upload speed goes, I'm fine. I have a 384 upload which usually tests more in the 425 range.

Baskido · 19th January 2005, 09:22

well thats very funny as i had the same problem :WITH THE SAME ROUTER!: i fixed it by assigning the server a new local ip on the router

djSpinnerCee · 19th January 2005, 11:38

Zero may be too small for the source idle timeout -- sometimes a zero value indicates NO TIMEOUT -- try 5 seconds.

I'll add that your problem may be that your source is not automatically reconnecting as well -- the DSP has both a Reconnection time value and a logical (yes/no) "Reconnect on connection Failure" that will tell the source to reconnect when the link fails -- you want both to occur.

The DSP reconnect time should be greater than the DNAS value to prevent the source from trying to attach to the DNAS before it closes the stale (idle) source connection.

destroyerdotnet · 20th January 2005, 19:25

there is info on this in the nicecast forum @ audio hijack. I think its a bug. (one of our djs uses it)

18th January 2005, 17:53	#1
everettmarshall Junior Member Join Date: Aug 2004 Location: St. Louis, MO USA Posts: 18	Upstream dropping... alot! I'm streaming @ 128k using Nicecast through a Netgear WGT624.v2 router over a dynamic DSL line. The SC server is 1.9.5 for Linux. The router is correctly set to keep the line open (I figgured the constant upstream of data would do that) but the line drops sporadically. It can stay up for a day and a half or it can drop after 30 minutes. There is no obvious pattern. It also appears that the drop is only affecting the upstream because when I see that the stream is down, I can open a browser on that machine an connect to the net with no problem. It is also worth mentioning that the connection will also drop when I connect direct to DSL with no router. The SC stream being lost takes a little more work to recover. Nicecast tries to reconnect, but returns a "login failed" error. The only way to get the streams back up is to ssh to the server and kill the PID, then restart it. I also have to do the same to my relays. What should I be looking at to run down this problem? My first instinct is that the DSL Dyn IP is changing, causing a drop. DSL is with SBC...could they be watching my datastream? It's only 128k and that is the ONLY use that line gets. I don't even DL software updates on that line.

18th January 2005, 21:00	#2
DJ AmPs Major Dude Join Date: Mar 2002 Location: g Posts: 1,603	Do you think the issue could be the remote server? I'm assuming you're using a remote server because you mention only using 128k. BB 192k Mp3 HIGH DEFINITION \| BB 24k Mp3 \| BB 20k WMA \| BB Community __________________________ My Host - Fast-Serv.com \| Free Shoutcast Hosting - Coming Soon...

19th January 2005, 00:32	#4
djSpinnerCee Forum King Join Date: Aug 2004 Location: Hollis, Queens/The Bronx, NYC Posts: 3,555	Do you notice if the IP of your source changes during this process -- You want to determine if it is in fact an issue with your broadband connection [a brief connectivity loss followed by an IP change would be a sure indication that would not effect browsing], or if there is network congestion somewhere between you and your DNAS. Since you can still browse -- connect to the DNAS station page [admin.cgi] and kill the source -- this will allow a more graceful recovery, you could also decrease the DNAS source idle timeout, so that the DNAS drops the connection sooner after the source stops sending data -- this will allow you to know when the problem occurs sooner, and your NiceCast may be able to recover faster [it should also have a reconnection timeout that you can decrease]. Lastly, but probably the most important -- You're streaming at your source upload limit -- not likely to work over time -- I would guess that at 96k you would have much better luck. In your case, the source is under-running -- to do what you want, your connection would have to be 110% perfect every minute of every day -- not likely for residential broadband. /* v2 HTML5 / Player test pages DigitalMixNYC, DigitalMixNYCbx \| DNAS Status: Now Playing js codes (scaststatus_X.php) \| PortForward.com \| Upload/Download Speed Test \| No-IP.com: Free Dynamic DNS \| In the YP \| dnasDir */

19th January 2005, 09:22	#6
Baskido Senior Member Join Date: Apr 2004 Location: ^ in a tree Posts: 291	well thats very funny as i had the same problem :WITH THE SAME ROUTER!: i fixed it by assigning the server a new local ip on the router I'm Back! Tune In!

19th January 2005, 11:38	#7
djSpinnerCee Forum King Join Date: Aug 2004 Location: Hollis, Queens/The Bronx, NYC Posts: 3,555	Zero may be too small for the source idle timeout -- sometimes a zero value indicates NO TIMEOUT -- try 5 seconds. I'll add that your problem may be that your source is not automatically reconnecting as well -- the DSP has both a Reconnection time value and a logical (yes/no) "Reconnect on connection Failure" that will tell the source to reconnect when the link fails -- you want both to occur. The DSP reconnect time should be greater than the DNAS value to prevent the source from trying to attach to the DNAS before it closes the stale (idle) source connection. /* v2 HTML5 / Player test pages DigitalMixNYC, DigitalMixNYCbx \| DNAS Status: Now Playing js codes (scaststatus_X.php) \| PortForward.com \| Upload/Download Speed Test \| No-IP.com: Free Dynamic DNS \| In the YP \| dnasDir */

18th January 2005, 22:05	#3
everettmarshall Junior Member Join Date: Aug 2004 Location: St. Louis, MO USA Posts: 18	I am also looking at that possibilty--in fact HIGHLY probable. What I know is this: DSL connection is up... DSL drops... Nicecast is doing its job: Trying to reconnect when the connection is lost... DSL is back up... The remote server is not allowing Nicecast to login again. I have to kill the sc_serv PID and relaunch SC. THEN Nicecast can login. SC isn't releasing the port after the connection is lost so it must think Nicecast is still connected. I have a feeling that this problem coincides with my server having to be rebuilt. I originally had RedHat 9 and didn't have this problem. When there was a security issue, my host rebuilt the server and installed Fedora--they didn't ask they just changed it.

19th January 2005, 02:08	#5
everettmarshall Junior Member Join Date: Aug 2004 Location: St. Louis, MO USA Posts: 18	Source idle timeout is currently 0s. A far as upload speed goes, I'm fine. I have a 384 upload which usually tests more in the 425 range.

20th January 2005, 19:25	#8
destroyerdotnet Member Join Date: Aug 2003 Posts: 81	there is info on this in the nicecast forum @ audio hijack. I think its a bug. (one of our djs uses it)

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