-
Notifications
You must be signed in to change notification settings - Fork 252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue when monitoring multiple DMR Systems #1681
Comments
@kazzaw What type of DMR system(s) are you monitoring? Are they conventional, cap+, con+, Tier III, or something else? |
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. |
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 |
… site labels in metadata. Adds synchronized to channel processing manager's start channel request method to ensure that each channel is configured and started sequentially to avoid chance that simultaneous traffic channel grants occurring across two separate systems get inter-mingled on configuration and startup.
@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. |
…t-system-and-site #1681 Audio Recorder Mixing Up System and Site When Decoding Multiple Systems
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
The text was updated successfully, but these errors were encountered: