talkgroup_tag is only read once?

[ZeroChaos-]

I finally got a chance to upgrade to 6.1(.2) and test the talkgroup_tag feature. It seems that no matter what, the tag is only read once per talkgroup and that information is cached. I'm not sure if I'm using it wrong, but let me describe my setup.

I am monitoring a ton of analog stuff. Each one is it's own entry in my trunk-recorder config, and as such, every analog frequency is tagged as "talkgroup: 1". I distinguish them based on the frequency (which does update on the rdio-scanner display) and the talkgroup_tag. While the first transmission reads the talkgroup tag correctly, every transmission after that only updates the frequency on the display and keeps the tag from the first frequency.

Can you please update the talkgroup_tag feature to work like the frequency display so it updates every time? I tried with "auto-populate" turns on and turned off. I also tried deleting all the talkgroup mappings. Unfortunately none of those config changes appear to make a difference. My main goal is to not have to maintain two separate mappings of the same information, so having trunk-recorder pass useful information which rdio-scanner reads and displays is what I'm aiming for.

[chuot]

The talkgroup_tag is used to create unknown talkgroups while autopopulate is enabled. If the talkgroup already exists in the configuration, then the talkgroup_tag will be ignored.

In my case, I'm using RTLSDR_Airband for analog transmissions. It much more CPU efficient and can be used with a dirwatch with masks. I can send you my config if you want to try?

[ZeroChaos-]

I'm not monitoring exclusively analog, nor am I using dirwatch (rdio-scanner is actually on a dedicated machine as of today with multiple TR systems feeding it).

What I'd like is for the talkgroup_tag to be respected as is, but I suppose I could adjust my upload script to make a new system for every frequency. It just seems like that's silly since the frequency is already read dynamically from the same file.

[VVakko]

I have a similar problem related to conventional (not trunked) signals. trunk-recorder, when reading the configuration file, assigns a tgid to each individual frequency (numbers in order). These tgids have nothing to do with reality. It is more convenient for me that in rdio each conventional frequency has a tgid equal to the frequency. Therefore, these wav files are uploaded to rdio-scanner with the command: curl ... /api/call-upload ... -F "frequency=${freq}" -F "talkgroup=${freq}" In general, this is a working option for analog recordings. For digital signals (P25), I tried using endpoint /api/trunk-recorder-call-upload, in order to upload to rdio-scanner a .json-file with the metadata of the calls. But when uploading a .json-file, the tgid is used, which is written in a .json-file, and this is not a real tgid, but just some ordinal number. Is it possible for endpoint /api/trunk-recorder-call-upload to add the ability to override the tgid by passing an additional parameter -F "talkgroup=${freq}" so that the parameter has priority over the tgid, which is written in a .json-file?

[chuot]

@ZeroChaos- How does your Trunk Recorder config file is done, do you use alphatags in the system definition, how to you use a talkgroupsfile? As @VVakko stated, each entry will be given a sequential TGID from which Rdio Scanner will attach the call to. Can you post an example of your Trunk Recorder config, I'm curious to see how you have defined your alpha tags.

@VVakko does the json file contains the freq property? Because I'm reading it when processing the json data. If it isn't there, then Trunk Recorder should be modified to include it. However, the rdioscanner-plugin for Trunk Recorder does send that info.

[VVakko]

@chuot here is example of .json-file:

{
"freq": 472137500,
"start_time": 1641739761,
"stop_time": 1641739774,
"emergency": 0,
"encrypted": 0,
"call_length": 9,
"talkgroup": 4,
"talkgroup_tag": "-",
"audio_type": "digital",
"short_name": "472-System",
"freqList": [
  {"freq": 472137500, "time": 1641739761, "pos": 0.0, "len": 9, "error_count": 0.0, "spike_count": 0.0}
],
"srcList": [
  {"src": 760807, "time": 1641739761, "pos": 0, "emergency": 0, "signal_system": "", "tag": ""},
  {"src": 760809, "time": 1641739765, "pos": 4, "emergency": 0, "signal_system": "", "tag": ""},
  {"src": 760809, "time": 1641739772, "pos": 6, "emergency": 0, "signal_system": "", "tag": ""}
]
}

As you can see, all the necessary meta-data is present here, including an srcList with callers and timestamps. The problem is that the talkgroup field contains a garbage for us. Ideally, the solution I see is adding the use_freq_as_tgid parameter in the configuration of system settings in trunk-recorder or in rdio-scanner. :)

[chuot]

Everything is built around systems and talkgroups, so talkgroup id cannot be considered as garbage on Rdio Scanner. You could adapt your upload script to change the talkgroup id based on the frequency, prior to sending it to Rdio Scanner. Some people are doing it that way.

[VVakko]

