audio1.broadcastify.com failure?

[blantonl]

Reporting in, my feed has been uptime seven days, and according to Broadcastify, has been continuous feed, no downtime, no alerts received.

I did nothing to improve, and my ISP reports nothing was changed in the past week and in the first five miles of my connection from my radio shack.

We haven't changed a single thing on audio1 in the past, I dunno.... 519 days 😜

[xxxx@audio1 ~]$ uptime
 23:55:03 up 519 days, 23:26,  1 user,  load average: 0.45, 0.23, 0.22

 

[a417]

Maybe it's this?

 

[telvana]

I was switched to audio3, no problems since.

audio1 is also working again (though I am no longer using it), and has been for quite awhile now. Must have been a hiccup somewhere w/ AT&T.


PING audio1.broadcastify.com (174.127.114.11): 56 data bytes

64 bytes from 174.127.114.11: icmp_seq=0 ttl=49 time=30.336 ms
64 bytes from 174.127.114.11: icmp_seq=1 ttl=49 time=30.258 ms
64 bytes from 174.127.114.11: icmp_seq=2 ttl=49 time=30.332 ms
64 bytes from 174.127.114.11: icmp_seq=3 ttl=49 time=30.431 ms
--- audio1.broadcastify.com ping statistics ---

4 packets transmitted, 4 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 30.258/30.339/30.431/0.061 ms

 

[wgbecks]

I'd like to point out that by default, a PING from Windows for example, only sends 32 bytes and is not a very good test aside from the fact that ICMP may be filtered (blocked) or otherwise throttled. I have found many problems on all sorts of networks that pass the default PING but start to fail once you increase packet payload size.

With that, in performing a PING test to a destination that isn't filtered, try sending larger test packets using the (-l) option to increase the payload that servers as a pseudo stress test. IE: PING -L 1400 8.8.8.8 Be careful on the size you select to avoid fragmentation that will also be dependent upon the network transport under test.

 

[blantonl]

Honestly, I think the problem at this point is that 100's of people are just pinging audio1 now for the heck of it. That's probably resulted in some upstream ISP asking "WTF?" and then blocking packets.

Or maybe we're just mind-f***ing the whole thing.

Either way, I love technology. 😜

 

[lazierfan]

Reporting in, my feed has been uptime seven days, and according to Broadcastify, has been continuous feed, no downtime, no alerts received.

I did nothing to improve, and my ISP reports nothing was changed in the past week and in the first five miles of my connection from my radio shack.

Edited to add:
During this entire issue of March 22-30, the actual internet connection never disconnected. If it had disconnected I would have had to restart icecast on the Linux server in order to reconnect. The published graphs from the period are in this thread, and Internet and ports and such were never the root cause. So, either Icecast on my side or the icecast server components on the Audio1 are at fault. Because i saw no logging in my messages file in the Linux os, regarding internet cause, this narrows the search.