De-duping Calls

[apu]

Anything feeds can do to help you de-dupe calls better? For example, in the above screenshot, the middle call (8;43:58 PM for 6 seconds) actually contains all the audio from the first and last calls.

 

[n0esc]

The efforts to reduce call skew that admin has posted about are a key fix to this. I took a look at the three calls and I think the difference is that your node is running SDRTrunk and uploaded the two individual calls with a .5-1.0sec higher skew time. Node 2167 is a TrunkRecorder node and the longer transmission hit with a more "accurate" timestamp so it looks like a different call both in duration and timing. The farther down BCFY is able to drive that skew, the more picky they can make the algorithm to detect duplicates, but in your case with two different ingest methods there is definitely some more complex problem solving to eliminate true duplicates while at the same time not negativity impacting something like patched TGs.

 

[GTR8000]

The issue in the example the OP posted has to do with the node software combining transmissions from differing sources into a single file, as opposed to multiple files (one for each source transmission). Call skew didn't come into play there.

To a certain degree, it's impossible to completely prevent duplication as noted in the posted example. BCFY has no way to determine that the 6 second transmission is actually a combination of individual transmissions that another node properly separated.

It is what it is, as they say.

 

[apu]

It is what it is, as they say.

No expectation of perfection. Just wondering if there is any tweaking that could help. Certainly an accurate clock is part of the de-dupe algorithm as n0esc pointed out.

I suppose everyone using the same software could help but that seems boring. Or the possibility of a problem in that one tool disabling multiple feeds negating the benefits of "upload them all and let Lindsay/RR/BCFY sort it out."

 

[WX9MDT]

Is the dev team for SDRTrunk active on the forums at all, has it been pitched as a feature request to them to try and match the timeout that TrunkRecorder does by default? I think that if SDRTrunk were to combine transmissions in a similar manner then we would only have to deal with the time sync issues for situations like these, unless I am missing something else? I am currently having a similar issue in Iowa where there is a provider feeding simulcast sites (using SDRTrunk), so I sometime hear the same traffic up to 3 times. Once each from his two feeds which seem to not be in sync, then Once from my own feed as the whole longer transmission combination.

 

[belvdr]

Is the dev team for SDRTrunk active on the forums at all, has it been pitched as a feature request to them to try and match the timeout that TrunkRecorder does by default? I think that if SDRTrunk were to combine transmissions in a similar manner then we would only have to deal with the time sync issues for situations like these, unless I am missing something else? I am currently having a similar issue in Iowa where there is a provider feeding simulcast sites (using SDRTrunk), so I sometime hear the same traffic up to 3 times. Once each from his two feeds which seem to not be in sync, then Once from my own feed as the whole longer transmission combination.

I don't think he is a member here, but you can review the list of issues and feature requests here:

DSheirer/sdrtrunk

A cross-platform java application for decoding, monitoring, recording and streaming trunked mobile and related radio protocols using Software Defined Radios (SDR). Website: - DSheirer/sdrtrunk

github.com

 

[n0esc]

https://forums.radioreference.com/members/dsheirer.274887/

He is active here as well, but I agree that the better and preferred location is on the application GitHub page.

 

[depster00]

I would think that the better way to accomplish this is for all transmissions to be separated. In my area there are several simulcast systems which allow re-broadcast of transmissions on their sites. So for an EMS dispatch I may have the call come over all 3 systems, the transmissions are all skewed by several ms. If the software were told to "combine" the transmission until the conversation was complete - how does it determine which system to listen to, which calls to combine and when to end? There seems to be too much ambiguity to make a "standard" way of combining?

 

[GTR8000]

Each individual transmission should be separate. That is to say, each PTT from a unique subscriber. There is absolutely no way for software to know what constitutes a full transmission (back and forth between subscribers), and so no combining should take place.

In any event, that is how the majority of software behaves, so if some bit of software is combining transmissions, it's less than ideal and likely not in keeping with what Lindsay wants for the Calls platform.