Duplicate Recordings on Smartnet Analog
Opened this issue · 1 comments
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"
}]
}]
}
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.
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.