Wrong stop_time value in json

[smokedsalmonbagel]

Hi I have been using trunk-recorder for a few years. I have tied into my receiver network using the encode-upload.sh plugin. I am noticing that some transmissions end up with the wrong "stop_time". I only noticed because I happen to partition the data using the stop_time field on the server. This is causing a bunch of incorrect partitions on the server.

{
  "freq": 851587500,
  "freq_error": -1083,
  "signal": 999,
  "noise": 999,
  "source_num": 1,
  "recorder_num": 5,
  "tdma_slot": 0,
  "phase2_tdma": 0,
  "start_time": 1739713999,
  "stop_time": 139709125013824,
  "emergency": 0,
  "priority": 4,
  "mode": 0,
  "duplex": 0,
  "encrypted": 0,
  "call_length": 14,
  "talkgroup": 11,
  "talkgroup_tag": "WPD Disp 1",
  "talkgroup_description": "Dispatch 1",
  "talkgroup_group_tag": "Law Dispatch",
  "talkgroup_group": "Law Dispatch",
  "audio_type": "digital",
  "short_name": "Waterbury",
  "freqList": [
    {
      "freq": 851587500,
      "time": 1739713999,
      "pos": 0.0,
      "len": 14.22,
      "error_count": 28,
      "spike_count": 2
    }
  ],
  "srcList": [
    {
      "src": 1511633,
      "time": 1739713999,
      "pos": 0.0,
      "emergency": 0,
      "signal_system": "",
      "tag": ""
    }
  ]
}

A few notes:

• this is only a few transmissions.
• It is not tied to any specific frequency or TG that I can tell
• The wrong value is not always the same, but is always a very large number
• This has been happening since an upgrade I did back in January to the latest version of trunk-recorder
• I have verified this does not happen with start_time

Any idea how I can further debug this? At first I though this was some bug with my upload code but I am posting here because the timestamp seems to be wrong in the original json created by trunk-recorder.

[ZeroChaos-]

I have a strong suspicion this is related to #998

[tadscottsmith]

Does it ever happen when there are multiple transmissions or is it always a single transmission like that?

[smokedsalmonbagel]

I have something like 14 RTLs in the setup so I am not sure. I see one case where there is a a different source_num and recorder_num for two bad stop_times consecutively.
Anyway, here are two logs.
https://gist.github.com/smokedsalmonbagel/5168f87129dab998eb4d3794ec856f49
44273490901.txt is the file where all the bad stop_times went. It is actually a date, Sept. 9th year 4427349 from the converted stop_time :-) I actually have thousands of examples but only uploaded this small sample. The other file is an overlapping time period of good stop_time values. Hopefully this helps debugging the issue.

There was some business about the multicast / simulcast sites here in CT but the issue doesn't seem to be restricted to those channels.