diag(icom net): name the audio stream when CI-V goes quiet

The RX audio stream is experimental and shares the rig's session with
CI-V. The shape in an operator's log is unmistakable: audio packets
arriving by the hundred while not one CI-V reply comes back, the watchdog
tearing the session down, twenty seconds' pause, and the whole thing
again — read from outside as "the Icom keeps disconnecting", with
nothing pointing at the switch that would end it.

The log now says it, and names the setting. icomAudio counts what it has
delivered so the line distinguishes "audio is enabled" from "audio is
arriving", which is the half that makes it a suspect.

changelog.json

@@ -6,13 +6,15 @@
       "FT map: the callsign, square and report show on hover again. The invisible circle that catches the clicks sits on top of the dot, so it takes the hover too — and the label was bound only to the dot underneath, which left the map silent from the moment the stations became clickable.",
       "ADIF export: a record is written on one line again. ADDRESS is a multi-line field by the standard and callbooks and other loggers fill it that way — “Kabul”, four blank lines, “Afghanistan” — and OpsLog wrote it out as it was, so a record ran down a dozen lines with the next apparently starting in the middle of the page. Line breaks inside a value are now joined with a comma, which is how an address reads on one line anyway. The files were always valid (ADIF counts bytes); they were unreadable.",
       "Icom over the network: a rig left in standby no longer sits in a dial-and-drop loop. The clock that bounds “the control link answers but no CI-V comes back” belongs to a session and was never cleared when a new one opened, so every fresh session started already past its grace — torn down at once, redialled twenty seconds later, and torn down again for as long as the radio was asleep. Silent since connect is now read as what it is: a rig in standby, with the session kept so it can be woken.",
