Feature request: option to disable conversation recording

[blantonl]

An option to turn the conversation recording feature on and off would be beneficial. The consolidation of conversations audio and metadata is difficult to work with in some architectures.

Individual clips for each call and associated metadata would be a great feature.

[robotastic]

This would be a pretty easy change - I think I can make it over the weekend.

[blantonl]

Checking in on this... any updates?

[robotastic]

Sorry - my coding has taken a dive. I am spending most of my free time herding kids. This is pretty straight forward. I will try to wrap it up this weekend.

[blantonl]

Wanted to ping you and check in on this again for status?

[robotastic]

I am hoping to get PRs #329 and #330 in this weekend. If that goes smoothly, I will roll this in too.

[robotastic]

Hmmm... this may not be as simple as I thought. Generally multiple Grant messages are sent out when a new call is started, so I will have to add in some logic. I might be able to simple do if you get a new grant message and the time of the recording is greater than 1 sec then start a new recording. I could also see if there is a way to look at the source ID of the transmitter... that could get weird in non-P25 systems. There is also the problem that you will probably end up with some of the next transmission in the previous recording because you have to let the audio stream through to make sure nothing is left in the buffers. I will have to poke at this a little.

[EricTendian]

What I've found after testing out MDC1200 source logging for a bit is that splitting into individual calls would rely on knowing whether the MDC1200 chirp is a leading or trailing one, to avoid transmissions being attributed to the wrong source.

I wonder if another way to solve this, at least for cases where it's troublesome within the process of making the recording, is to read the call metadata file and use sox/ffmpeg after the fact to cut up the audio file based on source timestamps in the metadata. For example, if I know my system uses a trailing MDC1200 code, I could theoretically cut out an individual transmission from when a previous user's chirp was heard until this user's chirp was heard. Then, each of those clips could be uploaded one-by-one. For integrating with the existing call uploading process, this would likely be occurring as an alternative to the current m4a encoding command, generating an array of call info structs and associated m4a files.

[JoeGilkey]

@EricTendian on the MDC PTT opcode there is a flag in the args that differentiates if it is a pre-PTT or post-PTT. In the decoder I can add these as different signal types. Those signals can then be used to create a new file or end the existing file.

[EricTendian]

@JoeGilkey interesting, I didn't realize that. That would be helpful, since currently OpenMHz is treating post-PTTs as if they were pre-PTT, not able to handle the source timestamps at the end of transmissions.

[blantonl]

I wanted to revive this again as this issue is becoming more and more critical to address duplicate call handing from multiple sites and different capture nodes for wide area systems.

Trunk-Recorder seems to take a pretty arbitrary approach to recording conversations vs individual calls, and even though the metadata is captured by conversation it is becoming more and more difficult to manage "conversations" vs "calls" - conversations are pretty arbitrary and difficult to manage in structured environments.

[blantonl]

It might also be helpful to rope in some of the other tickets with regards to encrypted calls and how TR handles those - in mixed environments TR doesn't ignore encrypted calls if the start of the conversation is in the clear.

I think it is going to be worth the time and effort to eliminate conversation handling unless it is explicitly enabled.

[natecarlson]

I agree that this would be a useful feature for many cases -- I'd love to see the conversation metadata stored but with individual calls tracked within. Could do server-side splitting of the current conversations. but it seems a bit silly to have the recorder combine and then the server split it back out. :) I'm currently looking into integrating with speech to text transcription, and it looks like having individual speakers in separate files would make it easier.

Looking at the source code, it looks like the simplest way to implement this would be to decouple the concept of a 'call' (which is the current conversation-style) from the recordings.. unless someone has a different suggestion?

Hmm, I should test and see what happens if we just set callTimeout to next to nothing. Now that I'm actually sending my scanner to Broadcastify Calls and OpenMHz instead of just my private server, it's a bit harder to play with the code though! :) I'll have to pick up a few more RTL-SDR's and antennas..

[natecarlson]

OK - setting callTimeout to -1 or 0 causes each call to get chopped into tiny increments, not good. :)

Setting it to 1 does end up in conversations with delays over a second being broken up.. but a lot of responses are faster than one second. Because we use C's time_t, which is only precise to a second, can't do something silly like set this to one microsecond.

Might look and see how hard it'd be to overhaul things to use millisecond or microsecond resolution..

[kcwebby]

