Report decode health in the checkin so the portal can explain "online but not recording" #40

New Issue

2026-10-25T23:42:09-04:00

logan commented

2026-10-25 23:42:09 -04:00

Prompted 2026-10-25: node-002 (My Radio Node, MTA Zone 2) shows Online in the portal but has recorded nothing since ~Sep 30, and the portal can't say why. SDR assignment confirmed correct by the owner. The only remote action available was Restart OP25 (sent 2026-10-25 23:41).

Today the portal only learns online/recording status, SDR inventory and op25_sdr_serial. Everything that would explain "online but never records" lives only on the node's local dashboard (/api/status), which needs LAN access (and node-002's dashboard is still on default creds, #1):

control-channel lock: is OP25 decoding the trunking control channel at all, which CC frequency, last good TSBK time
frames/TSBKs decoded per minute, and NAC seen vs configured (see #33: a wrong NAC drops every frame while "Decoding" says OK)
unattributed_segments: audio heard but discarded because no talkgroup came within the attribution window (metadata_watcher / DEFERRED.md row: "if OP25 stops decoding the control channel while audio keeps flowing, every call is silently dropped")
last call recorded and last upload result (HTTP status), and offline-buffer depth

Fix shape:

Node: add these to the periodic checkin (mqtt_manager), cheap counters only.
Server (server-26 half): store on the node doc in mqtt_handler._handle_checkin; node page shows a "Decode health" block; flag "online, no CC lock" / "audio but 100% unattributed" / "no call in N hours" in amber.

Priority p1: a node that silently stops recording is invisible to its owner, and recording is the foundation everything downstream depends on.

Prompted 2026-10-25: node-002 (My Radio Node, MTA Zone 2) shows **Online** in the portal but has recorded nothing since ~Sep 30, and the portal can't say why. SDR assignment confirmed correct by the owner. The only remote action available was Restart OP25 (sent 2026-10-25 23:41). Today the portal only learns online/recording status, SDR inventory and op25_sdr_serial. Everything that would explain "online but never records" lives only on the node's local dashboard (/api/status), which needs LAN access (and node-002's dashboard is still on default creds, #1): - control-channel lock: is OP25 decoding the trunking control channel at all, which CC frequency, last good TSBK time - frames/TSBKs decoded per minute, and NAC seen vs configured (see #33: a wrong NAC drops every frame while "Decoding" says OK) - unattributed_segments: audio heard but discarded because no talkgroup came within the attribution window (metadata_watcher / DEFERRED.md row: "if OP25 stops decoding the control channel while audio keeps flowing, every call is silently dropped") - last call recorded and last upload result (HTTP status), and offline-buffer depth Fix shape: 1. Node: add these to the periodic checkin (mqtt_manager), cheap counters only. 2. Server (server-26 half): store on the node doc in mqtt_handler._handle_checkin; node page shows a "Decode health" block; flag "online, no CC lock" / "audio but 100% unattributed" / "no call in N hours" in amber. Priority p1: a node that silently stops recording is invisible to its owner, and recording is the foundation everything downstream depends on.

logan added the

type

feature

area/recording-audio area/sdr-radio area/frontend area/mqtt

priority

p1

labels 2026-10-25 23:42:09 -04:00

logan commented

2026-10-25 23:53:32 -04:00

Data point after Restart OP25 (23:41): node-002 produced a call doc at 23:45 (MTA PD Districts 6/7/11 Dispatch, 14s), so OP25 is decoding and call_start/call_end reach C2 over MQTT, but the call still has no audio 10+ minutes later. So the /upload leg is failing or the recording is discarded on the node (upload auth/API key, recorder/PulseAudio, or trim/attribution drop). Still nothing in the portal says which. That is exactly the last-upload-result / recorder field this issue asks for.

Data point after Restart OP25 (23:41): node-002 produced a call doc at 23:45 (MTA PD Districts 6/7/11 Dispatch, 14s), so OP25 is decoding and call_start/call_end reach C2 over MQTT, but the call still has **no audio** 10+ minutes later. So the /upload leg is failing or the recording is discarded on the node (upload auth/API key, recorder/PulseAudio, or trim/attribution drop). Still nothing in the portal says which. That is exactly the last-upload-result / recorder field this issue asks for.

logan referenced this issue

2026-10-26 00:59:47 -04:00

Updater never prunes Docker build cache: node-002 disk hit 100% and silently stopped recording for 17 days #41

logan referenced this issue

2026-10-27 20:03:48 -04:00

Replace OP25+PulseAudio recorder with Trunk Recorder feeding our uploader #45

logan referenced this issue from a commit

2026-11-01 06:39:28 -05:00

call_recorder: spool failed uploads to disk and retry instead of deleting (node-26#44)

Sign in to join this conversation.