I understand that it is important for rdio-scanner to use the correct talkgroup ids and frequencies, that's why I'm asking you to add the ability to redefine fields in .json-file via variables passed via the -F key "talkgroup=${freq}" to the /api/trunk-recorder-call-upload method. Editing a .json-file directly using sed is an extreme option.

I'll also try to ask @robotastic https://github.com/robotastic/trunk-recorder/issues/603 to have the trunk-recorder modified. So this modification will allow to use the rdio-scanner plugin without any problems, without having to use self-written scripts and utilities.

[chuot]

I think having this fixed at the source, on the Trunk Recorder side, is better than tweaking Rdio Scanner. But I'll see what I can do in the mean time on the Rdio Scanner API side.

[ZeroChaos-]

Okay, to be totally clear, this whole thing is my fault. "system" has no meaning on conventional analog, or at least the "system" and "talkgroup" are the same thing. As such, my lazy self wrote the upload script like this

  curl http://192.168.1.242:3000/api/trunk-recorder-call-upload \
      -F "key=${rdio_key}" \
      -F "audio=@${m4aencoded}" \
      -F "meta=@${json}" \
      -F "system=1"

When I do this, which I know is wrong, rdio scanner updates the frequency for EVERY transmission. The talkgroup is also updated for every transmission, which is always 1 (conventional analog). What isn't read every time, despite being available, is the talkgroup tag. Ignoring the fact that the talk group tag changes seems like a bug to me, however, I fully accept that I'm using rdio_scanner wrong by feeding it system=1 for everything. As such, I've updated:

  curl http://192.168.1.242:3000/api/trunk-recorder-call-upload \
      -F "key=${rdio_key}" \
      -F "audio=@${m4aencoded}" \
      -F "meta=@${json}" \
      -F "system=${freq}"

Now it all works perfectly, other than I have to manually name the auto added systems.

I still feel that reading talkgroup tag only once is "wrong", but its easy enough to work around and probably more correct to do what I'm doing now, so I'll leave it to you as to if you want to close this or do something.

[chuot]

Here's what I will do:

• The /api/call-upload API will stay as it is and is the preferable API entry point.
• The /api/trunk-recorder-call-upload API, which is the legacy entrypoint, will first parse the JSON data, then reuse the code from the other API entry point, so every other fields will override what was read from the JSON file.

Starting from v6.1.3, if you use the legacy entrypoint with a json file that has a tgid set to 1 and you pass a talkgroup field set to, lets say 55, then the call will be imported to tgid 55. This is also true for all the other fields, frequency included.

[ZeroChaos-]

My apologies, is there an example for /api/call-upload which I can use? Happy to switch to the "preferable" end point

[chuot]

Note that the preferable api entry point is also used by the trunk-recorder plugin, but it doesn't support reading the json file.

See the docs/api.md document for more informations.

[ZeroChaos-]

reading the json file is super convenient though, so hopefully that end point isn't deprecated?

[chuot]

Not it won't, I know a lot of people rely on it with custom upload scripts. However, I prefer new stuff to use the new api entry point.

[VVakko]

I'm using this upload-call.sh file for uploading calls from conventional systems:

#!/bin/sh

# Rdio Scanner Server URL and Key for Uploading
url="http://server:3000"
key="11111111-2222-3333-4444-555555555555"

system="${1:-0}"
filename="${2%.*}"
site="${filename#*/}"
site="${site#*/}"
site="${site#*/}"
site="${site%%/*}"
temp="${filename%-call*}"
temp="${temp##*-}"
time="${temp%_*}"
date=$(date -ud @${time} +"%Y-%m-%dT%T.%3NZ")
freq="${temp#*_}"
tgid="${filename##*/}"
tgid="${tgid%-call*}"
tgid="${tgid%-*}"
tgid="${freq}"

#echo "File: ${filename}"
#echo "Syst: ${system}"
#echo "Site: ${site}"
#echo "Time: ${time}"
#echo "Date: ${date}"
#echo "Freq: ${freq}"
#echo "TGID: ${tgid}"

sed -e 's@"talkgroup":.*,@"talkgroup": '"${freq}"',@' -i ${filename}.json
curl --silent "${url}/api/trunk-recorder-call-upload" \
     -F "key=${key}" -F "system=${system}" \
     -F "audio=@${filename}.wav;type=audio/wav" \
     -F "meta=@${filename}.json;type=application/json" \

exit $?

curl --silent "${url}/api/call-upload" \
     -F "key=${key}" -F "system=${system}" \
     -F "audio=@${filename}.wav;type=audio/wav" \
     -F "dateTime=${date}" \
     -F "frequencies=[]" \
     -F "frequency=${freq}" \
     -F "talkgroup=${tgid}"

First curl is using for uploading .json-files and second one for uploading without .json. Yesterday I switched conventional systems to using /api/trunk-recorder-call-upload. I hope it will be useful to someone. :)

[chuot]

I guess we can close this one since we now have a #TGHZ metatag for dirwatch.