Duplicate Recordings on Smartnet Analog

[decoy4fun]

When the system I am listening to gets busy, I end up with a lot of what sounds like duplicate calls in my recordings. What's actually happening though, is when a call ends on the trunked system I'm listening to, it's assigning another talkgroup to the same frequency within the 1 second I have set in my config. Trunk-recorder continues the existing call as though it's the original talkgroup, but also spins up another recorder for the new call so the same conversation gets recorded twice.

On September 1st at 13:35 we had a working structure fire. A responding ambulance got into a pretty hefty accident and there was so much traffic that there were calls recorded as many as 3-5 times under various unrelated talkgroups. Recordings are available under the "Cache" OpenMHz feed.

This issue is ultimately locking all of my recorders (which I've seen all recording the same frequency at once in the past) so I'm missing other calls.

To me, It doesn't seem like TR is recognizing the change in TG ID's so it's not stopping the original recording when a new one starts on the same frequency.

I am listening to this system via the Logan Peak site.

My original config;

{
    "ver": 2,
    "defaultMode": "analog",
    "callTimeout": "1",
    "logLevel": "info",
    "logFile": true,
    "uploadServer": "https://api.openmhz.com",
    "broadcastifyCallsServer": "https://api.broadcastify.com/call-upload",
    "captureDir": "/home/user/SDR/Recordings/",
    "sources": [{
            "center": 855862500,
            "rate": 2148000,
            "error": 1400,
            "gain": 40,
            "digitalRecorders": 1,
            "analogRecorders": 5,
            "driver": "osmosdr",
            "device": "rtl=001",
            "enabled": true
        },{
            "center": 858075000,
            "rate": 2148000,
            "error": 1400,
            "gain": 40,
            "digitalRecorders": 1,
            "analogRecorders": 5,
            "driver": "osmosdr",
            "device": "rtl=002",
            "enabled": true
        },{
            "center": 860600000,
            "rate": 2148000,
            "error": 1400,
            "gain": 40,
            "digitalRecorders": 1,
            "analogRecorders": 5,
            "driver": "osmosdr",
            "device": "rtl=003",
            "enabled": true
        },{   
            "center": 146940000,
            "rate": 3700000,
            "error": 1400,
            "gain": 55,
            "debugRecorders": 0,
            "digitalRecorders": 0,
            "driver": "osmosdr",
            "device": "rtl=004",
           "enabled": false
        }],
 "systems": [{
            "control_channels": [856762500, 858937500],
            "type": "smartnet",
            "talkgroupsFile": "aaUCA-ALL.csv",
            "shortName": "Cache",
            "modulation": "qpsk",
            "analogLevels": 4,
            "squelch": -45,
            "bandplan": "800_reband",
            "audioArchive": false,
            "transmissionArchive": false,
            "callLog": false,
            "compressWav": true,
            "recordUnknown": true,
            "conversationMode": false,
            "talkgroupDisplayFormat": "id_tag",
            "broadcastifyApiKey": "redacted",
            "broadcastifySystemId": "2859",
            "apiKey": "redacted",
            "enabled": true
        },{
            "type": "conventional",
            "channelFile": "aahamchannel.csv",
            "shortName": "CacheHamRadio",
            "callLog": false,
            "squelch": -25,
            "audioArchive": false,
            "analogLevels": 4,
            "compressWav": "true",
            "transmissionArchive": false,
            "enabled": false
        }],
    "plugins": [{
            "name": "rdioscanner_uploader",
            "library": "librdioscanner_uploader.so",
            "server": "redacted",
            "enabled": true,
            "systems": [{
                    "shortName": "Cache",
                    "apiKey": "redacted",
                    "systemId": "redacted"
                }]
        }]
}

[decoy4fun]

To aid in troubleshooting we've already done in discord, this comment from tadscottsmith states:

There could be a flaw in the logic somewhere as well. On first glance it looks like the P25 since_last_write() logic might have been updated, where the analog recorder hasn't.

https://github.com/robotastic/trunk-recorder/blob/01f3f624ba68e41f3a5cef540a283851bd6f52be/trunk-recorder/recorders/p25_recorder_decode.cc#L64-L68C1

https://github.com/robotastic/trunk-recorder/blob/01f3f624ba68e41f3a5cef540a283851bd6f52be/trunk-recorder/recorders/analog_recorder.cc#L264-L267C2

Per this comment, it's possible a similar issue was fixed for p25 systems but the solution may not have been copied for analog systems.

[robotastic]

Is this still an issue? I don't remember if this was something that may have been ficxed with v5.0

[decoy4fun]

It was still an issue after releasing v5.0 but the smartnet analog system I was monitoring has been shut down and is now p25 phase II so I'm unable to verify/test anything anymore.

[Cole0209]

FYI this does still occur regularly for smartnet. As far as I could figure out it seems to happen only when the system is reusing frequencies right after another TG finishes with it. Watching the spectrum on another SDR it looks like the repeater for that frequency isn't dropping so the squelch never closes. The next transmission on a different TG will be recorded in full and this will continue until the system lets that repeater drop. Not sure how the smartnet recording works for t-r but something to force end the call even if it doesn't drop below the squelch threshold when another call is started on the same frequency might be a fix?

[xmleger]

I'm also having this problem on a large smartnet system in Mass (MSP Smartnet.) I've been able to mitigate it a little by setting the calltimeout to "1" but when the system gets busy it still can really eat up resources even with the smaller overlaps.

[xmleger]

If someone is working on this and can tell me how to capture data from the system near me for testing, please le me know if I can capture that to help troubleshoot this issue.

I am wondering if this is at all related to the User ID's not updating on calls in the analog smartnet system too. If it is not "noticing" that the original transmitting unit has ended their transmission and it has been picked up by another. Only the initiating source ID is showing up in the generated JSON file too.