P25 P1 Patched talk groups missing in Now Playing

[tadscottsmith]

sdrtrunk Version
Nightly 5/4/2024.

Describe the bug
P25 P1
Now playing tab is not correctly showing patched talk groups. Patched talk group information also appears to be missing from Recordings metadata and streaming. The Events tab does seem to recognize and correctly display the patched calls.

To Reproduce
Run latest nightly build on a P25 P1 system with active patch groups.

Expected behavior
Patch groups should display correctly and be passed to recordings/streamings.

Screenshots
As shown, the call from 312995 to 11518 does not show patched talk groups. The events tab correctly shows the patched talk groups.

[tadscottsmith]

Here is a baseband recording with a couple of examples.

As you can see there's an extended patch call with a patch of 11518 and 11520. 11520 is never shown in the Now Playing section and the patched information does not get sent to the streaming or recording modules.

https://drive.google.com/file/d/1XU0YkqGX79VV_YIW6aDYognk_IBb0xZJ/view?usp=sharing

[DSheirer]

Thanks for the recording. I'm investigating.

[DSheirer]

It looks like call events are never closing out. So, while the traffic channel manager thinks the call is still active, it will refuse to allow a new channel to be allocated. You can see this in the call events table in the duration column where the original call event will just keep getting a longer and longer duration, but the channel never gets allocated.

[tadscottsmith]

That is interesting! I went back to v0.6.1-beta-1 with the same WAV recording and noticed that the behavior is the same where all three calls are combined into one call event. This is actually 3 calls back to back on the same channel.

It still appears to be recording the calls correctly, but the latest nightly versions do not contain the patch information.

v0.6.1-beta-1 Recordings:

Nightly Recordings:

The actual call grants:

20240820 130740,PASSED,NAC:1037 TSBK2 PTCH GRP VCHN GR PATCH GROUP:P:11518 FROM:312994 SERVICE OPTIONS:PRI0 CIRCUIT
20240820 130740,PASSED,NAC:1037 TSBK2 PTCH GRP VCHN GR PATCH GROUP:P:11518 FROM:312994 SERVICE OPTIONS:PRI0 CIRCUIT
20240820 130749,PASSED,NAC:1037 TSBK1 PTCH GRP VCHN GR PATCH GROUP:P:11518 FROM:314796 SERVICE OPTIONS:PRI0 CIRCUIT
20240820 130749,PASSED,NAC:1037 TSBK1 PTCH GRP VCHN GR PATCH GROUP:P:11518 FROM:314796 SERVICE OPTIONS:PRI0 CIRCUIT
20240820 130752,PASSED,NAC:1037 TSBK2 PTCH GRP VCHN GR PATCH GROUP:P:11518 FROM:312994 SERVICE OPTIONS:PRI0 CIRCUIT
20240820 130752,PASSED,NAC:1037 TSBK2 PTCH GRP VCHN GR PATCH GROUP:P:11518 FROM:312994 SERVICE OPTIONS:PRI0 CIRCUIT

[DSheirer]

I finally had more than 15 minutes to focus on this issue this morning. Your recording has 1 traffic channel that never shuts down and that was causing one of the event durations to continue to climb. The other events with climbing durations were for failed channel allocations where the traffic channel frequency was outside of the range of the baseband recording. The stale events from the previous failed allocation were not being cleared out of the channel event map and instead it was continuing to aggregate each call's duration to the same single event. I'll fix this first and then focus back on this original issue.

[DSheirer]

I think I figured out what was causing this and have corrected it:

[tadscottsmith]

Thank you very much! Let me know if there's any way I can buy you a coffee for your efforts!