Issue when monitoring multiple DMR Systems

[kazzaw]

sdrtrunk Version
Has occured for a while, currently using 0.6.0b2

Describe the bug
I have been having an issue with SDRTrunk getting confused when recording calls and outputting to Trunking Recorder - I have tested with Jason of Trunking Recorder and can see that there is no issue on his side, so I am trying to look for issues with my programming within SDRTrunk now.

Basically, I have SDRTrunk monitoring 2 different DMR systems, both in different frequency bands. System A is in 460Mhz and System B is in 500Mhz. SDRTrunk is confusing the two systems, which is leading to incorrect categorizations in the recorded files.

5:53:07 PM 25/10/2022 10046000 Unknown 46123 5.5 DMR Group 57 System B 0 463.1625
5:52:46 PM 25/10/2022 10046000 [group name here] 46148 14.1 DMR Group 21 System A 0 463.1625

The filename created by SDRTrunk is “20221025_175306SystemB_57_TRAFFIC__TO_10046000_FROM_46123.mp3”, notice it’s a “SystemB” Site 57 call.

When Trunking Recorder decodes the file and reads the Call Comment Tag it gets “'Date:2022-10-25 17:53:06.829;System:SystemB;Site:57;Name:TRAFFIC;Decoder:DMR;Frequency:463162500;”

Trunking Recorder reads the System and Site parts of the Comment Tag and imports it into Trunking Recorder with this information.

For some reason SDRTrunk decoded this call and believes occurred on System B Site 57.

This may be an issue with my setup, as I only have specific TG's programmed in, and other in a general 'Unknown' to catch recordings I don't currently have TG names for.

It's worth noting that SDRTrunk will output this information without any issue if only one DMR system is being monitored.

To Reproduce
Steps to reproduce the behavior:
Monitor two or more DMR TIII systems, both with recording enabled. SDRTrunk should get the groups and systems confused.

Expected behavior
SDRTrunk should be able to tell which system the call has come from and label the recordings correctly - Calls recorded from System A, regardless of the TGID Identifier should be recorded under System A, and likewise for System B

Screenshots
Can add on request

Application Log
Log from Trunking Recorder -
`2022-10-25 17:53:06,866 [32] DEBUG Trunking_Recorder.CallImport - Importing call 'C:\Users\Server\SDRTrunk\recordings\20221025_175306SystemB_57_TRAFFIC__TO_10046000_FROM_46123.mp3'

2022-10-25 17:53:06,869 [32] DEBUG Trunking_Recorder.CallImport - Call Duration: '5.5'

2022-10-25 17:53:06,869 [32] DEBUG Trunking_Recorder.CallImport - Call Raw Target Title: '10046000"Unknown"'

2022-10-25 17:53:06,869 [32] DEBUG Trunking_Recorder.CallImport - Group Target ID: '10046000'

2022-10-25 17:53:06,869 [32] DEBUG Trunking_Recorder.CallImport - Group Target Label: 'Unknown'

2022-10-25 17:53:06,869 [32] DEBUG Trunking_Recorder.CallImport - Call Raw Source Title: '46123'

2022-10-25 17:53:06,869 [32] DEBUG Trunking_Recorder.CallImport - Source ID: '46123'

2022-10-25 17:53:06,869 [32] DEBUG Trunking_Recorder.CallImport - Call Comment tag: 'Date:2022-10-25 17:53:06.829;System:SystemB;Site:57;Name:TRAFFIC;Decoder:DMR;Frequency:463162500;'

2022-10-25 17:53:06,869 [32] DEBUG Trunking_Recorder.CallImport - Call Start Time: '10/25/2022 07:53:06'

2022-10-25 17:53:06,869 [32] DEBUG Trunking_Recorder.CallImport - System ID: 'SystemB', no label

2022-10-25 17:53:06,869 [32] DEBUG Trunking_Recorder.CallImport - Site ID: '57', no label

2022-10-25 17:53:06,869 [32] DEBUG Trunking_Recorder.CallImport - Voice Service: 'DMR'

2022-10-25 17:53:06,869 [32] DEBUG Trunking_Recorder.CallImport - Frequency: '463.16250MHz'`

Both of these should be System A Calls

Additional context
Appreciate the logs are old, however I have just started monitoring both systems again and the issues have been re-identified. Happy to share further info if required

[DSheirer]

@kazzaw What type of DMR system(s) are you monitoring? Are they conventional, cap+, con+, Tier III, or something else?

[DSheirer]

On code inspection is looks like there's a potential for multiple channel start processing requests to be serviced concurrently, possibly resulting in misconfiguration of traffic channels to where the parent channel configuration that is used to identify the system/site values is incorrectly assigned to another traffic channel, causing the metadata to be incorrect on the traffic channel and any audio files generated from that traffic channel. Updating the channel processing manager to use a synchronized method to ensure that channel start requests are processed sequentially.

[kazzaw]

Tier III systems are all I have access to that I am able to test on.

I’m happy to provide more logs and attach my config if you’d like more, just. Let me know

[DSheirer]

@kazzaw I'm patching the code and that will close this issue. I'll produce a new beta release shortly. If the issue is still not resolved with the beta release, please let me know and we can re-open this issue and I'll dig into it some more.

[kazzaw]

Still appears to be happening on the systems I monitor unfortunately, although maybe a little less?

If you look at 9:06:53 you will see that the call was assigned to the Orion network, but originated on the Philcomm network. 9:07:07 is correct and what the earlier call should be.

TGID 10140026 also appears to belong to the Philcomm network.

That screenshot is from Trunking Recorder, however if I look at the logs in SDRTrunk at the same time, these groups don't show up in the incorrect places.

This is event list from the Philcomm network at that time

This is the event list from Orion network at that time

Tested on both 0.6.0 b5 and latest nightly build