The problem with this concept is that there is not a message from the system that definitively separates between one transmission and another. Sometimes they occur on the same frequency, without an additional grant, and sometimes they are recycled to a separate frequency with a new grant. Add in patches and all of the other methods required to try and track this, and it gets very complex/convoluted very quickly.

To do this reliably, you would need the trunked radio system to delineate between transmissions in any particular "call" But right now, the P25 protocol doesn't do any signalling when one person ends and the messages for a subscriber unit starting to transmit can be one of many things. Trunk recorder follows the call "build up" and then follows it until it times out, while it records the unit ID's that it see's talking, it doesn't track the transmissions like that.

This would be an extremely significant rewrite of alot of the code to even start to get this to function.

On Fri, Oct 30, 2020 at 12:58 PM Nate Carlson [email protected] wrote:

OK - setting callTimeout to -1 or 0 causes each call to get chopped into tiny increments, not good. :)

Setting it to 1 does end up in conversations with delays over a second being broken up.. but a lot of responses are faster than one second. Because we use C's time_t, which is only precise to a second, can't do something silly like set this to one microsecond.

Might look and see how hard it'd be to overhaul things to use millisecond or microsecond resolution..

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/robotastic/trunk-recorder/issues/326#issuecomment-719707595, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACSNSASMTI5BVWV7CFANJXTSNL5DLANCNFSM4LUHVOOA .

[natecarlson]

Oh, yikes! Yeah, I haven't looked at the code or p25 protocol in significant detail yet; I assumed that since it logs the unit IDs for each segment that those were readily available during the call flow already, but sounds like that isn't the case.

I'll have to dig in some more just to understand what I can!

[robotastic]

@natecarlson interesting thought on changing the timeout. On the P25/Smartnet control channels, you get 30-40 messages per second. The Channel Grant messages for the different calls are what reset that timeout. You maybe able to go down to 0.5 seconds for a timeout, but not much lower because you don't get that many Grant messages per second.

The real problem is that an End Call message doesn't does not go out over the Trunking Control Channel ( I can go double check the specs).

However there is a second source of control messages and that is on the Voice Channel. There is an End Call message that gets broadcast there... I think. It is not super simple to make use of it though. There is a long pipeline for decoding audio, with buffers in between. The initial P25 decoding happens near the start, so when a End Call message comes in, there could still be audio from that transmission that is still being decoded. I think for it to work, all of the Trunking messages recieved on the Voice Channel would need to be attached to the voice data, as meta data and processed as part of the flow. This we be a bit of intensive surgery, but it may not be impossible. This is already done for the Source IDs, which are decoded off the voice channel.

Anyhow... I think this maybe possible, but not easy. I am game to give it a shot though. We should be able to use the same Calls structure to mange the metadata around a transmission.

[robotastic]

It does look like OP25 is already decoding the Terminator codes on the Voice channels: https://github.com/robotastic/trunk-recorder/blob/5305e8f5320315094bcb646e571f79e5e4f9acb2/lib/op25_repeater/lib/p25p2_tdma.cc#L152 https://github.com/robotastic/trunk-recorder/blob/bfb41e52a751a19bb70efb423fe47f3aea5a24b2/lib/op25_repeater/lib/p25p1_fdma.cc#L383

The trick will be having these messages passed through to the right spots and making sure all the audio gets processed. The messages also get repeated a lot, so we also have to make sure they are only handled once.

[natecarlson]

Awesome, thanks for the details! I'll try to dig into this a bit when I've got some time. I think my first steps will be to get a test scanner set up that can receive the full 6mhz off my repeater (gotta get more RTLs!), find a single TG that gets consistent calls and set up the scanner to only that TG, and then add a bunch of debug logging to help understand what is already available to us.

If it is going to take extensive changes, I'm probably not the best person to make them (i do a lot of architecture work, but came up from the system administration side instead of the programming side.. I can certainly understand what the code is doing, but especially in C my code isn't elegant!) - but we'll see where it goes. Really, that's my long winded way of making sure not to make anyone with coding skills and interest in working on this think that the task has been claimed already. :)

[robotastic]

Cool - I added a bunch of messages on the Analog Squelch branch.

It looks like Channel Grant messages on the Trunk Control Channel are completely seperate from the control messages on the voice channel. So you can have an End message come over on the voice channel and then get Trunk Control grant messages after that. Basically it looks like the Trunk system will dedicate a Channel to a talkgroup. Multiple Transmissions may start and stop on that freq. We could have it that a unique WAV file is created for each transmission and a Call represents a group of unique Transmissions.

Basically, the Trunking Control message govern the creation of a Call which tracks the Grant of a frequency to a talkgroup. A Recorder would be Started to monitor a Freq for that Talkgroup. The Recorder would automatically create a new WAV file for each transmission, and associate each Transmission with that Call. When that Channel Grant times out, that Call would be over and that group of transmission WAV files would be uploaded.

So - the Recorder would become smarter and automatically create new WAV files for each transmission. Instead of an array of Src IDs, there would be an array of recordings with the associated src id.

[natecarlson]

I see that commit - awesome!

And that sounds like exactly what I'd be looking for. Not sure if that would match up with the use case @blantonl has in mind or not, as this method wouldn't necessarily result in individual transmissions being uploaded to the server any faster than they are today.

Should have another pair of RTL's on my doorstep sometime tomorrow, assuming Amazon does their job! That'll give me a total of three to play with on a development box.

[robotastic]

I have some very preliminary code working. Right now it just creates separate wav file for each transmission. Upload is probably broken and so is the JSON file stuff.

Still if someone is able to give the analog_squelch branch a try and see if it chops up P25 system calls correctly that would be cool.

I don't think it works with SmartNet because it doesn't look like they send out the call termination message on the voice channel.

[natecarlson]

That is awesome!!

My additional rtl-sdr's showed up today; once I get a test system built and validated I will give this a try.

(As I've noted elsewhere I'm all P25 at my area for LE. There may be other SmartNet and analog systems in the area, but if there are I haven't tried to find 'em.)

[natecarlson]

Got the RTL's set up and tuned (yay), and have them recording the same data as my production system now. Will check in later to see how things look.

[natecarlson]

Found an issue.. here's the srclist for a call on my prod system.. "srcList": [ {"src": 135702, "time": 1604323391, "pos": 0.000000, "emergency": 0, "signal_system": "p25", "tag": ""}, {"src": 131428, "time": 1604323395, "pos": 3.960000, "emergency": 0, "signal_system": "p25", "tag": ""}, {"src": 131410, "time": 1604323397, "pos": 4.320000, "emergency": 0, "signal_system": "p25", "tag": ""}, {"src": 135702, "time": 1604323402, "pos": 8.820000, "emergency": 0, "signal_system": "p25", "tag": ""} ],

..same from the test system: "srcList": [ {"src": 135702, "time": 1604323391, "pos": 0.000000, "emergency": 0, "signal_system": "p25", "tag": ""}, {"src": 131428, "time": 1604323395, "pos": 3.780000, "emergency": 0, "signal_system": "p25", "tag": ""}, {"src": 131410, "time": 1604323396, "pos": 0.360000, "emergency": 0, "signal_system": "p25", "tag": ""}, {"src": 135702, "time": 1604323402, "pos": 4.500000, "emergency": 0, "signal_system": "p25", "tag": ""} ],

First note is that the position is being reset on the test system -- no big deal (you mentioned upload/json are probably busted), but just wanted to note it.

Then, looking at the audio output files from the test system:

-rw-r--r-- 1 nc nc 72044 Nov  2 07:23 4302-1604323391-131410_855987500.wav
-rw-r--r-- 1 nc nc  5804 Nov  2 07:23 4302-1604323391-131428_855987500.wav
-rw-r--r-- 1 nc nc 63404 Nov  2 07:23 4302-1604323391-135702_855987500.wav

...we've only got three files - looks like if a unit transmits twice it only writes out one file right now?

If I listen to the original file (4302-1604323391_855987500.m4a), I hear:

• 0s: 135702 - Dispatcher asking two squads for status
• 4s: 131410 - One squad responding no secondaries
• 8s: 135702 Dispatcher response

Never hear the message from 131428, looks like it's a short transmission that doesn't have actual content.

Listening to the files from the split recording..

• 131410 file contains the same audio as above
• 131428 file isn't audible
• 135702 file contains the second rmessage from that unit - guessing it overwrote the first one.

So - need to index the files, or include another 'current' timestamp for each of the unit recordings (might make the most sense to keep them in order?)

[natecarlson]

Added a quick patch:

diff --git a/trunk-recorder/call.cc b/trunk-recorder/call.cc
index 877abd3..e0de625 100644
--- a/trunk-recorder/call.cc
+++ b/trunk-recorder/call.cc
@@ -11,6 +11,7 @@

 void Call::create_filename() {
   tm *ltm = localtime(&start_time);
+  current_time = time(NULL);
   long current_source_id = get_current_source();
   std::stringstream path_stream;

@@ -19,7 +20,7 @@ void Call::create_filename() {
   boost::filesystem::create_directories(path_stream.str());

   int nchars;
-  nchars = snprintf(filename, 255, "%s/%ld-%ld-%ld_%.0f.wav", path_stream.str().c_str(), talkgroup, start_time, current_source_id, curr_freq);
+  nchars = snprintf(filename, 255, "%s/%ld-%ld-%ld-%ld_%.0f.wav", path_stream.str().c_str(), talkgroup, start_time, current_time, current_source_id, curr_freq);

   if (nchars >= 255) {
     BOOST_LOG_TRIVIAL(error) << "Call: Path longer than 255 charecters";
@@ -30,7 +31,7 @@ void Call::create_filename() {
     BOOST_LOG_TRIVIAL(error) << "Call: Path longer than 255 charecters";
   }

-  nchars = snprintf(converted_filename, 255, "%s/%ld-%ld_%.0f.m4a", path_stream.str().c_str(), talkgroup, start_time, curr_freq);
+  nchars = snprintf(converted_filename, 255, "%s/%ld-%ld-%ld-%ld_%.0f.m4a", path_stream.str().c_str(), talkgroup, start_time, current_time, current_source_id, curr_freq);
   if (nchars >= 255) {
     BOOST_LOG_TRIVIAL(error) << "Call: Path longer than 255 charecters";
   }
diff --git a/trunk-recorder/call.h b/trunk-recorder/call.h
index ed79e07..1b946da 100644
--- a/trunk-recorder/call.h
+++ b/trunk-recorder/call.h
@@ -132,6 +132,7 @@ protected:
   int idle_count;
   time_t stop_time;
   time_t start_time;
+  time_t current_time;
   bool debug_recording;
   bool sigmf_recording;
   bool encrypted;

EDIT: Ignore the blank file thing I'm discussing below, it seems to be an artifact of how I'm playing the files over the network to my laptop. The files play fine from the zip I uploaded! Looking at it.

..and it looks better. srcList: "srcList": [ {"src": 561078, "time": 1604324858, "pos": 0.000000, "emergency": 0, "signal_system": "p25", "tag": ""}, {"src": 561100, "time": 1604324860, "pos": 1.800000, "emergency": 0, "signal_system": "p25", "tag": ""}, {"src": 561078, "time": 1604324865, "pos": 1.980000, "emergency": 0, "signal_system": "p25", "tag": ""}, {"src": 561100, "time": 1604324869, "pos": 2.700000, "emergency": 0, "signal_system": "p25", "tag": ""} ],

-rw-r--r-- 1 nc nc 29K Nov  2 07:47 33404-1604324858-1604324858-561078_851375000.wav
-rw-r--r-- 1 nc nc 31K Nov  2 07:47 33404-1604324858-1604324861-561100_851375000.wav
-rw-r--r-- 1 nc nc 43K Nov  2 07:47 33404-1604324858-1604324865-561078_851375000.wav
-rw-r--r-- 1 nc nc 15K Nov  2 07:47 33404-1604324858-1604324869-561100_851375000.wav
-rw-r--r-- 1 nc nc 701 Nov  2 07:47 33404-1604324858_851375000.json

Here's the srcList from my prod system: "srcList": [ {"src": 561078, "time": 1604324858, "pos": 0.000000, "emergency": 0, "signal_system": "p25", "tag": ""}, {"src": 561100, "time": 1604324860, "pos": 1.800000, "emergency": 0, "signal_system": "p25", "tag": ""}, {"src": 561078, "time": 1604324865, "pos": 3.780000, "emergency": 0, "signal_system": "p25", "tag": ""}, {"src": 561100, "time": 1604324869, "pos": 6.480000, "emergency": 0, "signal_system": "p25", "tag": ""} ],

The first three calls have similar audio to the segments of the standard file - however, the last call appears to just be someone keying the transmit key and letting go without saying anything.. on the production file you can hear that, 33404-1604324858-1604324869-561100_851375000.wav doesn't appear to have anything audible in it.

Another call (json from prod system): "srcList": [ {"src": 100526, "time": 1604325143, "pos": 0.000000, "emergency": 0, "signal_system": "p25", "tag": ""}, {"src": 104016, "time": 1604325146, "pos": 1.440000, "emergency": 0, "signal_system": "p25", "tag": ""}, {"src": 100526, "time": 1604325148, "pos": 2.700000, "emergency": 0, "signal_system": "p25", "tag": ""}, {"src": 104016, "time": 1604325153, "pos": 5.760000, "emergency": 0, "signal_system": "p25", "tag": ""} ],

Files from split:

nc@teststorage02:~/trunk-recorder/recordings/scarmer2/2020/11/2$ ls -l 54-1604325143*
-rw-r--r-- 1 nc nc 23084 Nov  2 07:52 54-1604325143-1604325143-100526_851375000.wav
-rw-r--r-- 1 nc nc 20204 Nov  2 07:52 54-1604325143-1604325146-104016_851375000.wav
-rw-r--r-- 1 nc nc 49004 Nov  2 07:52 54-1604325143-1604325148-100526_851375000.wav
-rw-r--r-- 1 nc nc 28844 Nov  2 07:52 54-1604325143-1604325153-104016_851375000.wav
-rw-r--r-- 1 nc nc   698 Nov  2 07:52 54-1604325143_851375000.json

On this one, the second recording doesn't have any audible audio.. weird! Probably a race issue in the recording somewhere or something?

Log file attached (logentries.log) - note that there are other recordings happening at the same time too.. pertinent section, I think? (Again, full log attached - this is just small chunks.)

[2020-11-02 07:52:26.698145]:  [0]-[  : Pos - 11520 offset: 0 :
[2020-11-02 07:52:26.698239]:  [1]-[  : Pos - 11520 offset: 0 :
[2020-11-02 07:52:26.698289]:  [2]-[  : Pos - 11520 offset: 0 :
[2020-11-02 07:52:26.698329]:  [3]-[  : Pos - 11520 offset: 0 :
[2020-11-02 07:52:26.698366]:  [4]-[  : Pos - 11520 offset: 0 :
[2020-11-02 07:52:26.698403]:  [5]-[  : Pos - 11520 offset: 0 :
[2020-11-02 07:52:26.698440]:  [6]-[  : Pos - 11520 offset: 0 :
[2020-11-02 07:52:26.698478]:  [7]-[  : Pos - 11520 offset: 0 :
[2020-11-02 07:52:26.698871]:  Skipping to next file, Call Src:  104016
[2020-11-02 07:52:26.699184]: wav wrote: 1440 to: /home/nc/trunk-recorder/recordings/scarmer2/2020/11/2/54-1604325143-1604325146-104016_851375000.wav from source: 0
[2020-11-02 07:52:26.764782]: [scarmer2]        TG:         54 (^[[35m           MSP 2500 DSP^[[0m)     Freq: 851.375000 MHz    Update! 851.375000 MHz  Elapsed: 3s     Since update: 0s
[2020-11-02 07:52:26.889918]: wav wrote: 1440 to: /home/nc/trunk-recorder/recordings/scarmer2/2020/11/2/54-1604325143-1604325146-104016_851375000.wav from source: 0
[2020-11-02 07:52:27.077804]: wav wrote: 1440 to: /home/nc/trunk-recorder/recordings/scarmer2/2020/11/2/54-1604325143-1604325146-104016_851375000.wav from source: 0
[2020-11-02 07:52:27.139477]: [scarmer2]        TG:         54 (^[[35m           MSP 2500 DSP^[[0m)     Freq: 851.375000 MHz    Update! 851.375000 MHz  Elapsed: 4s     Since update: 1s
[2020-11-02 07:52:27.264449]: wav wrote: 864 to: /home/nc/trunk-recorder/recordings/scarmer2/2020/11/2/54-1604325143-1604325146-104016_851375000.wav from source: 0
[2020-11-02 07:52:27.268472]: wav wrote: 864 to: /home/nc/trunk-recorder/recordings/scarmer2/2020/11/2/54-1604325143-1604325146-104016_851375000.wav from source: 0
[2020-11-02 07:52:27.392266]: [scarmer2]        TG:         54 (^[[35m           MSP 2500 DSP^[[0m)     Freq: 851.375000 MHz    Update! 851.375000 MHz  Elapsed: 4s     Since update: 0s
[2020-11-02 07:52:27.455112]: wav wrote: 1728 to: /home/nc/trunk-recorder/recordings/scarmer2/2020/11/2/54-1604325143-1604325146-104016_851375000.wav from source: 0
[2020-11-02 07:52:27.700430]: wav wrote: 1728 to: /home/nc/trunk-recorder/recordings/scarmer2/2020/11/2/54-1604325143-1604325146-104016_851375000.wav from source: 0
[2020-11-02 07:52:27.766698]: [scarmer2]        TG:         54 (^[[35m           MSP 2500 DSP^[[0m)     Freq: 851.375000 MHz    Update! 851.375000 MHz  Elapsed: 4s     Since update: 0s
[2020-11-02 07:52:27.811411]: Call Terminated, NO amount produced: 0 SRC: 0 n written 754560
[2020-11-02 07:52:27.811782]: Call Terminated, NO amount produced: 0 SRC: 0 n written 754560
[2020-11-02 07:52:27.886262]: wav wrote: 576 to: /home/nc/trunk-recorder/recordings/scarmer2/2020/11/2/54-1604325143-1604325146-104016_851375000.wav from source: 0
[2020-11-02 07:52:27.948993]: [scarmer2]        TG:         54 (^[[35m           MSP 2500 DSP^[[0m)     Freq: 851.375000 MHz    Update! 851.375000 MHz  Elapsed: 4s     Since update: 0s
[2020-11-02 07:52:28.141113]: [scarmer2]        TG:         54 (^[[35m           MSP 2500 DSP^[[0m)     Freq: 851.375000 MHz    Update! 851.375000 MHz  Elapsed: 5s     Since update: 1s
[2020-11-02 07:52:28.141330]: [scarmer2]        TG:         54 (^[[35m           MSP 2500 DSP^[[0m)     Freq: 851.375000 MHz    Update! 851.375000 MHz  Elapsed: 5s     Since update: 0s
[2020-11-02 07:52:28.323286]: [scarmer2]        TG:         54 (^[[35m           MSP 2500 DSP^[[0m)     Freq: 851.375000 MHz    Update! 851.375000 MHz  Elapsed: 5s     Since update: 0s
[2020-11-02 07:52:28.323526]: [scarmer2]        TG:         54 (^[[35m           MSP 2500 DSP^[[0m)     Freq: 851.375000 MHz    Update! 851.375000 MHz  Elapsed: 5s     Since update: 0s
[2020-11-02 07:52:28.515490]: [scarmer2]        TG:         54 (^[[35m           MSP 2500 DSP^[[0m)     Freq: 851.375000 MHz    Update! 851.375000 MHz  Elapsed: 5s     Since update: 0s
[2020-11-02 07:52:28.826423]:  [0]-[  : Pos - 10080 offset: 0 :
[2020-11-02 07:52:28.826520]:  [1]-[  : Pos - 10080 offset: 0 :
[2020-11-02 07:52:28.826569]:  [2]-[  : Pos - 10080 offset: 0 :
[2020-11-02 07:52:28.826980]:  Skipping to next file, Call Src:  100526

Attached the files for this call from my standard/prod and the new system: files-to-compare.zip

[robotastic]

Interesting! yes - since the file writing is now driven by the WAV Sink, samples have to come through for a new file to be created. It is also possible that the file was less than 1 Sec and automatically deleted. I have been doing some work on adding a flag to the config file. I can upload the change in a little. I was also looking at a different approach, where a new Call is created everytime the Call Source changes. I think the timing may line up so that everything is always written to the WAV file before a new speaker starts. I am not sure though...

[natecarlson]

I'll have to review the audio now that it's been running for awhile, but seems like the splitting with this solution is accurate. Downside is that it does require changes to the uploader and (depending on how it's done) the server side. New call would have the benefit of being 100% compatible with existing software.. but wouldn't be able to pass along conversation info.

I'll review more audio tomorrow; if you push more code you want tested just holler!

[natecarlson]

With the current analog_squelch branch, which is splitting via the wav sink, plus my patch to add the current timestamp to the filename of the wav file. Note that I understand that there haven't been any changes made to get the json file working as expected - just adding my notes on the current behavior here. :)

• Listening through a bunch of calls, it seems like the splitting is working quite well. Haven't found transmissions where either the beginning or the end is clipped or overran from a different transmission.
• JSON notes.. ** Overall start_time and stop_time appear to be correct (for the scope of the overall call obviously.) ** In the srcList, the 'pos' field gets reset with each file, as it is read from the duration of the wav_sink.. it is actually just reflecting the length of the previous transmission only. ** The timestamps between the filenames and recorded as 'time' in the srclist sometimes differ a little bit; looks like the timestamp recorded for the source occasionally gets updated before the time(NULL) I added for the filename. So it looks like there could be slight offsets in the calls there. ** The frequency table appears to be busted in the json - again, no surprise.

Here's json for one long conversation with the filenames manually added to each srclist..

{
  "freq": 852938000,
  "start_time": 1604380867,
  "stop_time": 1604380909,
  "emergency": 0,
  "talkgroup": 4826,
  "srcList": [
    {
      "src": 140988,
      "time": 1604380867,
      "filename": "4826-1604380867-1604380867-140988_851375000.wav",
      "pos": 0,
      "emergency": 0,
      "signal_system": "p25",
      "tag": ""
    },
    {
      "src": 139421,
      "time": 1604380873,
      "filename": "4826-1604380867-1604380873-139421_851375000.wav",
      "pos": 4.14,
      "emergency": 0,
      "signal_system": "p25",
      "tag": ""
    },
    {
      "src": 140988,
      "time": 1604380876,
      "filename": "4826-1604380867-1604380876-140988_851375000.wav",
      "pos": 1.98,
      "emergency": 0,
      "signal_system": "p25",
      "tag": ""
    },
    {
      "src": 139421,
      "time": 1604380883,
      "filename": "4826-1604380867-1604380884-139421_851375000.wav",
      "pos": 5.76,
      "emergency": 0,
      "signal_system": "p25",
      "tag": ""
    },
    {
      "src": 140988,
      "time": 1604380885,
      "filename": "4826-1604380867-1604380886-140988_851375000.wav",
      "pos": 1.44,
      "emergency": 0,
      "signal_system": "p25",
      "tag": ""
    },
    {
      "src": 139422,
      "time": 1604380889,
      "filename": "4826-1604380867-1604380889-139422_852937500.wav",
      "pos": 1.44,
      "emergency": 0,
      "signal_system": "p25",
      "tag": ""
    },
    {
      "src": 140988,
      "time": 1604380892,
      "filename": "4826-1604380867-1604380892-140988_852937500.wav",
      "pos": 2.34,
      "emergency": 0,
      "signal_system": "p25",
      "tag": ""
    },
    {
      "src": 139422,
      "time": 1604380895,
      "filename": "4826-1604380867-1604380896-139422_852937500.wav",
      "pos": 1.44,
      "emergency": 0,
      "signal_system": "p25",
      "tag": ""
    },
    {
      "src": 140988,
      "time": 1604380902,
      "filename": "4826-1604380867-1604380903-140988_852937500.wav",
      "pos": 6.48,
      "emergency": 0,
      "signal_system": "p25",
      "tag": ""
    }
  ],
  "freqList": [
    {
      "freq": 851375000,
      "time": 1604380867,
      "pos": 0,
      "len": 0,
      "error_count": 0,
      "spike_count": 0
    },
    {
      "freq": 852937500,
      "time": 1604380889,
      "pos": 1.44,
      "len": 99200,
      "error_count": 135,
      "spike_count": 9
    }
  ]
}

[natecarlson]

Pushed some changes I've made here: https://github.com/natecarlson/trunk-recorder/tree/split_recordings_nate

I'm pulling the call time from the source now, which makes it consistent.. and adding the frequency to the source info that gets written in the json - this would theoretically give an upload script enough info to construct the filename for that individual transmission.

[robotastic]

Awesome testing @natecarlson !! I haven't rolled in your changes yet. Can you give the current branch a test first? I added a flag for the config.json file called, transmissionMode that can be set true or false and it is defined for each system. If transmissionMode is true, it will listen to the voice channel for the end of transmission, if transmissionMode is false, it will listen for a change in Source on the trunk channel and start a new recording.

If you can give both modes a try, that would be awesome. I think the Call approach would be easier since the changes would be smaller.