-      "The Icom console appears whenever the configured radio is an Icom, not only once the rig is talking — the console is where the power-ON button lives, so it used to be missing at the one moment it was needed. The console’s configured backend also follows a radio switched from the status bar, instead of waiting for a trip through Settings and a Save that changed nothing."
+      "The Icom console appears whenever the configured radio is an Icom, not only once the rig is talking — the console is where the power-ON button lives, so it used to be missing at the one moment it was needed. The console’s configured backend also follows a radio switched from the status bar, instead of waiting for a trip through Settings and a Save that changed nothing.",
+      "Icom over the network: when CI-V goes quiet while the experimental RX audio stream is still delivering, the log now says so and names the switch to try. The two share the rig’s session, and the shape in the field is exactly that — hundreds of audio packets arriving, not one CI-V reply, the watchdog tearing the session down, and the whole thing starting again."
     ],
     "fr": [
       "Carte FTx : l’indicatif, le locator et le report réapparaissent au survol. Le cercle invisible qui capte les clics est au-dessus du point, donc il capte aussi le survol — et l’étiquette n’était liée qu’au point du dessous, ce qui rendait la carte muette dès que les stations sont devenues cliquables.",
       "Export ADIF : un enregistrement tient de nouveau sur une ligne. ADDRESS est un champ multiligne selon la norme, et les callbooks comme les autres logiciels le remplissent ainsi — « Kabul », quatre lignes vides, « Afghanistan » — qu’OpsLog recopiait tel quel : un enregistrement s’étalait sur une douzaine de lignes, le suivant semblant commencer au milieu de la page. Les retours à la ligne dans une valeur sont désormais réunis par une virgule, ce qui est de toute façon la façon de lire une adresse sur une ligne. Les fichiers étaient valides (l’ADIF compte les octets) ; ils étaient illisibles.",
       "Icom en réseau : un poste laissé en veille ne tourne plus en boucle connexion/déconnexion. L’horloge qui borne « la liaison de contrôle répond mais aucun CI-V ne revient » appartient à une session et n’était jamais remise à zéro à l’ouverture de la suivante : chaque nouvelle session démarrait déjà au-delà de son délai de grâce — coupée aussitôt, rappelée vingt secondes plus tard, recoupée, aussi longtemps que la radio dormait. « Silencieux depuis la connexion » se lit désormais pour ce que c’est : un poste en veille, dont on garde la session pour pouvoir le réveiller.",
-      "La console Icom s’affiche dès que la radio configurée est un Icom, et pas seulement quand le poste parle — c’est là que se trouve le bouton d’allumage, il manquait donc au seul moment où il servait. Le backend configuré suit aussi un changement de radio fait depuis la barre d’état, au lieu d’attendre un passage dans les réglages et un « Enregistrer » qui ne changeait rien."
+      "La console Icom s’affiche dès que la radio configurée est un Icom, et pas seulement quand le poste parle — c’est là que se trouve le bouton d’allumage, il manquait donc au seul moment où il servait. Le backend configuré suit aussi un changement de radio fait depuis la barre d’état, au lieu d’attendre un passage dans les réglages et un « Enregistrer » qui ne changeait rien.",
+      "Icom en réseau : quand le CI-V devient muet alors que le flux audio expérimental continue d’arriver, le journal le dit et nomme l’option à essayer. Les deux partagent la session du poste, et c’est exactement la forme observée en vrai — des centaines de paquets audio, pas une réponse CI-V, le chien de garde qui coupe la session, et tout qui recommence."
     ]
   },
   {

internal/cat/icomaudio.go

@@ -67,12 +67,26 @@ type icomAudio struct {
 	txOuter uint16
 	txSend  uint16
 	lastRx  atomic.Int64 // UnixNano of last packet (liveness)
+	rxCount atomic.Int64 // packets delivered on this stream
 
 	done      chan struct{}
 	closeOnce sync.Once
 }
 
-func (a *icomAudio) markRx() { a.lastRx.Store(time.Now().UnixNano()) }
+func (a *icomAudio) markRx() {
+	a.lastRx.Store(time.Now().UnixNano())
+	a.rxCount.Add(1)
+}
+
+// packets reports whether the stream is actually delivering — the difference
+// between "audio is on" and "audio is arriving", which is what makes it worth
+// naming as a suspect when CI-V has gone quiet on the same session.
+func (a *icomAudio) packets() int64 {
+	if a == nil {
+		return 0
+	}
+	return a.rxCount.Load()
+}
 
 // Close tears the audio stream down (disconnect a few times; UDP is lossy).
 func (a *icomAudio) Close() {

internal/cat/icomnet.go

@@ -496,6 +496,17 @@ func (n *icomNet) civPump() {
 			}
 			debugLog.Printf("icom net: no CI-V DATA for 10 s (transport last heard %s ago; last scope frame %s ago; last socket error: %v; missing-seq backlog: %d; CI-V commands SENT since the last answer: %d)",
 				time.Since(lastPkt).Round(time.Second), scopeAge, lastErr, len(n.rxMissing), n.txCiv.Load()-n.txAtData.Load())
+			// THE AUDIO STREAM IS THE FIRST SUSPECT, AND ONLY THE LOG CAN SAY SO.
+			//
+			// The RX audio stream is experimental and shares the rig's session with
+			// CI-V. The shape seen in the field is exactly this one: audio packets
+			// arriving by the hundred while not one CI-V reply comes back, the
+			// watchdog tearing the session down, and the whole thing beginning
+			// again — a loop an operator reads as "the Icom keeps disconnecting",
+			// with nothing pointing at the switch that would end it.
+			if n.audio != nil && n.audio.packets() > 0 {
+				debugLog.Printf("icom net: the RX audio stream is running and still delivering while CI-V has gone quiet — that option is experimental and shares this session. If the drops continue, turn OFF \"Stream RX audio over the network\" in Settings → CAT and see whether control steadies.")
+			}
 			// And try the gentle repair before the 30 s watchdog tears the whole
 			// session down: if the rig quietly closed the CI-V data flow (the
 			// transport is still chatting, so the session itself stands), saying