Active shooter - D.C. Naval yard

Sile · Sep 17, 2013

Looks like most DC feeds have been taken off air.

After Sandy Hook, Fairfield Co police feed was taken down, too.

Uncomfortable.

Edit: DC feeds were *not* taken down. The error was mine. See below for discussion of archives issue.

blantonl · Sep 17, 2013

Sile said:
The thing is, I know the audio was working as a live stream, because I was listening to it all morning.

So I'm curious how the recording software seems to have cut in and out randomly...couldn't have been a computer setting, I don't think, as the aberrations are not consistent.

I realize it's a huge commitment to provide streams/archives to RadioReference, and I do appreciate it. Bummer for this particular set of audio, though - will now be impossible to thoroughly review the events of yesterday, unless someone else has recorded a stream.

I looked into this issue yesterday evening - it appears that the archive server that supported the DC Fire/EMS feed had some intermittent connectivity issues yesterday morning which coincided with the timeframes when the incident started. It looks like all feeds that were supported by this archive server saw some intermittent missing archives during that 1 hour or so. At this time, I don't know what caused it (stream loads wouldn't have caused it) - so further investigation is on the way.

blantonl · Sep 17, 2013

Sile said:
Looks like most DC feeds have been taken off air.

After Sandy Hook, Fairfield Co police feed was taken down, too.

Uncomfortable.

I'm not sure what you mean by most DC feeds have been taken off the air. We have excellent coverage of the DC Metro area, minus DC Police which unfortunately went encrypted.

Sile · Sep 17, 2013

blantonl said:
I looked into this issue yesterday evening - it appears that the archive server that supported the DC Fire/EMS feed had some intermittent connectivity issues yesterday morning which coincided with the timeframes when the incident started. It looks like all feeds that were supported by this archive server saw some intermittent missing archives during that 1 hour or so. At this time, I don't know what caused it (stream loads wouldn't have caused it) - so further investigation is on the way.

Very interesting - thank you, and appreciate the followup!

Sile · Sep 17, 2013

blantonl said:
I'm not sure what you mean by most DC feeds have been taken off the air. We have excellent coverage of the DC Metro area, minus DC Police which unfortunately went encrypted.

Referring to the feeds posted on RR for Washington, D.C. I now see them in a different spot on the page, so the error may well have been mine. Apologies if so!

gregsto · Sep 17, 2013

blantonl said:
I looked into this issue yesterday evening - it appears that the archive server that supported the DC Fire/EMS feed had some intermittent connectivity issues yesterday morning which coincided with the timeframes when the incident started. It looks like all feeds that were supported by this archive server saw some intermittent missing archives during that 1 hour or so. At this time, I don't know what caused it (stream loads wouldn't have caused it) - so further investigation is on the way.

This really seems to be an extraordinary coincidence. What other feed's archives were affected in a similar way? (For example....not expecting a whole list)

blantonl · Sep 17, 2013

Almost all 748 of these feeds listed below were affected, meaning they lost a 30 minute archive block from anywhere between 7:00 AM and 8:00 AM EST. Again, most likely due to a connectivity issue between our relay servers and this specific archive server. The archive servers are on "large" amazon Web services instances which means they share bare metal servers with other hosts.

You can be "outraged" and "suspicious" all you want, but the simple reality is that **** happens sometimes, almost always in an inopportune moment. We DO NOT under any circumstances censor audio feed archives at the request of a public safety or government agency. The only times we've removed archives from the database is in cases where a feed provider has a misconfigured broadcast computer that inadvertently broadcasts (and records) and open mic in the person's home/business.

Code:

Sile · Sep 17, 2013

The Washington DC Fire and EMS Audio archives from 16 Sep 2013 are erratic throughout the day.

File sizes vary between 7 KB and 4,098 KB; this is one issue, the second being that even the larger files flatline after 15 minutes.

On examining files from the day before, Sep 15, 2013, these same anomalies are present (erratic file sizes, flatlining even in larger files).

Just in case it's of help.

Sile · Sep 17, 2013

blantonl said:

Almost all 748 of these feeds listed below were affected, meaning they lost a 30 minute archive block from anywhere between 7:00 AM and 8:00 AM EST. Again, most likely due to a connectivity issue between our relay servers and this specific archive server. The archive servers are on "large" amazon Web services instances which means they share bare metal servers with other hosts.

You can be "outraged" and "suspicious" all you want, but the simple reality is that **** happens sometimes, almost always in an inopportune moment. We DO NOT under any circumstances censor audio feed archives at the request of a public safety or government agency. The only times we've removed archives from the database is in cases where a feed provider has a misconfigured broadcast computer that inadvertently broadcasts (and records) and open mic in the person's home/business.

Code:

Feed 2455 in this list is Washington D.C.; feed 2456 in this list is Alexandria, VA. For what it's worth, Alexandria exhibits no flatlining during the time period in question. All files tested (between 7-9 a.m.) are consistent half hour blocks, showing good waveform.

Sile · Sep 17, 2013

Just checked 2404, East Hartford - also fine between 6 a.m. and 9 a.m. EST.

"Flatlining" is the wrong term for me to have used; the Washington D.C. files show an actual cutoff of the recording process, or possibly a section of audio that has been removed.

Rather than a flat, central line (showing that recording is continuing, but there's nothing to record), the recording process cuts off altogether, even though the file length remains good.

Also, for D.C., the file times, as given in the archives listing (a steady progression of half-hour chunks) do not match up with the filename of the downloaded file. D.C. 8:34 a.m., for example, has a file name of 201309160805-212222-2455.mp3.

Trying to wrap my head around it. Appreciate any feedback!

blantonl · Sep 17, 2013

Since I own the Washington DC feed, I had also implemented a beta process that strips dead air time for each archive file, that is while there is an inconsistent file size for each archive file. Some 30 minute blocks have more comms then others. I've since disabled that feature as of yesterday afternoon.

blantonl · Sep 17, 2013

Sile said:
Feed 2455 in this list is Washington D.C.; feed 2456 in this list is Alexandria, VA. For what it's worth, Alexandria exhibits no flatlining during the time period in question. All files tested (between 7-9 a.m.) are consistent half hour blocks, showing good waveform.

That is not true. The Alexandria feed is missing 8:37 AM to 9:07 AM

blantonl · Sep 17, 2013

Just FYI - I spent some time this afternoon to pull together the archives from the DC Fire/EMS feed - our archives appear to have recovered at 8:34 AM CST (it appears we missed the initial dispatch at 8:20 AM CST) but most of the operations were covered well by the archives.

9/16/2013 - Washington DC Fire/EMS response to the Navy Yard shootings

Sile · Sep 17, 2013

blantonl said:
Just FYI - I spent some time this afternoon to pull together the archives from the DC Fire/EMS feed - our archives appear to have recovered at 8:34 AM CST (it appears we missed the initial dispatch at 8:20 AM CST) but most of the operations were covered well by the archives.

9/16/2013 - Washington DC Fire/EMS response to the Navy Yard shootings

That's great news - looks like the filenames are now consistent with the time listings as well. Really appreciate all the work you must have put into this. It will make it a lot easier to get an accurate timeline of events.

Those dispatchers are amazing...completely impressive response on everyone's part to the situation imho.

Thanks again for all the help figuring this out!

blantonl · Sep 18, 2013

Sile, please understand that the actual file names of archive files and their associated date/time stamps are typically in the Central Standard Timezone .... For all feeds. We make the translation via the Web interface for most time zones worldwide for each feed. You should not rely on those individual file names for proper timing of archive mp3 files.

Sile · Sep 18, 2013

blantonl said:
Sile, please understand that the actual file names of archive files and their associated date/time stamps are typically in the Central Standard Timezone .... For all feeds. We make the translation via the Web interface for most time zones worldwide for each feed. You should not rely on those individual file names for proper timing of archive mp3 files.

Thank you - much appreciated! I've been reviewing Newtown, CT audio for so long now that I just take it for granted "1830" refers to 1930 EST, lol. But it's good to have it confirmed as a feed-wide practice - I wasn't sure.

Nonetheless, the minutes still line up, correct? I.e. 1634 in an RR file indicates 1734 EST?

Thank you again!

Best,

Sile

jimmnn · Sep 20, 2013

Did the Naval Yard Radio System fail?

Did failed Navy Fire Department radios cost lives? | STATter911.com

Jim<

gadepp · Sep 23, 2013

Radio Failures

In response to another closed feed directed here.

The decision to use digital or analog modes are really insignificant in the overall scheme of things. The decision which band to use makes a difference. VHF, UHF, 700/800mhz frequencies react differently in various environments. No matter which you choose you must test the entire area to see how well they work and which is best. The problem comes when those who make the decisions on what to get are not the ones who will be using the system. They are often fed info from others, and are also forced to save money and limit options rather than providing a system with adequate coverage. Different manufactures provide radios with many similar options. There are differences with the quality of the equipment.

I also read about encryption. Although I like being able to hear what's going on I do understand why it is used and I am an advocate for its use. I know in the inter-op aspect there is normally none used, however I can understand when it is used under certain circumstances. There apparently does need to be a generic code utilized so all agencies have access to the same code on those channels. This would only block those listening with scanners and those without access to the code used, there by providing at least some protection for responding personnel requiring private communications.

Where I work we are unable to transmit from within buildings most all times, and when you can the signal is not complete so all you get is that digital garbage sound. When signals are received the audio quality is poor and many times difficult to understand what was said. The trunked site is not located on the grounds in which we work, we do not even own the equipment, another agency does. I have always found properly installed Motorola systems to provide the best quality service, although it is very expensive. We use the cheaper M/A Com systems and have numerous problems, our system does not provide coverage to even moderately provide life safety communications for responders.

When gov't officials actually care about their emergency responders and not just say it on TV to make it appear like they do and want to enforce life safety then maybe they will improve one day.

Active shooter - D.C. Naval yard

Sile

Member

blantonl

Founder and CEO

blantonl

Founder and CEO

Sile

Member

Sile

Member

gregsto

Member

blantonl

Founder and CEO

Sile

Member

Sile

Member

Sile

Member

blantonl

Founder and CEO

blantonl

Founder and CEO

Attachments

blantonl

Founder and CEO

Sile

Member

blantonl

Founder and CEO

Sile

Member

jimmnn

Member

gadepp

Member

Similar threads