Zero length calls

[b1tninja]

So disclaimer: I've never gotten this working, so it could be entirely a configuration error on my part, but I notice call recording starts to happen in some cases the frequency is 0 or the call duration is 0, which results in the wav file being deleted.

I've tried the latest tagged release, and the current master, the logs are from the master build

[2020-10-07 11:36:37.002952] (info) [SRRCS] TG: 2821 Freq: 8.524625e+08 Ending Recorded Call - Last Update: 4s Call Elapsed: 13 [2020-10-07 11:36:37.003047] (info) - Stopping P25 Recorder Num [1] TG: 2821 Freq: 8.524625e+08 TDMA: false Slot: 0 [2020-10-07 11:36:37.003106] (error) wav error closing file [2020-10-07 11:36:37.003115] (info) [SRRCS] Deleting this call as it has a duration less than minimum duration of 0 TG: 2821 Freq: 8.524625e+08 Call Duration: 0s [2020-10-07 11:36:37.003136] (error) Could not delete file /tmp/trunk-recorder/build/SRRCS/2020/10/7/2821-1602095784_852462500.wav

[2020-10-07 11:36:13.688126] (info) [SRRCS] Started with Control Channel: 8.538765e+08 Decim: 80 Decim2: 4 [2020-10-07 11:36:13.688462] (info) P25 Trunking two-stage decimator - Initial decimated rate: 100000 Second decimated rate: 25000 FA: 6250 FB: 12500 System Rate: 8000000 [2020-10-07 11:36:13.694380] (info) P25 Trunking ARB - Initial Rate: 8000000 Resampled Rate: 25000 Initial Decimation: 80 System Rate: 24000 ARB Rate: 0.96 [2020-10-07 11:36:13.845336] (info) [SRRCS] TG: 3769 Freq: 0.000000e+00 Not Recording: no source covering Freq [2020-10-07 11:36:13.945987] (info) [SRRCS] TG: 3851 Freq: 0.000000e+00 Not Recording: no source covering Freq

config.json.txt

recorder.log

Thanks for all your work on this amazing project

[UberPlexCa]

I had this same issue happen if you do not have your analog talk groups in or listed as analog in the talkgroup file. Once I put them in my issues went away. But the other issue now is static for 3-10 seconds at the end of every analog transmission.

Ubuntu 20.04 and TR3.3

[rosecitytransit]

But the other issue now is static for 3-10 seconds at the end of every analog transmission.

If you haven't addressed the issue (and for others), you'll want to adjust the squelch setting in the config.json file. The issue is that there's no way to tell when a transmission has ended, so the program looks for a lack of updates on the control channel and waits until some seconds after the last one. You can also adjust callTimeout to shorten how long the program waits until deciding the call must have ended.

[NathanHowell]

@b1tninja I ran into possibly the same issue Deleting this call as it has a duration less than minimum duration of 0... I ran opensnoop-bpfcc and it was never even opening a file to write the wav to (note: strace slows down trunk-recorder so much that it loses packets, opensnoop and bpftrace do not). json metadata gets created but that's it. I reverted to v3.1.4 and files are being created properly.

Someone on gitter thought it might have started around 5465f9a65821b0e3833a2dde17f91c5855fe0798 but I haven't tried bisecting, arm64 builds take a long time.

If you happen to be using a 64-bit Raspberry Pi 4 you could try this docker image: https://hub.docker.com/layers/nathanhowell/trunk-recorder-rpi4/v3.1.4/images/sha256-512a2aaf6e91c56d88d65f384231dc5de2e8c70e696a68ebf2e320579d511af2?context=repo reference docker-compose.yaml: https://github.com/NathanHowell/trunk-recorder-pi4/blob/master/docker-compose.yml

[bctrainers]

@NathanHowell that error generally is the result of frequency drift or someone clicking on their radio but immediately unlatching the talk button.

[NathanHowell]

