Lindsay has advised that these servers are pretty loaded so the delay can be expected.
Feed delay?
- Thread starter voxiso
- Start date
- Status
Folks,
Delays are to be expected for the feeds. I wouldn't call it uncommon for some feeds to have delays of 1 to 2 minutes.
We do have some server upgrades scheduled in the next few weeks, so it might bring down the delay time once that occurs. But, understand that we are streaming THOUSANDS of feeds - so processing and routing all that data is not going to be in real time.
Delays are to be expected for the feeds. I wouldn't call it uncommon for some feeds to have delays of 1 to 2 minutes.
We do have some server upgrades scheduled in the next few weeks, so it might bring down the delay time once that occurs. But, understand that we are streaming THOUSANDS of feeds - so processing and routing all that data is not going to be in real time.
1 to 2 minutes? Man, it was just a few short months ago that the delay was a minuscule ~10 seconds. To think, a few months ago I complained when the delay went from ~10 seconds to ~35 seconds...now we're measuring the delay in minutes. It's a real shame that the servers have gotten that bogged down and overloaded. Seems like the usage has grown exponentially while the capacity and number of servers has remained largely the same. 
webstar22
RenfrewCountyScanner.com
I don't know why you all are complaining about the delay. It makes no sense as people listening unless they have a scanner in the same area have no idea it's being delayed.
It is a free service but all you see is people complaining about it.
It is a free service but all you see is people complaining about it.
1 to 2 minutes? Man, it was just a few short months ago that the delay was a minuscule ~10 seconds. To think, a few months ago I complained when the delay went from ~10 seconds to ~35 seconds...now we're measuring the delay in minutes. It's a real shame that the servers have gotten that bogged down and overloaded. Seems like the usage has grown exponentially while the capacity and number of servers has remained largely the same.
Did you convientently skip over reading where I said:
We do have some server upgrades scheduled in the next few weeks, so it might bring down the delay time once that occurs.
Hey everyone, listen up….this is how HTTP streaming works. There is a delay involved when taking HTTP packets, 2400 concurrent at a time, and queueing that up to 10-15 thousand clients. And we're not going to drop thousands of additional $$ on infrastructure so some of you with a stop watches feel better that you heard the audio from your scanner and then only 5 seconds later from your computer.
I swear to God that some of you guys are exasperating at times when it comes to this Live Audio platform.
"Waaaahhh.... the server went down and all my clients disconnected, WTF????"
"The listener counts are off on my feed... it says 9 on the user list but I only see EIGHT on the feed listing !!!!! What kind of operation are you running???"
"OMG.... my feed is delayed by 39.4 seconds!!!!"
"Why is XXX Feed Down??? WTF???? "
"The feed disconnected in my browser after 8 hours... WTF??? I have to restart my browser every EIGHT HOURS???? You guys suck!!"
:roll:
Seriously, if you want better, go do it yourself! Just as I tell my kids "You get what you get, and you don't get upset"
Don't get me wrong, we listen to all feedback and welcome it, but the complaining and whining is almost getting to a fever pitch. You ought to see what we have to deal with from feed providers and listeners via email on a daily basis.
</rant>
Last edited:
webstar22
RenfrewCountyScanner.com
ROFL.... Well Said.
To those who want to hear there feed realtime. buy Proscan, connect to yourself and poof it will be instant.
I know that using HTTP opens the sockets via TCP, does the stream then become a UDP after that? Being a UDP wouldnt have to worry about the checksum or syn for each stream basically just putting out a netbroadcast.
It's TCP all the way from source client to server and from server to the media player.
Performance of TCP vs UDP is for all practical purposes nearly identical. On UDP, applications are responsible for the re-ordering, error detection, and requesting packet resend.
scaredpoet
Member
Well, on this note...
Let me just say first that I've been very happy n the short time I've been on RR and providing a feed. This forum was helpful in solving my problem rather quickly and the feed I'm providing has been successful. Is there a delay? Yeah, but that's the nature of streaming. I deal with streaming stuff all the time in my day job, and the behavior and performance of the streaming servers here is right in line with what anyone should reasonably expect.
That said, I did kinda wonder: I do have the means, the bandwidth and a commercial-grade server in a Tier 1 datacenter to self-host an audio feed. But doing so means that it wouldn't be listed here for others to easily access (including the many smartphone apps that rely on RR for their feed listings).
Might there be a way for someone who has the ability and expertise to host their own feed server "affiliate" with RR? It would seem like a win-win: RR gets to list a feed, but it's one less bit of audio that would have to be hosted on your streaming servers, and one less reason to have to spend money to upgrade capacity and bandwidth. All the terms of feed hosting could still be enforced: anyone who breaks the rules, or can't keep their broadcast server online for a certain minimum level of reliability would get their feed listing dumped, and they're on their own unless and until they show that they're back in line.
Then again, I guess it would open up a whole new can of worms. Like people trying to run servers from their home ISPs or through connections/servers that really aren't meant for that.
Anyway, just thinking out loud here.
- Status
Similar threads
