Thinline-Dynamic-Solutions/ThinLineRadio v26.05.004

Release 26.05.004

on GitHub

Version 26.05.004

Fixed

• Server — Tone detection, stacked pending tones, and orphan alerts (callId = 0)

  • First known report: First production incident of this failure mode we are aware of (investigated May 15, 2026 on system ref 78, talkgroup ref 46036 / 78 FD DISP). It is now fixed.
  • Root cause: Tone detection ran asynchronously on a copy of the call before WriteCall assigned a database callId. All downstream steps used callId = 0, so tone results never persisted on the real call rows and the 60-second orphan safety net could not load the call to create alerts.

• Example failure (May 15, 2026 — stacked tone page, no voice on dispatch)

  Multiple short clips on one channel within ~20 seconds; detection and pre-alerts worked, but no rows were written to the alerts table and hasTones stayed false on every call:

  Call time (ET)	callId	Detected / matched	Pre-alerts	DB alerts row
  05:03:29	39395685	Champion Duty (376 + 1055 Hz)	13 users	None
  05:03:34	39395698	Weathersfield 42	18 users	None
  05:03:40	39395709	Howland Duty	16 users	None
  05:03:45	39395718	Newton Falls Duty	13 users	None

• Fixes in this release

  • Run tone detection after WriteCall so logs, updateCallToneSequence, storePendingTones, and orphan timers use the real callId.
  • Orphan handler loads the call via pending.CallId when the timer argument is stale, writes the merged toneSequence to the database, then triggers alerts.
  • Stacked pending: Each merge into the active pending stack moves the anchor to the latest clip and resets the 60-second orphan timer; older timer goroutines exit when the anchor advances.
  • Expired-pending replace path schedules an orphan check.
  • Clearer logging for tone-only clips with matched tone sets (pending until voice or orphan).

See CHANGELOG.md for full details.