Reconnection is a term that doesn't exist in the implementation of the group, so this isn't possible to be implemented. Simply the SRT library doesn't have information it could use to calculate this statistical data.

Where's the problem: SRT knows only that the application requested a connection. If this connection breaks, it's removed. If the application connects to the same address again, SRT doesn't have any "history information" about the connection that was used once already. Even if you have used this connection in the past, for SRT this is always a "new connection".

Application is the only actor here that knows that particular connection is "renewed" and as well the only actor that undertakes the action of "reconnecting a broken link". The best place then to keep this information is in the application's connection table as this is the only place that can "identify the old and new link as the same".

"Reconnection counter" is an incorrect term I used in the title. However, the description talks about the "switch counter".

Ok, so one more thing, just to make sure about the implementation.

If you have a situation that a link is considered unstable, the only reaction is activation of the highest priority idle link. Nothing more at the moment, and since this time there are two links used. Also there's nothing done about this fact for some initial period of time as the link is "temporary activated" and until this state is over, it's not considered parallel.

Only after this period is over, the temporary activation state is cleared and since this moment the link can potentially be treated as parallel. USUALLY though if the link was really broken, this link will be likely removed before this check could be performed. It works then more-less this way (let's say that every line represents a single call of the sending function, just the number of these calls here is way less than in reality):

running/stable | idle
running/stable | idle
running/UNSTABLE | running/tmpactive <-- GROUPSTABTIMEO exceeded, link unstable!
running/UNSTABLE | running/tmpactive (no parallel links atm)
running/UNSTABLE | running/tmpactive
running/UNSTABLE | running/tmpactive
BROKEN | running/tmpactive <-- the stability problem resolved to broken link
... | running/tmpactive
... | running/stable <-- Temporary activation period is over

The question is, which exactly event should cause the counter to be increased?

Note also that in case of the "stability overreaction" the scenario is a little different:

running/stable | idle
running/stable | idle
running/UNSTABLE | running/tmpactive <-- GROUPSTABTIMEO exceeded, link unstable!
running/UNSTABLE | running/tmpactive (no parallel links atm)
running/stable | running/tmpactive <-- Stable again!
running/stable | running/tmpactive
running/stable | running/stable <-- Temporary activation period is over
running/stable | idle <-- Link silenced

I think this situation also deserves some stats to be collected, but if you only have a counter of activated links, these two situations would not be distinguishable.