robotastic
trunk-recorder works fine, but refuses to record one specific talkgroup?
this one is really confusing me. I've had trunk-recorder up for quite some time and it works great. however, I just noticed that for some reason, it just refuses to record one specific talkgroup. In my case it's talkgroup 28 (ME TAC 8) on Minnesota ARMER, hex 01c.
No, it's not encrypted. Yes, there is traffic there. Listening to it using sdr-trunk from a different machine, I hear calls on it. same dongles, same hardware. the talkgroup is set to priority 1 in my csv file. from what I can tell, it has NEVER recorded a single file from TG 28. It'll record ME TAC 7 (talkgroup 26) just fine.
So very confused, could this be a bug in trunk-recorder? Anything I should look at tweaking?
Can you double check you are on the latest version? I just fixed a different bug that might be related. If there were multiple systems, all of the talk group files were being mixed together so one talk groups priority could be over written by a different system.
On Dec 17, 2022, at 12:45 AM, bnelson333 @.***> wrote:
this one is really confusing me. I've had trunk-recorder up for quite some time and it works great. however, I just noticed that for some reason, it just refuses to record one specific talkgroup. In my case it's talkgroup 28 (ME TAC 8) on Minnesota ARMER, hex 01c.
No, it's not encrypted. Yes, there is traffic there. Listening to it using sdr-trunk from a different machine, I hear calls on it. same dongles, same hardware. the talkgroup is set to priority 1 in my csv file. from what I can tell, it has NEVER recorded a single file from TG 28. It'll record ME TAC 7 (talkgroup 26) just fine.
So very confused, could this be a bug in trunk-recorder? Anything I should look at tweaking?
— Reply to this email directly, view it on GitHub https://github.com/robotastic/trunk-recorder/issues/747, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA3TXBWXDM75LFX7ZHENL3WNVHOVANCNFSM6AAAAAATBYOON4. You are receiving this because you are subscribed to this thread.
That's almost certainly it. I'm gonna try putting the latest version on a different server to see if it works, and if so, I'll upgrade the existing. It's probably been a while, oops. Thanks for the quick reply!
Reread your note, I don't have multiple systems, so not sure if that's going to fix it. I upgraded to the latest trunk-recorder on that server and turned on logging. I'll have to check later to see if it captured/ignored that TG and then I'll dig into the logs to see if I can see a reason why.
bummer - that would have been too easy. Would it be possible to try recording for a bit without using any talkgroup.csv file? That will get rid of any issues around priority.
sure thing! I have it running on two machines now, both on the latest trunk-recorder. One I have running my talkgroups.csv file and one I have running wide open. Both have logging turned on. The talkgroup I'm aiming for doesn't seem to be active this morning, but it was last night, so maybe it's a channel split by time of day sorta thing. I'll check tonight and see if it shows up in either of my machines
What ARMER site are you monitoring? I've recorded calls on ME TAC 8 with trunk-recorder within the last 15 minutes.
ta-da, I got it now! looks like it was just the need to upgrade. Sorry about that, much ado about nothing!
Another thing to keep in mind is that if the talkgroup you're interested in is patched with another talkgroup, it may show as the "other" talkgroup in trunk-recorder's output. Patching information is available in the JSON metadata files for each audio recording.
Newer versions of trunk-recorder will monitor the patches that are active on the system and record the "other" talkgroup if it's patched to the one you care about even if you're not normally recording the "other" talkgroup, but older versions would not. But in either case, only one audio file is recorded using the TGID of whichever talkgroup is designated as the "super group" in the patch.
You'll see evidence of patching in the trunk-recorder output if you turn the log level to "debug".
bummer - that would have been too easy. Would it be possible to try recording for a bit without using any talkgroup.csv file? That will get rid of any issues around priority.
While my issue is resolved, this has me wondering: do I even NEED a .csv file?
I set up a second server running without a .csv file to catch everything. Just for fun, I compared it to the calls my first server recorded (the one that does have a .csv). I found no evidence of "dropped calls". Is that expected or did I just get lucky in my test?
E.g. let's say my server has a .csv file that tells it to record 30 talkgroups and ignore everything else. But let's say my tower normally has upwards of 100 talkgroups passing through it. If I remove the .csv file from the server and tell it just to record everything, do I run the risk of missing stuff I had previously cared about? E.g. a call comes in that is in one of those initial 30 I cared about, but now there's 70 more it has to keep track of, might it drop that call (in the 30) because it doesn't know the difference and chooses to do one of the 70 instead? Or is the system just that smart that it can do it all?
Like I said, I compared them and I couldn't find evidence of even a single dropped call. If I did run into a situation like that, would the log tell me that "hey I didn't record this one because all of your tuners were being used"? If the log tells me that, then I can just run it wide open and look for that error if I know what I'm looking for.
But as I'm tying this, I'm wondering instead if I shouldn't just: make my 30 talkgroups priority 1, and the other 70 priority 2. Then I'll always get the ones I care about and a whole lot of the ones I might just casually be interested in?
It depends on how many recorders you have set up in your configuration. If you have enough recorders (and processing horsepower) to enable capture of the entire system and you want to capture the entire system, then the Priority field in the CSV file isn't really needed, but you still may want the CSV for talkgroup names.
If it's a large/busy system, you may not want to capture everything, in which case the CSV prioritization can be used.
Or, if you only have a few recorders set up in trunk-recorder (less total recorders than number of frequencies on the system, usually with an extra recorder or two for buffer as calls overlap), prioritization will help make sure those recorders are used for the talkgroups you care about.
If I did run into a situation like that, would the log tell me that "hey I didn't record this one because all of your tuners were being used"? If the log tells me that, then I can just run it wide open and look for that error if I know what I'm looking for.
Yup. If the system starts running out of free recorders, you'll see things like this in the logs:
Not recording talkgroup. Priority is 1 but only 0 recorders are available.
or
Not recording talkgroup. Priority is 3 but only 2 recorders are available.
The priority system isn't strictly a "first, second, third" kind of thing. It works on the principle of: "you need [priority] free recorders before recording this talkgroup." Everything is a priority 1 by default. A -1 or any number greater than the amount of recorders you have effectively blocks a talkgroup from being recorded.
Unless a system is super-busy, or you have a low number of recorders, it's often possible to just record everything. But even when you have the resources, priorities are very useful in identifying busy talkgroups you might not care about at all (garbage trucks, busses, snow plows, etc...) and setting trunk-recorder to ignore them.
