search

robotastic / trunk-recorder

Records calls from a Trunked Radio System (P25 & SmartNet)
GNU General Public License v3.0
878 stars 196 forks source link

v4.0 - Duplicate Calls on Smartnet #535

Open UberPlexCa opened 3 years ago

UberPlexCa commented 3 years ago

Ever since I went to 4.0 last week, I am getting a lot of duplicate calls being uploaded to my Rdio-Scanner. I even pulled the most recent copy of trunk this morning with the same issue. When there is a lot of traffic on the system seems to be when it happens.

This is a Smartnet system with both Analog and Digital TG's.

Could this be the new system where chunks of calls are merged before upload?

robotastic commented 3 years ago

Just to double check, are you using the Github repo and building from source, or using a docker container? I have to double check that the docker container has the latest version.

Is it with Analog TG or Digital, or both? Could you check to see if the same Call is getting recorded multiple times - like are there the same Call in 2 different .wav files? If not, the problem could be that it is being sent multiple times to Rdio-scanner.

There is a thread over there, but it doesn't look there is an issue: https://github.com/chuot/rdio-scanner/issues/61

UberPlexCa commented 3 years ago

I do everything from the GitHub. I am going to look at my archives, I keep everything and I am going to see if I can track down if any are dups in there.

I thought it was Analog Only but today I heard it happening on Digital comms as well.

UberPlexCa commented 3 years ago

So I was listening and found a spot when it happened. Now there is no duplicate .wav files and I can't really see that it did two of them in the logs.

Oct 21 22:14:05 trunknew Rdio Scanner[146]: NewCall: system=100 talkgroup=8704 file=8704-1634868829_141375000-call_125.m4a Success Oct 21 22:14:07 trunknew Rdio Scanner[146]: NewCall: system=100 talkgroup=8800 file=17344-1634868836_142005000-call_128.m4a Success

8704 is patched into 17344 All the calls are showing up on trunk as 8704 but it got 17344 from someplace. I don't save the .json files but is it possible it isn't doing the patches right?

And do you need me to do anything?

UberPlexCa commented 3 years ago

Just to double check, are you using the Github repo and building from source, or using a docker container? I have to double check that the docker container has the latest version.

Is it with Analog TG or Digital, or both? Could you check to see if the same Call is getting recorded multiple times - like are there the same Call in 2 different .wav files? If not, the problem could be that it is being sent multiple times to Rdio-scanner.

There is a thread over there, but it doesn't look there is an issue: chuot/rdio-scanner#61

Yeah I seen his thread, I added "audioArchive": true, "transmissionArchive": false,

Into my configs per his info, lets see what happens.

aaknitt commented 3 years ago

Oct 21 22:14:05 trunknew Rdio Scanner[146]: NewCall: system=100 talkgroup=8704 file=8704-1634868829_141375000-call_125.m4a Success Oct 21 22:14:07 trunknew Rdio Scanner[146]: NewCall: system=100 talkgroup=8800 file=17344-1634868836_142005000-call_128.m4a Success

8704 is patched into 17344 All the calls are showing up on trunk as 8704 but it got 17344 from someplace. I don't save the .json files but is it possible it isn't doing the patches right?

There are different ways that "patching" can be done. If they do a "simulselect" or "multiselect" at the console, it's simply transmitting the same audio to two different talkgroups that end up getting two different frequency grants and this will result in a recording in trunk-recorder for each talkgroup and then both will play back to back in rdio-scanner (assuming you've got both enabled for monitoring).

Other methods of patching do the patch at the system level rather than at the console...those methods result in a single frequency grant being used for the patch and therefore only one recording in trunk-recorder.

Seems like perhaps you're getting some simulselect/multiselect operations and trunk-recorder is behaving as expected...it's got no way of knowing that those are duplicate transmissions since they're actually on different talkgroups and different frequencies...it's the same as if someone were to key up two radios on different talkgroups and talk into both of them at the same time.

johnrockie commented 3 years ago

Not sure if I should have created a new issue but having similar issues with my Trunk P25 since upgrading to V4 for a week now. Mainly getting duplicates due to the call being recorded multiple times while its already recording. Below are some logs I found and links to an example in openmhz of one of many examples, I have noticed the issue even when the system is not busy. I have not changed anything from V3

Log: https://pastebin.com/raw/4jD4cAZ2 Config: https://pastebin.com/raw/x3x6rjjH

Link to openmhz call with multiple recordings and repeats in order.