@bctrainers on master it never ever records anything (it doesn't even open a file that would later be deleted), reverting to v3.1.4 everything works as intended. maybe it's a problem with my config but it sure seems like a bug.

[toddejohnson]

I also had @NathanHowell's problem with a working setup after upgrade to edge docker. Removing docker and downgrading to 3.1.4 it is working again. I use archlinuxarm so I made a PKGBUILD: https://aur.archlinux.org/packages/trunk-recorder

[dkettmann]

System: Ubuntu 18.04.5 LTS System built: Jan 2019 Original Recorder prog built: Jul 2020 RTL-SDR v2 (two of them)

Has run well for over a year. Has a massive TPlayer database so it struggles but has been solid. Last night under a ton of load due to user activity started getting OOOOOOOOO in my recorder console. Did Ubuntu updates, rebooted still same problem with CPU pegged. Did poweroff, opened it up on the bench and blew out 2 years of cat hair etc.

Reconnected, started back up and no longer CPU bound but now getting nothing but zero length errors. https://pastebin.com/bcWk3SYZ

Renamed my trunk-build to trunk-buildold, emptied trunk-recorder folder, pulled down latest master. Built new style config.json and now latest code running on same system but still getting same zero length error. My control channel decodes at 120 of 120. https://pastebin.com/pWVDxTJK

Did the same with pulling down the v3.1.4 code and same problem.

Any ideas I can try before I have to bury it at sea? Any way to completely wipe the Trunk Recorder stuff without affecting TPlayer? I'm over my head and about to give up but wanted to give this info as a hail mary or maybe it helps?

[kb2ear]

System: Ubuntu 18.04.5 LTS System built: Jan 2019 Original Recorder prog built: Jul 2020 RTL-SDR v2 (two of them)

Has run well for over a year. Has a massive TPlayer database so it struggles but has been solid. Last night under a ton of load due to user activity started getting OOOOOOOOO in my recorder console. Did Ubuntu updates, rebooted still same problem with CPU pegged. Did poweroff, opened it up on the bench and blew out 2 years of cat hair etc.

Reconnected, started back up and no longer CPU bound but now getting nothing but zero length errors. https://pastebin.com/bcWk3SYZ

Renamed my trunk-build to trunk-buildold, emptied trunk-recorder folder, pulled down latest master. Built new style config.json and now latest code running on same system but still getting same zero length error. My control channel decodes at 120 of 120. https://pastebin.com/pWVDxTJK

Did the same with pulling down the v3.1.4 code and same problem.

Any ideas I can try before I have to bury it at sea? Any way to completely wipe the Trunk Recorder stuff without affecting TPlayer? I'm over my head and about to give up but wanted to give this info as a hail mary or maybe it helps?

Did you tune you SDRs at some point? I see very high PPM error set on them.

[robotastic]

It looks like both of the RTLs are set to a gain of 300!

[2021-07-21 16:11:38.146472] (info)   PPM Error: -1.7
[2021-07-21 16:11:38.146483] (info)   Auto gain control: false
[2021-07-21 16:11:38.146491] (info)   Gain: 300

That maxs out the gain. I would try something lower, maybe 32 to get started. I have also noticed that RTLs can sometimes burn out over time. Do you have any backups you could try swapping in? The error correction also seems pretty high. It is generally pretty close to zero.

[dkettmann]

It looks like both of the RTLs are set to a gain of 300!

I will try as you suggest. I did note when I started recorder it would complain about that and then just select the highest available from the SDR. I had played around with 42.1 but will try lower. I can picture that blowing the signal out.

I do have backup SDRs. I do wonder if these took a hit. The wire on the antenna feed (into the powered splitter) came completely out of the connector and I had to electrical tape it back where the shrink tubing had failed. Perhaps it shorted out before I caught that. I will try different ones.

I am a bit surprised about the comments on my ppm being high. Historically this is in the ballpark (if not exactly) what I've used for years. It is a simulcast system that I am on the edge of with a yagi aimed at a tower. If that matters?

Thanks for the ideas, they're good ones. It really seemed to fit in to this potential bug -- as in my mind the only things that changed were some less-than-graceful shutdowns under load and the tear down and re-setup of the computer. Until I renamed trunk-build and did that stuff nothing software had changed at all. I really had envisioned some type of file that got hung in a bad state, but it would be my luck that it is something along the lines of being mentioned. I'll tame the gain and swap sticks and see if any help. Also I will try moving my ppm closer to zero. I did move it further away from zero and started getting worse CC decode but I didn't go the other direction.

[dkettmann]

She breathes again! ---> https://pastebin.com/YzBcCEss

Okay so I did some things and one of the below has it recording now, so I know it isn't any type of bug and is just tuning related:

• Took gain down to 29.7
• Ran as sudo (which I had forgotten this box needs for file permissions but I had recently tried this before with no love)
• Swapped out both SDRs
• Adjusted ppm to -1, any closer to zero and I lose the CC.
• Realized that before I had 1 stick doing the CC and another doing voice freqs. So CC decode had nothing to do with voice decode. I simplified down to one SDR (missing the lower 2 or 3 voice bands) and that helps for now. Now going to work on adding 2nd SDR to cover the difference but I have a good base and know it can work if I get it right.

Thank you everyone for talking me off the ledge.