audio1.broadcastify.com failure?

[telvana]

Greetings,

I have been having an issue with my feed and I cannot locally connect to audio1.broadcastify.com — it was working great, until it wasn’t. Nothing has changed on my end, so I am at a loss here for what I can do as my feed is down and I cannot bring it back up. I can ping audio2 just fine, but of course I can’t use it as I am not authorized to do so.

PING audio1.broadcastify.com (174.127.114.11): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2

--- audio1.broadcastify.com ping statistics ---


4 packets transmitted, 0 packets received, 100.0% packet loss

 

[a417]

PING audio1.broadcastify.com (174.127.114.11) 56(84) bytes of data.
64 bytes from kidneycarenw.com (174.127.114.11): icmp_seq=1 ttl=51 time=62.0 ms
64 bytes from kidneycarenw.com (174.127.114.11): icmp_seq=2 ttl=51 time=61.3 ms
64 bytes from kidneycarenw.com (174.127.114.11): icmp_seq=3 ttl=51 time=60.0 ms
64 bytes from kidneycarenw.com (174.127.114.11): icmp_seq=4 ttl=51 time=71.9 ms

hmmm.

 

[telvana]

PING audio1.broadcastify.com (174.127.114.11) 56(84) bytes of data.
64 bytes from kidneycarenw.com (174.127.114.11): icmp_seq=1 ttl=51 time=62.0 ms
64 bytes from kidneycarenw.com (174.127.114.11): icmp_seq=2 ttl=51 time=61.3 ms
64 bytes from kidneycarenw.com (174.127.114.11): icmp_seq=3 ttl=51 time=60.0 ms
64 bytes from kidneycarenw.com (174.127.114.11): icmp_seq=4 ttl=51 time=71.9 ms

hmmm.

Yep, the reverse DNS is a bit out of whack as you can see, but I don’t think that’s the cause of my issues as I cannot ping it via IP either.

 

[belvdr]

Ping failure doesn't necessarily mean anything as it relates to services. So many things filter ICMP packets, it's better to test the port directly.

 

[blantonl]

audio1 is cranking along like a champion with no issues noted now or anytime in the recent past few weeks.

 

[a417]

audio1 is cranking along like a champion with no issues noted now or anytime in the recent past few weeks.

you know the old axiom @blantonl, it's always DNS.

 

[lazierfan]

My feed has had over a dozen events of failure Tuesday alone. It has had failures for weeks now, and it has been rock-solid since 1995.
My ISP has only made our internet on our home campus even more robust and 100% reliable, with no other service interruptions whatsoever.

Please repair your audio1.broadcastify.com now that you have had multiple complaints.
Feed: West Metro, Jefferson County, Colorado


I add to this thread only because this has been highly unusual for what you provide.

 

[a417]

There's more to the internet than "your ISP" and the servers that lindsay's company provides. Every day I read about temporary backhaul outages, BGP issues, misrouting, etc. Each of those can temporarily disrupt your feed.

 

[lazierfan]

There's more to the internet than "your ISP" and the servers that lindsay's company provides. Every day I read about temporary backhaul outages, BGP issues, misrouting, etc. Each of those can temporarily disrupt your feed.

I completely understand.
I also ask that you logically examine that my experience overall has been intensely positive for over 26 years providing a feed. Steady, rock solid and forsaking any issue along the great interwebs. and then, boom. the feed has issues, but not the rest of my internet experience with work, streaming tv, Zoom meetings, monitoring, security, webcams.

 

[ProScan]

I completely understand.
I also ask that you logically examine that my experience overall has been intensely positive for over 26 years providing a feed. Steady, rock solid and forsaking any issue along the great interwebs. and then, boom. the feed has issues, but not the rest of my internet experience with work, streaming tv, Zoom meetings, monitoring, security, webcams.

The problem is probably on your end, or the ISP, or the last mile (if copper). Some folks use a program called PingPlotter to narrow in on the problem. Broadcastify uses Icecast servers which is TCP based. TCP is a connection oriented protocol so it is more susceptible to flaky cables and connectors, NIC cards, router ports, ISP, copper interconnects, etc... Zoom, webcams, etc if using UDP, the problem may not be noticed because it's connectionless.
Also ensure that you're not using AVG antivirus software as that will break the TCP connection.

 

[lazierfan]

Thank-you for the constructive input, I appreciate this.
The connection is Linux directly to the router, no AV no port sniffers to that particular device, by design so I wouldn't have these type of problems. And our provider uses rock-solid reliable land-based microwave.
I suspect port blocking somewhere past the backbone toward the audio1.broadcastify.com server.

Again, if any of the above were the culprit, Zoom Meetings, streaming video, Webcams, anything you can think of on my LAN (all using specific ports on the TCP/IP protocols) would exhibit problems as well. They Don't.

 

[a417]

I completely understand.
I also ask that you logically examine that my experience overall has been intensely positive for over 26 years providing a feed. Steady, rock solid and forsaking any issue along the great interwebs. and then, boom. the feed has issues, but not the rest of my internet experience with work, streaming tv, Zoom meetings, monitoring, security, webcams.

Unless the remainder of the services you are using are using the exact same pathing, encapsulated in the exact same methods & use the exact hardware to the exact same end points your feeds are going, your example of "the rest of your internet experience with work, streaming tv, Zoom meetings, monitoring, security, webcams" is moot.

If you had another service being hosted by the same underlying infrastructure as the audio1 server, i might consider that...but every little 1 and 0 that comes out of your house only colocates with your stream as far as your first couple of hops at your local ISP. After that, it's up to backbone providers...

 

[lazierfan]

Also, the indication that it is not the server running the icecast in Linux as the feed: totally autonomous operation, it reconnects to the downed server once it sees it without human intervention, and the uptime on my server is measured in weeks.

Behavior of power loss to the Linux server would be human starting Icecast manually. thats how I have it set up.

 

[a417]

I don't feel you fully understand how internet routing works. The problem is either in the last mile from your ISP, or it's in the backhaul between the audio1 server and your ISP. You seem to be insistient on blaming Broadcastify, when there are a great many other factors that go into bits coming from your scanner, and going to the audio1 server. Using "browsing and games" as proof that the problem absolutely has to be Broadcastify's problem further proves my point.

 

[lazierfan]

never mentioned games.

Maybe its ports at the last mile of the
audio1.broadcastify.com
server.
why discount that fact?
I do take that into account. we are analyzing the last two weeks of poor service vs. 23 years of rock-solid streaming from me.

poster Telvana should be so fortunate to get this stellar feedback; this is his thread.

Look, it comes down to listener experience. I am going to bat for the listeners, due to the notifications I get from them, so I bow out now, I tried, listeners.

 

[a417]

poster Telvana should be so fortunate to get this stellar feedback; this is his thread.

...which you hijacked. Since we're being pedantic, is it 23, 26 or 27 years of streaming consecutively w/o any downtime?

Tell me you don't know anything about internet routing, without telling me you don't know anything about internet routing. I see you've already gone first...

On behalf of the listeners, TYFYS. Have a good night!

 

[n0nhp]

Listen to my own feed all the time..
No problems on audio 1

 

[ProScan]

Maybe its ports at the last mile of the
audio1.broadcastify.com
server.
why discount that fact?
I do take that into account. we are analyzing the last two weeks of poor service vs. 23 years of rock-solid streaming from me.

Why don't you just try PingPlotter. It's worth a try and should isolate the problem. Zoom and webcam streaming is not a valid test on intermittents.

 

[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.

 

[GTR8000]

I manage multiple feeds at multiple geographically diverse locations using different providers that are on audio1, and I haven't had a single issue with any of them in months.

Audio1 is fine. Something else was at play with your feeds.