https://openmhz.com/system/loco?call-id=61744af579a46626f39f854b&time=1635011277001 https://openmhz.com/system/loco?call-id=61744af579a46626f39f8544&time=1635011293001 https://openmhz.com/system/loco?call-id=61744af879a46626f39f857b&time=1635011300001 https://openmhz.com/system/loco?call-id=61744b0079a46626f39f8689&time=1635011322001 https://openmhz.com/system/loco?call-id=61744b0e79a46626f39f885c&time=1635011326001

files

UberPlexCa commented 3 years ago

Well now I don't feel crazy

carissavixen commented 3 years ago

Not crazy, I'm seeing duplicates as well. I'm kinda wondering if the code change to better detect frequency re-use at the end of a call is unintentionally starting extra recorders.

robotastic commented 3 years ago

@johnrockie Thanks for documenting this so well. I will dig into it.

robotastic commented 3 years ago

Ah - This looks like it is Phase 2 audio... it is possible that something could be screwed up for Phase 2.

robotastic commented 3 years ago

@johnrockie Just to double check - you were on version 4.0.2? That version fixed some duplicate call errors. If I am hearing it right there was some overlap on the first 2 calls, right?

The way it works in v4.x is that a recorder will keep going until it gets a termination signal on the voice channel. That signal happens when the person transmitting lets up on the PTT button. While they are talking, messages should also be going out on the control channel, saying that TG has that frequency.

Looking at the logs, it looks like the following happened:

It is weird - it is almost like Update messages stop getting sent out on the Control Channel. I am not sure why the calls are ending while a transmission is still going.

Could you try setting "controlWarnRate": -1 in the config.json at the top level? This will output the number of control channel messages you are getting. It should be around 39 per second for P25.

There of course could also be some sort of bug... or maybe this is just what the system does. I will try to look at the raw P25 Control Channel messages to see if I can spot this happening. Maybe some P25 systems broadcast the talkgroup assignments less frequently.

One other option to try is setting: "callTimeout": 4 or even to 5, at the top level of the config.json.

UberPlexCa commented 3 years ago

Would it be worth trying those same settings on my system or is this just for P25?

johnrockie commented 3 years ago

@johnrockie Just to double check - you were on version 4.0.2? That version fixed some duplicate call errors. If I am hearing it right there was some overlap on the first 2 calls, right?

The way it works in v4.x is that a recorder will keep going until it gets a termination signal on the voice channel. That signal happens when the person transmitting lets up on the PTT button. While they are talking, messages should also be going out on the control channel, saying that TG has that frequency.

Looking at the logs, it looks like the following happened:

  • at 13:48:05 on Call 70, the user starts the 3rd transmission of the Call, and it lasts for 29 seconds.
  • However at, 13:48:13.008868 Call 70 is stopped because there hasn't been an update message on the Control Channel is the past 3 seconds.
  • At 13:48:13.706171 a control channel message comes through and a new Call (72) is started, and it adds a new recorder to also record the same Transmission that the recorder from Call 70 is already recording.
  • Call 72 stop at 13:48:20.008367 because there hasn't been an update on the control channel
  • Call 73 starts at 13:48:20.543914 ...
  • At 13:48:37.003722 the original recorder stops because the transmission ends.

It is weird - it is almost like Update messages stop getting sent out on the Control Channel. I am not sure why the calls are ending while a transmission is still going.

Could you try setting "controlWarnRate": -1 in the config.json at the top level? This will output the number of control channel messages you are getting. It should be around 39 per second for P25.

There of course could also be some sort of bug... or maybe this is just what the system does. I will try to look at the raw P25 Control Channel messages to see if I can spot this happening. Maybe some P25 systems broadcast the talkgroup assignments less frequently.

One other option to try is setting: "callTimeout": 4 or even to 5, at the top level of the config.json.

Yes, I was using 4.0.2 and now using 4.0.3 and after updating it and changing timeout to 5 seconds it seems to have fixed many of the duplicates, cuts and leaks, only a small number of them now. I am getting a steady 37.333, count 112 decode message. I would like to add that I also have a 2nd P25 P2 system (Prince William County) on Airspy not HackRF and that one has no issues at all. I'll continue to investigate but for now it seems to be stable enough. Thank you!

devicenull commented 3 years ago

I'm seeing this with the op25-update branch still - https://gist.githubusercontent.com/devicenull/0dc97a3dc9fae35f8c6a871895c27e4f/raw/6adf4f101a33709933086b2f410f654cfd53c7c0/gistfile1.txt

Overlapping audio files are here -https://www.dropbox.com/sh/d44586ydo5da5cq/AABv7rbZ5RM24Tea8QkgoBC8a?dl=0