Why?! Its their system. The public safety sector should be able to say whatever they want, whenever they want, on their system. The public's ability to listen should be the absolute last concern (if even a concern) about a PS system.
The Official Thread: Live audio feeds, scanners, and... wait for it.. ENCRYPTION!
- Thread starter blantonl
- Start date
Why?! Its their system. The public safety sector should be able to say whatever they want, whenever they want, on their system. The public's ability to listen should be the absolute last concern (if even a concern) about a PS system.
It wasn't your FAULT of course - but Broadcastify /was/ the source for said audio. It is absolutely disgusting that the media decided to air the audio in the first place. I honestly don't have THAT big of a problem with the streaming, provided a delay was built in. It is the archive that I have particular issue with. If someone else happened to hear this, or similar, go down and hit the record button, fine. But in this case, it's a "catch all" that is saved for quite a long time.
I'm actually yet to hear one good reason why streams are real-time, and not have a delay of say 10 minutes. I challange you, please, to give us an actual reason, as opposed to just "it's how we do things". At the very least, it would silence people (myself included) who won't shut up about needing a delay built in.
I don't think there will be any good answer to this. It is subjective based on who you are. North Little Rock, AR is allowed to broadcast a delayed feed, while others are told no.
North Little Rock Police Dispatch 1
I've answered this more times than I can remember, but here goes again.
The technical challenges to delaying an individual feed at our server level are fairly easy - using our existing open source implementation it is kind of "hacky" but gets the job done in a reasonable manner. However, scaling it to thousands of feeds would become extremely cost and development prohibitive, and probably won't even work without throwing enormous amounts of resources to a problem with minimal to no return.
Couple that with listener confusion on whether or not a feed is in real time or not. We already get bi*ched at because the feeds are inherently delayed by 30-90 secs.
We do have some exceptions in place for official feed providers who provide the delay on their end. That allows us to hopefully drive more adoption for official providers to participate. Otherwise, we don't allow it.
Regardless, it's not going to shut up people to will continue to argue about needing a delay built in (never mind there is already an inherent delay of 30-90 secs depending on cellular/direct connection etc).
So, when the bi*ching and complaining starts back up, I'll default to "it's how we do things"
So, if an individual wanted to incorporate a delay on their end, it would not be allowed?
Was I not clear in my previous post? At what point was my previous point not crystal clear?
Actually, you weren't.
You indicated that the reason for not allowing delays was due to server-side resources.
If a client-side delay were instituted, what would be the rationale for disallowing that? I simply cannot accept listener confusion as a valid reason for not allowing a delay.
As an aside, how would anyone know there was a client-side delay? Tattle-tales?
That's your freaking problem - not mine.
Put up a feed with an implemented delay on your end - I triple dog dare you.
I know of only a few times this has been discussed, I am sure it has been discussed many more times. I can understand that it gets tiresome. None of the times I have read provided a link to previous threads.
Sent via Tapatalk
When you did not address the delay being incorporated at the feed supplier's end.
A standardized delay could be specified, and, possibly, listed on the feed information. The inherent propagation delay is beyond control, and reasonable people understand that. (There is no pleasing some people, and I know you deal with a lot of that.)
I am hoping some compromise can be reached, as none of us want to see the feeds die.
Sent via Tapatalk
A department in my state provides a private feed for specific entities since they went encrypted. Even that feed can be delayed and fed to media on a separate IP as needed.
IMHO, EVERY feed provider should implement a 15 minute delay on all public safety feeds submitted to blastify thus putting the cost of delay technology on the provider, and LCBIII should NOT archive any feeds. This will significantly reduce his perceived operating costs at the same time required broadcast subscribers to actually do more work by recording more streams of interest to get those 'juicy stories' they crave. A new revenue source could be to charge by the amount of feeds simultaneously connected to by each subscriber.
IMHO, EVERY feed provider should implement a 15 minute delay on all public safety feeds submitted to blastify thus putting the cost of delay technology on the provider, and LCBIII should NOT archive any feeds. This will significantly reduce his perceived operating costs at the same time required broadcast subscribers to actually do more work by recording more streams of interest to get those 'juicy stories' they crave. A new revenue source could be to charge by the amount of feeds simultaneously connected to by each subscriber.
It was crystal clear. I just wanted you to confirm that you will allow it if a department wants it, which increases your ability to advertise "official feeds," but if a person is trying to implement it for the EXACT SAME REASON a department would want to, you have no time or need for that feed provider. More indication that you place no value whatsoever on those providing the major content of your business model.
That statement is simply an opinion promulgated by yourself.
Remember, I'm the one in charge here who sets policy, procedure, and how we do things. So let's not lecture me on my "business model" because frankly, you don't know you are talking about. Again, you are armchair quarterbacking an operation that you have ZERO business understanding of. It would be like me telling you how to shoot fire photos. Its ridiculous.
Until you become a shareholder or officer in this company and operation, you're just going to have to suck it up buttercup and realize that, while you think you know what's best for this business, you really are just going to have to acquiesce to what I say happens around here. Period.
Otherwise you might as well piss up a rope.
This is like talking to my 11 year old daughter, who at times thinks she knows it all. It's freaking hilarious.
Yeah, fire photos, that's all I do.......
I had been asked by superiors what would be necessary to implement an official feed with a delay. I had looked at various methods, but now I'm going to tell them it's not worth it. I find it absurd that if I were to write you a letter on department letter head, I could implement the delay, but if it's just me, using the exact same knowledge base and equipment, it's considered unacceptable.
I don't understand this post. I'm not sure how I backed you into a corner to warrant this response, but if this response is insinuating that you've got bigger and broader professional responsibilities that would add legitimacy to your armchair quarterbacking of this operation- well, no dude, sorry, you don't. Come on man...
Wait, really? Disregard all my last... I'm soooooooo sorry. In light of this news we will completely revamp all of our policies and procedures to accommodate the potential losses that could occur to our platform because of this veiled "threat" :roll:
Attachments
Yes, actually I am myopic. Corrected to 20/20 with glasses.
You entirely missed my point. I was approached because of my experience in having had online feeds in the past. I would be the one administering the feed, and because of a piece of paper, it would be fine, but if I did it without that piece of paper, you have no use for me. Double standard?
You entirely missed my point. I was approached because of my experience in having had online feeds in the past. I would be the one administering the feed, and because of a piece of paper, it would be fine, but if I did it without that piece of paper, you have no use for me. Double standard?
The wonders of modern medicine, but which still hasn't solved the affliction of lacking imagination, foresight, and intellectual insight into how things operate around here and in the business world in general.
Double standard? No. Strategic business decision? Yes. If you, with your superior armchair quarterbacking abilities can't understand or agree with our position further, then I don't owe you any further explanation. It is a simple as that.
From the earlier posts, it seems:
- that RR wants unofficial feeds, and shows its appreciation by offering the unofficial feed-provider a Premium Membership, even with anonymity,
- that RR wants official feeds, and because they are harder to get and are the best type of feed to have, it shows its appreciation by offering the official feed-provider the opportunity to use a feed-provider-induced delay,
- that RR does not have a double-standard, just simply multiple levels of benefits depending on the type of feed-provider,
- that the unofficial feeds are likely provided by hobbyists who often download data from the RRDB and would benefit from the premium membership; whereas the official feeds are likely by agencies (which I'm guessing have little to no need for downloading from the RRDB, but) which would be interested in a delayed broadcast option.
If RR offered both the premium membership and the delayed-feed option to unofficial feed providers, why would anyone ever choose to go through all of the extra work to setup an official feed, which is often the highest quality feed possible? As indicated in the red-font in the earlier posts, the delay option is an incentive to attract premium feeds.
Just one distant perspective on what the business model motivations might be,
Last edited:
Similar threads
