simon/qortal-go-2.0
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
qortal-go-2.0/docs/gcall-call-review-summary.md
T
phil b8fe67f155 fixes upnp issue and group calls
2026-05-14 02:17:53 +03:00

378 KiB
Raw Permalink Blame History

GCall Call Review Summary

This file records reviewed group-call diagnostics using the checklist in docs/gcall-call-review-template.md.

Call: 2026-05-05 12:57Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-05T12-57-34-020Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-05T12-57-29-656Z.json

User symptom:

  • New paired call after the latest receive-policy changes; subjective symptom was not included with the export, so user-bad is inferred from receive metrics and recovery profiles.

High-level verdict:

  • Mixed/bad.
  • Correctness paths are clean, but both sides are still policy-dominated, with one side near-empty and repair-heavy and the other over-classified into the strongest recovery profile.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Queue/backpressure: Reticulum bridge/binary high-water values are 0 on both sides.
  • Startup playout: both playouts are active, jitterHasReadyFrame is true, playback/scheduler nodes are active, and audio contexts are running.
  • Failover: root/cluster promotion counts are 0 on both sides.

Primary next target:

  • Selector.
  • Specifically, prevent collapse-recovery from winning when reserve is materially healthy and concealment pressure is low; that Linux/root side fits a buffered missing-frame/repair shape better than true collapse.
  • Code target: selectSingleSourceReceiveProfile in src/lib/group-call/groupCallAudioReceiveEngine.ts, where severeSingleSourceHold currently returns collapse-recovery before the repair profiles unless buffered-not-ready is active.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP persistent-lean yes 11.596 363 478 0.066 0.062 recovery Classification matches the shallow-buffer, ongoing roughness shape.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 collapse-recovery partly 31.361 783 18 0.050 0.014 recovery Profile looks too strong for the exported symptom: reserve is not collapsed and concealment is mild.

Side A

Expected profile from symptom:

  • persistent-lean, possibly bordering repair-collapse because concealment is high.

Actual exported profile:

  • persistent-lean

Did classification match?

  • Yes.

Notes:

  • avgPcmBufferedMs is only 11.596, jitterBufferDepthFramesMean is 0.587, avgPlayoutDeltaMs is -112.212, and concealment is high at 478.
  • This is a real weak-listener policy case, not key, queue, failover, or startup.

Side B

Expected profile from symptom:

  • repair-heavy-connected or a lighter repair/missing-frame profile.

Actual exported profile:

  • collapse-recovery

Did classification match?

  • No/partly.

If no:

  • The side has high missingFrames (783) but very low concealmentTicks (18), healthy-ish avgPcmBufferedMs (31.361), low playoutRateFractionBelow097 (0.014), and only moderate under-target pressure (0.050).
  • Retune selector entry/priority for collapse-recovery before increasing its target or floor.

Trend Read

Side A:

  • Flat-bad with gradual counter growth.
  • Reasons seen:
    • missingFrames increases from 307 to 363.
    • concealmentTicks increases from 388 to 478.
    • buffer stays shallow around 11.3 to 11.6 ms.
    • no decrypt/decode/transport reasons.

Side B:

  • Oscillating selector/mode behavior over a buffered repair path.
  • Reasons seen:
    • entered-recovery appears twice.
    • adaptive mode flips from recovery to low-latency and back to recovery.
    • missingFrames increases from 669 to 783, while concealment only increases from 14 to 18.
    • buffer stays around 31 to 33 ms rather than collapsing.

Call: 2026-05-05 13:13Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-05T13-13-16-416Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-05T13-13-13-521Z.json

User symptom:

  • New paired call after the selector escape change; subjective symptom was not included with the export, so user-bad is inferred from receive metrics and recovery profiles.

High-level verdict:

  • Bad.
  • Correctness paths remain clean, but both sides are still policy-dominated and exported as collapse-recovery; the remaining problem is no longer the previous healthy-buffer overclassification.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Queue/backpressure: Reticulum bridge/binary high-water values are 0 on both sides.
  • Startup playout: both playouts are active, jitterHasReadyFrame is true, playback/scheduler nodes are active, and audio contexts are running.
  • Failover: root/cluster promotion counts are 0 on both sides.

Primary next target:

  • collapse-recovery profile strength.
  • The selector now lands both sides in a defensible severe/near-severe profile, but the profile is not rebuilding reserve enough: Mac stays around 7 ms, Linux stays around 19 ms, and both remain in recovery with strongly negative playout delta.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP collapse-recovery yes 7.290 180 611 0.059 0.054 recovery Classification matches true severe collapse: tiny reserve, high concealment, very negative delta.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 collapse-recovery yes 18.891 899 13 0.027 0.005 recovery Classification is acceptable/partly correct: reserve is under the lean floor and delta is very negative, though concealment is low.

Side A

Expected profile from symptom:

  • collapse-recovery

Actual exported profile:

  • collapse-recovery

Did classification match?

  • Yes.

Notes:

  • avgPcmBufferedMs is only 7.290, jitterBufferDepthFramesMean is 0.370, avgPlayoutDeltaMs is -115.466, and concealmentTicks is 611.
  • This is exactly the class that should receive the strongest collapse target/floor.

Side B

Expected profile from symptom:

  • collapse-recovery or silent-lean

Actual exported profile:

  • collapse-recovery

Did classification match?

  • Partly/yes.

Notes:

  • This side is no longer the previous healthy-buffer false positive. avgPcmBufferedMs is 18.891, under the low-reserve band, and avgPlayoutDeltaMs is -139.200.
  • Low concealmentTicks (13) and low playoutRateFractionBelow097 (0.005) make it less obviously repair-collapse, but the tiny reserve plus high missingFrames (899) still justify a strong recovery path.

Trend Read

Side A:

  • Flat-bad with gradual counter growth.
  • Reasons seen:
    • missingFrames increases from 144 to 180.
    • concealmentTicks increases from 523 to 611.
    • buffer stays pinned around 6.9 to 7.3 ms.
    • no decrypt/decode/transport reasons.

Side B:

  • Oscillating mode over a still-shallow path.
  • Reasons seen:
    • entered-recovery appears three times.
    • adaptive mode flips between recovery and low-latency.
    • missingFrames increases from 715 to 899.
    • buffer only rebuilds from 18.1 to 18.9 ms, still below the low-reserve threshold.

Call: 2026-05-05 13:34Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-05T13-34-46-268Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-05T13-34-43-094Z.json

User symptom:

  • New paired call after the collapse-recovery strength change; subjective symptom was not included with the export, so user-bad is inferred from receive metrics and recovery profiles.

High-level verdict:

  • Bad/mixed.
  • Receive policy still reports collapse-recovery on both sides, but this call introduces non-policy blockers: Linux/root has decode failures, and Mac/standby has a ready-state contradiction with buffered jitter frames but no ready frame.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Queue/backpressure: Reticulum bridge/binary high-water values are 0 on both sides.
  • Failover: root/cluster promotion counts are 0 on both sides.

Primary next target:

  • Another subsystem: decode/session path first, then playout readiness/mode synchronization.
  • Do not tune receive profile strength or baseline from this call until packetsDroppedDecodeFailure=33 on Linux/root and the Mac jitterBufferedFrames=12 / jitterHasReadyFrame=false state are explained.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP collapse-recovery yes 9.484 617 7 0.024 0.003 recovery Classification is suspicious: low reserve and very negative delta, but low concealment/under-target and jitterHasReadyFrame=false with 12 buffered frames points at readiness/mode sync.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 collapse-recovery yes 13.914 370 425 0.113 0.101 recovery Classification matches collapse symptoms, but packetsDroppedDecodeFailure=33 makes decode/session correctness the first target.

Side A

Expected profile from symptom:

  • buffered-not-ready or silent-lean

Actual exported profile:

  • collapse-recovery

Did classification match?

  • Partly/no.

If no:

  • avgPcmBufferedMs is only 9.484 and avgPlayoutDeltaMs is -132.257, so a severe path is understandable.
  • But concealmentTicks is only 7, playoutUnderTargetFraction is 0.024, playoutRateFractionBelow097 is 0.003, and the playout snapshot says jitterBufferedFrames=12 with jitterHasReadyFrame=false.
  • This should be treated as a playout readiness/mode synchronization issue before selector or strength tuning.

Side B

Expected profile from symptom:

  • collapse-recovery

Actual exported profile:

  • collapse-recovery

Did classification match?

  • Yes for the receive symptom, but root cause is not cleanly receive-policy.

Notes:

  • avgPcmBufferedMs is 13.914, avgPlayoutDeltaMs is -153.318, concealmentTicks is 425, and playoutRateFractionBelow097 is 0.101, so the collapse profile fits the audible damage.
  • packetsDroppedDecodeFailure=33 is a quick-triage correctness signal and should be investigated before another receive-policy patch.

Trend Read

Side A:

  • Oscillating mode with suspicious readiness state.
  • Reasons seen:
    • adaptive mode flips low-latency to recovery near the end.
    • missingFrames increases from 477 to 617.
    • concealmentTicks stays almost flat from 6 to 7.
    • buffer stays near 9 ms, and playout snapshot has buffered frames but jitterHasReadyFrame=false.

Side B:

  • Flat-bad/degrading with decode failures.
  • Reasons seen:
    • packetsDroppedDecodeFailure is 33 for the entire sampled trend.
    • concealmentTicks increases from 295 to 425.
    • missingFrames jumps from 135 to 370.
    • buffer falls from about 15.1 to 13.9 ms and remains shallow.

Call: 2026-05-05 14:53Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-05T14-53-12-293Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-05T14-53-14-926Z.json

User symptom:

  • New paired call after the repair-heavy selector/hold change; subjective symptom was not included with the export, so user-bad is inferred from receive metrics and exported profiles.

High-level verdict:

  • Mixed/bad.
  • Correctness paths are clean and collapse-recovery no longer dominates, but classification is now split: Mac is a true extremely shallow silent-lean path with a buffered-but-not-ready playout snapshot, while Linux is over-classified as weak despite a very healthy reserve.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Queue/backpressure: Reticulum bridge/binary high-water values are low (3/2 on Mac, 2/1 on Linux) with no queue-pressure drops.
  • Failover: root/cluster promotion counts are 0 on both sides.

Primary next target:

  • Selector / playout readiness, not baseline or profile strength.
  • Mac needs the selector/readiness path to treat avgPcmBufferedMs=2.366, jitterBufferedFrames=10, and jitterHasReadyFrame=false as the dominant failure shape instead of letting the runtime remain in low-latency while the exported profile says silent-lean.
  • Linux needs a healthy-reserve escape from steady-weak-listener: avgPcmBufferedMs=73.273, jitterHasReadyFrame=true, low concealment, and low under-target pressure do not match a user-bad weak listener.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP silent-lean yes 2.366 802 2 0.002 0.000 low-latency Classification matches the tiny-reserve blind spot, but runtime mode/readiness does not: 10 jitter frames are buffered while no ready frame is reported.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 steady-weak-listener no/partly 73.273 328 10 0.016 0.007 recovery Classification is too pessimistic for a healthy-reserve, low-concealment side; only late recovery entry and moderate missing frames support a weak label.

Side A

Expected profile from symptom:

  • silent-lean or buffered-not-ready

Actual exported profile:

  • silent-lean

Did classification match?

  • Yes for profile family, partly for runtime behavior.

Notes:

  • avgPcmBufferedMs is only 2.366, jitterBufferDepthFramesMean is 0.120, and avgPlayoutDeltaMs is -118.416, so this is a real shallow-buffer blind spot.
  • concealmentTicks is only 2, playoutUnderTargetFraction is only 0.002, and the playout snapshot says jitterBufferedFrames=10 with jitterHasReadyFrame=false.
  • The next patch should make this state drive protective mode/readiness behavior more directly; raising baseline globally would not explain why 10 buffered frames are not ready.

Side B

Expected profile from symptom:

  • clean-low-latency or at most steady-weak-listener briefly after the late recovery entry.

Actual exported profile:

  • steady-weak-listener

Did classification match?

  • Partly/no.

If no:

  • avgPcmBufferedMs is 73.273, jitterBufferDepthFramesMean is 3.733, jitterBufferedFrames=23, jitterHasReadyFrame=true, concealmentTicks=10, and playoutUnderTargetFraction=0.016.
  • This side looks buffered and mostly healthy; tune selector clear/escape conditions for weak-listener classification before touching profile target sizes or baseline policy.

Trend Read

Side A:

  • Flat-bad shallow-buffer state with gradual missing-frame growth.
  • Reasons seen:
    • missingFrames increases from 666 to 802.
    • concealmentTicks stays nearly flat from 1 to 2.
    • buffer stays pinned around 2.3 ms.
    • adaptive mode moves from recovery back to low-latency even though the playout snapshot remains not-ready.

Side B:

  • Mostly healthy-buffer with a late discrete recovery entry.
  • Reasons seen:
    • entered-recovery appears once near the end.
    • missingFrames increases from 295 to 328.
    • concealmentTicks only rises from 0 to 10.
    • buffer stays around 73 to 74 ms, with ready jitter frames.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-05T12:57Z group-812 A / Mac standby persistent-lean yes yes receive policy strength Keep as evidence, but do not tune first.
2026-05-05T12:57Z group-812 B / Linux root collapse-recovery partly no/partly selector Done: added stale severe-hold escape for ready buffered low-concealment paths.
2026-05-05T13:13Z group-812 A / Mac standby collapse-recovery yes yes receive policy strength Done: raised collapse-recovery target/floor and collapse-only hold headroom.
2026-05-05T13:13Z group-812 B / Linux root collapse-recovery yes partly/yes receive policy strength Done for strength; watch whether low-concealment shallow paths need a later selector split.
2026-05-05T13:34Z group-812 A / Mac standby collapse-recovery yes partly/no startup/playout-ready Investigate buffered-but-not-ready playout state and recovery/low-latency mode sync.
2026-05-05T13:34Z group-812 B / Linux root collapse-recovery yes yes decode/session Investigate packetsDroppedDecodeFailure=33 before more receive-policy tuning.

Next Fix Target

Current patched target:

  • collapse-recovery now has a stronger target/floor and collapse-only extra-hold headroom.
  • Keep the selector escape from the 12:57 review; the 13:13 call no longer showed the same healthy-buffer false positive.
  • The 13:34 logs shift the next fix away from receive-policy tuning: first inspect the Linux decode/session failure path, then the Mac buffered-but-not-ready playout readiness state.

Call: 2026-05-05 14:14Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-05T14-14-50-550Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-05T14-14-47-842Z.json

User symptom:

  • New paired call after the previous receive-policy changes; subjective symptom was not included with the export, so user-bad is inferred from receive metrics and non-clean profiles.

High-level verdict:

  • Mixed/improved.
  • Both sides moved out of collapse-recovery into repair-heavy-connected, with no decrypt/decode/queue/failover errors and much healthier reserve than the earlier collapse calls, but both are still accumulating missing frames and re-entering recovery.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Queue/backpressure: Reticulum bridge/binary high-water values are 0 on both sides.
  • Failover: root/cluster promotion counts are 0 on both sides.
  • Collapse profile strength: neither side is now classified as collapse-recovery.

Primary next target:

  • Selector.
  • Specifically, tune the recovery/profile selector and hold behavior around repair-heavy-connected: this call has healthy reserve (45.729 ms Mac, 64.204 ms Linux), low concealment (85 / 20), and only modest under-target/rate pressure, yet both sides remain non-clean and re-enter recovery.
  • Do not raise baseline or collapse-recovery strength from this call; the collapse target/floor change appears to have done its job by moving the call into a buffered repair profile.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP repair-heavy-connected partly 45.729 1255 85 0.063 0.046 recovery Classification partly matches high missing-frame repair, but reserve is healthy and concealment is modest.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 repair-heavy-connected partly/no 64.204 687 20 0.070 0.028 recovery Classification is more suspicious: very healthy reserve, very low concealment, and only modest rate pressure.

Side A

Expected profile from symptom:

  • repair-heavy-connected or steady-weak-listener

Actual exported profile:

  • repair-heavy-connected

Did classification match?

  • Partly.

Notes:

  • missingFrames is high at 1255, so a repair profile is defensible.
  • But avgPcmBufferedMs is 45.729, jitterBufferDepthFramesMean is 2.318, jitterHasReadyFrame is true, and concealmentTicks is only 85.
  • This looks like buffered repair/missing-frame pressure, not collapse, startup, decode, or baseline starvation.

Side B

Expected profile from symptom:

  • steady-weak-listener or clean-low-latency with repair counters watched.

Actual exported profile:

  • repair-heavy-connected

Did classification match?

  • Partly/no.

If no:

  • avgPcmBufferedMs is 64.204, jitterBufferDepthFramesMean is 3.252, and concealmentTicks is only 20.
  • jitterBufferedFrames=9 with jitterHasReadyFrame=false is a small readiness mismatch, but the reserve metrics are otherwise healthy and decode is clean.
  • Tune selector entry/hold thresholds for repair-heavy-connected before changing profile strength or baseline policy.

Trend Read

Side A:

  • Gradual repair-counter growth with oscillating recovery entry.
  • Reasons seen:
    • entered-recovery appears twice.
    • missingFrames increases from 1104 to 1255.
    • concealmentTicks only increases from 77 to 85.
    • buffer remains healthy around 44.4 to 45.7 ms.

Side B:

  • Gradual repair-counter growth with oscillating recovery entry.
  • Reasons seen:
    • entered-recovery appears twice.
    • missingFrames increases from 571 to 687.
    • concealmentTicks only increases from 18 to 20.
    • buffer remains healthy around 64 to 65 ms.

Call: 2026-05-05 15:56Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-05T15-56-59-433Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-05T15-56-56-210Z.json

User symptom:

  • New paired call after the selector/playout-ready changes; subjective symptom was not included with the export, so user-bad is inferred from receive metrics and non-clean profiles.

High-level verdict:

  • Mixed/bad.
  • Correctness paths remain clean, and both playout snapshots are now ready, but both sides still show under-target pressure, negative playout delta, and missing-frame growth. Mac is misclassified as buffered-not-ready after readiness has returned; Linux is plausibly weak but not clean.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Startup hidden playout: both sides have active playback/scheduler nodes and jitterHasReadyFrame=true.
  • Failover: root/cluster promotion counts are 0 on both sides.
  • Collapse profile strength: neither side is in collapse-recovery.

Primary next target:

  • Selector.
  • First fix the buffered-not-ready clear/escape path: Mac exports buffered-not-ready even though jitterHasReadyFrame=true, reserve is 37.192 ms, and the live mode has already fallen back to low-latency.
  • Do not raise baseline yet. Linux’s steady-weak-listener classification is defensible, but Mac’s wrong ready-state profile means selector/hold cleanup should come before profile strength or baseline changes.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP buffered-not-ready yes 37.192 729 72 0.105 0.081 low-latency Classification is wrong/partly: playout is ready with 5 buffered jitter frames, but the profile is still ready-failure shaped.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 steady-weak-listener partly 48.970 431 26 0.063 0.028 low-latency Classification mostly matches a moderate weak-listener path: ready, buffered, but still under target with missing-frame growth.

Side A

Expected profile from symptom:

  • repair-heavy-connected or steady-weak-listener

Actual exported profile:

  • buffered-not-ready

Did classification match?

  • Partly/no.

If no:

  • jitterHasReadyFrame=true, jitterBufferedFrames=5, avgPcmBufferedMs=37.192, and jitterBufferDepthFramesMean=1.885, so this no longer fits a not-ready profile.
  • The bad symptoms are real: playoutUnderTargetFraction=0.105, playoutRateFractionBelow097=0.081, avgPlayoutDeltaMs=-96.983, missingFrames=729, and concealmentTicks=72.
  • Tune selector clear/hold priority so ready buffered damage moves to steady-weak-listener or repair-heavy-connected, not buffered-not-ready.

Side B

Expected profile from symptom:

  • steady-weak-listener, possibly bordering repair-heavy-connected if missing-frame pressure keeps growing.

Actual exported profile:

  • steady-weak-listener

Did classification match?

  • Yes/partly.

Notes:

  • avgPcmBufferedMs=48.970, jitterHasReadyFrame=true, and concealmentTicks=26 keep this out of collapse or buffered-not-ready.
  • playoutUnderTargetFraction=0.063, avgPlayoutDeltaMs=-84.554, missingFrames=431, and a brief entered-recovery trend justify a weak-listener profile.
  • This side is not enough evidence for baseline tuning until the Mac selector error is fixed.

Trend Read

Side A:

  • Gradual weak/repair damage with a late low-latency exit despite continuing pressure.
  • Reasons seen:
    • missingFrames increases from 607 to 729.
    • concealmentTicks increases from 56 to 72.
    • playoutUnderTargetFraction stays around 0.10.
    • adaptive mode exits recovery to low-latency near the end while the exported profile remains buffered-not-ready.

Side B:

  • Mostly steady weak-listener path with one brief recovery entry.
  • Reasons seen:
    • entered-recovery appears once.
    • missingFrames increases from 333 to 431.
    • concealmentTicks stays modest at 23 to 26.
    • buffer gradually improves from about 45.9 to 49.0 ms.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-05T12:57Z group-812 A / Mac standby persistent-lean yes yes receive policy strength Keep as evidence, but do not tune first.
2026-05-05T12:57Z group-812 B / Linux root collapse-recovery partly no/partly selector Done: added stale severe-hold escape for ready buffered low-concealment paths.
2026-05-05T13:13Z group-812 A / Mac standby collapse-recovery yes yes receive policy strength Done: raised collapse-recovery target/floor and collapse-only hold headroom.
2026-05-05T13:13Z group-812 B / Linux root collapse-recovery yes partly/yes receive policy strength Done for strength; watch whether low-concealment shallow paths need a later selector split.
2026-05-05T13:34Z group-812 A / Mac standby collapse-recovery yes partly/no startup/playout-ready Investigate buffered-but-not-ready playout state and recovery/low-latency mode sync.
2026-05-05T13:34Z group-812 B / Linux root collapse-recovery yes yes decode/session Decode failures are gone in 14:14Z; keep watching but do not tune from this old blocker now.
2026-05-05T14:14Z group-812 A / Mac standby repair-heavy-connected partly partly selector / repair hold Tune repair-heavy-connected entry/hold/exit so high missing-frame counters do not keep a healthy-reserve low-concealment side over-protected.
2026-05-05T14:14Z group-812 B / Linux root repair-heavy-connected partly/no partly/no selector / repair hold Same selector target, with stronger evidence because reserve is 64.204 ms and concealment is only 20.
2026-05-05T14:53Z group-812 A / Mac standby silent-lean yes yes/partly selector / playout-ready Treat tiny-reserve buffered-but-not-ready as the next primary bad-side target; align low-latency/recovery mode with silent-lean readiness.
2026-05-05T14:53Z group-812 B / Linux root steady-weak-listener no/partly partly/no selector Add/tighten healthy-reserve weak-listener escape so this side can clear toward clean-low-latency.
2026-05-05T15:56Z group-812 A / Mac standby buffered-not-ready yes partly/no selector / readiness hold Tune buffered-not-ready clear/escape when jitterHasReadyFrame=true; ready buffered damage should classify as weak/repair, not not-ready.
2026-05-05T15:56Z group-812 B / Linux root steady-weak-listener partly yes/partly selector / weak-listener Keep as evidence after Mac selector fix; do not tune baseline from this side alone.

Next Fix Target

Current patched target:

  • Selector.
  • Primary fix: make buffered-not-ready clear immediately, or lose priority, once jitterHasReadyFrame=true; ready buffered damage should fall through to steady-weak-listener or repair-heavy-connected.
  • Secondary watch item: after the Mac selector fix, decide whether steady-weak-listener needs more target/floor for the Linux-style moderate under-target path.
  • Keep collapse-recovery strength and global baseline unchanged for the next patch.

Call: 2026-05-05 16:48Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-05T16-48-33-310Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-05T16-48-31-124Z.json

User symptom:

  • New paired call after the latest selector/readiness changes; subjective symptom was not included with the export, so user-bad is inferred from receive metrics, not-ready state, and non-clean profiles.

High-level verdict:

  • Bad/mixed.
  • Correctness paths remain clean, but classification is still not aligned with the exported symptoms: Mac is buffered-but-not-ready and shallow while classified as steady-weak-listener, and Linux is ready with many buffered jitter frames while classified as collapse-recovery.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Queue/backpressure: Reticulum bridge/binary high-water values are low (1/1 on Mac, 2/1 on Linux) with no queue-pressure drops.
  • Failover: root/cluster promotion counts are 0 on both sides.
  • Startup hidden playout nodes: both sides have active playback and scheduler nodes.

Primary next target:

  • Selector / readiness priority.
  • Mac is the clearest current target: jitterBufferedFrames=9 with jitterHasReadyFrame=false, avgPcmBufferedMs=11.997, avgPlayoutDeltaMs=-159.095, and live mode low-latency should not export as ordinary steady-weak-listener.
  • Linux does need protection because reserve is shallow, but collapse-recovery is probably too strong for jitterHasReadyFrame=true, jitterBufferedFrames=22, concealmentTicks=36, and modest rate pressure. It fits persistent-lean / silent-lean / weaker recovery better than a full collapse profile.
  • Do not raise baseline or profile strength from this call. Per the template decision rules, classification is wrong/partly wrong on both sides, so selector/readiness logic comes first.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP steady-weak-listener yes 11.997 493 12 0.024 0.005 low-latency Classification is too mild and misses the not-ready symptom: 9 jitter frames buffered, jitterHasReadyFrame=false, and very negative delta.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 collapse-recovery yes/partly 12.416 500 36 0.040 0.021 recovery Classification is partly too strong: reserve is shallow, but the playout is ready with 22 jitter frames, low concealment, and modest rate pressure.

Side A

Expected profile from symptom:

  • buffered-not-ready or silent-lean

Actual exported profile:

  • steady-weak-listener

Did classification match?

  • No/partly.

If no:

  • The side is clearly shallow and not ready: avgPcmBufferedMs=11.997, jitterBufferDepthFramesMean=0.608, avgPlayoutDeltaMs=-159.095, and the playout snapshot reports jitterBufferedFrames=9 with jitterHasReadyFrame=false.
  • Damage counters are real but not huge: missingFrames=493, concealmentTicks=12, playoutUnderTargetFraction=0.024, and playoutRateFractionBelow097=0.005.
  • This should select a readiness/lean profile and drive protective mode, not stay in live low-latency as an ordinary weak listener.

Side B

Expected profile from symptom:

  • persistent-lean or silent-lean, possibly a lighter recovery profile.

Actual exported profile:

  • collapse-recovery

Did classification match?

  • Partly/no.

If no:

  • The shallow reserve is real: avgPcmBufferedMs=12.416, jitterBufferDepthFramesMean=0.630, avgPlayoutDeltaMs=-113.001, and missingFrames=500.
  • But the collapse classification is too aggressive for jitterHasReadyFrame=true, jitterBufferedFrames=22, concealmentTicks=36, playoutUnderTargetFraction=0.040, and playoutRateFractionBelow097=0.021.
  • This argues for selector priority/threshold cleanup before touching collapse-recovery strength or the global baseline.

Trend Read

Side A:

  • Gradual shallow/not-ready path with mode exiting recovery too early.
  • Reasons seen:
    • missingFrames increases from 351 to 493.
    • concealmentTicks only rises from 10 to 12.
    • buffer slowly improves from about 11.1 to 12.0 ms but remains shallow.
    • adaptive mode exits recovery to low-latency early and stays there even though the playout snapshot is not ready.

Side B:

  • Oscillating mode over a shallow but ready path.
  • Reasons seen:
    • entered-recovery appears three times.
    • adaptive mode flips between recovery and low-latency.
    • missingFrames increases from 360 to 500.
    • concealmentTicks only rises from 30 to 36, while the playout snapshot is ready with 22 buffered jitter frames.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-05T12:57Z group-812 A / Mac standby persistent-lean yes yes receive policy strength Keep as evidence, but do not tune first.
2026-05-05T12:57Z group-812 B / Linux root collapse-recovery partly no/partly selector Done: added stale severe-hold escape for ready buffered low-concealment paths.
2026-05-05T13:13Z group-812 A / Mac standby collapse-recovery yes yes receive policy strength Done: raised collapse-recovery target/floor and collapse-only hold headroom.
2026-05-05T13:13Z group-812 B / Linux root collapse-recovery yes partly/yes receive policy strength Done for strength; watch whether low-concealment shallow paths need a later selector split.
2026-05-05T13:34Z group-812 A / Mac standby collapse-recovery yes partly/no startup/playout-ready Buffered-but-not-ready state still recurs in later calls; keep readiness selector as active target.
2026-05-05T13:34Z group-812 B / Linux root collapse-recovery yes yes decode/session Decode failures are gone in later calls; keep watching but do not tune from this old blocker now.
2026-05-05T14:14Z group-812 A / Mac standby repair-heavy-connected partly partly selector / repair hold Keep as evidence for selector cleanup around healthy-buffer repair holds.
2026-05-05T14:14Z group-812 B / Linux root repair-heavy-connected partly/no partly/no selector / repair hold Keep as evidence for healthy-reserve escapes from over-protective repair profiles.
2026-05-05T14:53Z group-812 A / Mac standby silent-lean yes yes/partly selector / playout-ready Recurring bad-side pattern; readiness/mode should align with silent-lean or buffered-not-ready protection.
2026-05-05T14:53Z group-812 B / Linux root steady-weak-listener no/partly partly/no selector Keep as evidence for healthy-reserve weak-listener escape.
2026-05-05T15:56Z group-812 A / Mac standby buffered-not-ready yes partly/no selector / readiness hold Prior target was clear/escape after readiness returns; the new call shows the opposite miss, so tune both entry and clear priority.
2026-05-05T15:56Z group-812 B / Linux root steady-weak-listener partly yes/partly selector / weak-listener Keep as evidence after Mac selector fix; do not tune baseline from this side alone.
2026-05-05T16:48Z group-812 A / Mac standby steady-weak-listener yes no/partly selector / readiness priority Fix not-ready entry/priority: 9 buffered jitter frames with no ready frame should not remain ordinary weak-listener/low-latency.
2026-05-05T16:48Z group-812 B / Linux root collapse-recovery yes/partly partly/no selector / collapse priority Add/tighten ready-buffered low-concealment escape from collapse-recovery into lean/weak recovery, not stronger collapse or baseline.

Next Fix Target

Current patched target:

  • Selector / readiness priority.
  • Primary fix: make buffered-not-ready / silent-lean entry win when jitterHasReadyFrame=false with buffered jitter frames and shallow reserve, even if damage counters are modest and live mode has fallen back to low-latency.
  • Secondary fix: keep the ready-buffered escape from collapse-recovery strict enough that Linux-style jitterHasReadyFrame=true, many buffered frames, low concealment, and modest rate pressure lands in lean/weak recovery instead of full collapse.
  • Keep global baseline and profile strength unchanged for the next patch; this batch is dominated by classification mismatches, not evidence that a correctly selected profile is too weak.

Call: 2026-05-05 17:10Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-05T17-10-08-202Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-05T17-10-06-530Z.json

User symptom:

  • New paired call after the selector/readiness patch; subjective symptom was not included with the export, so user-bad is inferred from receive metrics and exported profiles.

High-level verdict:

  • Bad, but diagnostically useful.
  • The previous 16:48Z selector misses improved: the not-ready side now lands in buffered-not-ready, and the ready-buffered side no longer lands in collapse-recovery. The remaining bad classification is Mac: it is catastrophically shallow and concealment-heavy, but only exported as persistent-lean.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Queue/backpressure: Reticulum bridge/binary high-water values are low (4/1 on Mac, 2/0 on Linux) with no queue-pressure drops.
  • Failover: root/cluster promotion counts are 0 on both sides.
  • Startup hidden playout nodes: both sides have active playback and scheduler nodes.

Primary next target:

  • Selector.
  • Specifically, make high-concealment tiny-reserve paths beat persistent-lean: Mac has avgPcmBufferedMs=1.877, jitterBufferDepthFramesMean=0.095, avgPlayoutDeltaMs=-118.673, and concealmentTicks=1847, which fits repair-collapse or collapse-recovery, not ordinary persistent-lean.
  • Do not raise baseline yet. Linux’s current buffered-not-ready classification is correct for jitterBufferedFrames=9 with jitterHasReadyFrame=false, and Mac is a wrong-profile problem before it is a profile-strength problem.
  • Secondary watch item: Mac also shows a bursty ingress shape (maxIncomingPacketMs=2196.115, maxReticulumAudioBridgeToRendererIngressMs=2074), but there are no decode/key/queue drops, so fix selector escalation first.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP persistent-lean yes 1.877 452 1847 0.028 0.027 recovery Classification is too weak: tiny reserve plus huge concealment should escalate to repair-collapse or collapse-recovery.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 buffered-not-ready yes 27.560 1255 87 0.062 0.040 recovery Classification matches the not-ready buffered state: 9 jitter frames buffered, no ready frame, and ongoing under-target pressure.

Side A

Expected profile from symptom:

  • repair-collapse or collapse-recovery

Actual exported profile:

  • persistent-lean

Did classification match?

  • No.

If no:

  • This is not just a quiet lean path. The side has avgPcmBufferedMs=1.877, jitterBufferDepthFramesMean=0.095, avgPlayoutDeltaMs=-118.673, and concealmentTicks=1847.
  • jitterHasReadyFrame=true with jitterBufferedFrames=19 means this is not the buffered-not-ready state from the previous call.
  • The selector should let active concealment plus tiny reserve outrank persistent-lean; retune selector priority/entry before changing persistent-lean strength.

Side B

Expected profile from symptom:

  • buffered-not-ready

Actual exported profile:

  • buffered-not-ready

Did classification match?

  • Yes.

Notes:

  • jitterBufferedFrames=9 with jitterHasReadyFrame=false is the exact readiness failure shape targeted after 16:48Z.
  • avgPcmBufferedMs=27.560, avgPlayoutDeltaMs=-102.196, playoutUnderTargetFraction=0.062, and missingFrames=1255 support a protective profile.
  • This side is evidence that the readiness selector fix moved in the right direction; the next patch should not weaken buffered-not-ready.

Trend Read

Side A:

  • Flat-bad collapse/repair path.
  • Reasons seen:
    • avgPcmBufferedMs stays pinned around 1.88 ms.
    • concealmentTicks climbs steadily from 1581 to 1847.
    • missingFrames increases from 395 to 452.
    • adaptive mode stays in recovery throughout, but the exported profile remains persistent-lean.

Side B:

  • Oscillating mode over a not-ready buffered path.
  • Reasons seen:
    • entered-recovery appears three times.
    • adaptive mode flips between low-latency and recovery.
    • missingFrames increases from 1100 to 1255.
    • jitterHasReadyFrame=false with 9 buffered jitter frames supports buffered-not-ready.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-05T12:57Z group-812 A / Mac standby persistent-lean yes yes receive policy strength Keep as evidence, but do not tune first.
2026-05-05T12:57Z group-812 B / Linux root collapse-recovery partly no/partly selector Done: added stale severe-hold escape for ready buffered low-concealment paths.
2026-05-05T13:13Z group-812 A / Mac standby collapse-recovery yes yes receive policy strength Done: raised collapse-recovery target/floor and collapse-only hold headroom.
2026-05-05T13:13Z group-812 B / Linux root collapse-recovery yes partly/yes receive policy strength Done for strength; watch whether low-concealment shallow paths need a later selector split.
2026-05-05T13:34Z group-812 A / Mac standby collapse-recovery yes partly/no startup/playout-ready Buffered-but-not-ready state still recurs in later calls; keep readiness selector as active target.
2026-05-05T13:34Z group-812 B / Linux root collapse-recovery yes yes decode/session Decode failures are gone in later calls; keep watching but do not tune from this old blocker now.
2026-05-05T14:14Z group-812 A / Mac standby repair-heavy-connected partly partly selector / repair hold Keep as evidence for selector cleanup around healthy-buffer repair holds.
2026-05-05T14:14Z group-812 B / Linux root repair-heavy-connected partly/no partly/no selector / repair hold Keep as evidence for healthy-reserve escapes from over-protective repair profiles.
2026-05-05T14:53Z group-812 A / Mac standby silent-lean yes yes/partly selector / playout-ready Recurring bad-side pattern; readiness/mode should align with silent-lean or buffered-not-ready protection.
2026-05-05T14:53Z group-812 B / Linux root steady-weak-listener no/partly partly/no selector Keep as evidence for healthy-reserve weak-listener escape.
2026-05-05T15:56Z group-812 A / Mac standby buffered-not-ready yes partly/no selector / readiness hold Prior target was clear/escape after readiness returns; later calls show both entry and clear priority now improving.
2026-05-05T15:56Z group-812 B / Linux root steady-weak-listener partly yes/partly selector / weak-listener Keep as evidence; not enough for baseline tuning.
2026-05-05T16:48Z group-812 A / Mac standby steady-weak-listener yes no/partly selector / readiness priority Improved in 17:10Z: the analogous not-ready buffered side now exports buffered-not-ready.
2026-05-05T16:48Z group-812 B / Linux root collapse-recovery yes/partly partly/no selector / collapse priority Improved in 17:10Z: ready-buffered low-concealment no longer exports as collapse-recovery.
2026-05-05T17:10Z group-812 A / Mac standby persistent-lean yes no selector / repair escalation Fix high-concealment tiny-reserve priority so this lands in repair-collapse or collapse-recovery.
2026-05-05T17:10Z group-812 B / Linux root buffered-not-ready yes yes selector / readiness Keep current readiness selector; do not weaken buffered-not-ready.

Next Fix Target

Current patched target:

  • Selector.
  • Primary fix: make active high concealment with near-empty reserve outrank persistent-lean, even when jitterHasReadyFrame=true; this should classify as repair-collapse or collapse-recovery.
  • Keep buffered-not-ready, global baseline, and profile strength unchanged for the next patch.
  • Watch the Mac ingress-burst metrics after classification is corrected; if the side still collapses under the correct heavy profile, then inspect transport/ingress pacing as a separate subsystem.

Call: 2026-05-05 17:49Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-05T17-49-47-712Z.json
  • Side B: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-05T17-49-54-656Z.json

User symptom:

  • The call was left running for minutes, but neither side could hear the other.

High-level verdict:

  • Catastrophic media-path/key-establishment failure.
  • This call never reached receive-profile territory: both sides exported packetsReceived=0, packetsDecoded=0, no playouts, no jitter buffers, and no live policy profiles.

Not the problem:

  • Receive selector/profile strength/baseline: no side received any audio to classify.
  • Decode: packetsDroppedDecodeFailure=0 on both sides because no inbound audio reached decode.
  • Jitter/playout policy: no playout nodes or source profiles existed on either side.
  • Linux sender capture: Linux had a running sender, 15195 encoded frames, 15195 send attempts, and 15195 send successes.

Primary next target:

  • Another subsystem: room-key distribution / media-path establishment.
  • Mac stayed awaitingAuthoritativeKey=true, roomKeyPresent=false, sender engine stopped, and outbound counters remained zero. It repeatedly requested the room key from Linux (60 recent room-key-requested events) but never applied a key.
  • Linux owned and minted the room key and sent thousands of encrypted packets to Mac, but the root diagnostics did not show targeted-room-key-sent; this points at root-side key distribution/encryption/recipient roster handling rather than receive policy.
  • Fix applied after this review: preserve known non-empty participant public keys when hydrating/merging rosters and when building root key recipients, so a stale main roster with an empty public key cannot erase the usable key learned from participant events. Added room-key-rotate-sent, room-key-distribution-skipped, and targeted-room-key-skipped diagnostics.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QP9Jj4...i6rP none / no receive source yes 0 0 0 0 0 low-latency Sender was alive and sent 15195 frames to Mac; inbound audio stayed at zero. Root owned the key, but no key-send success was visible in diagnostics.
B standby-forwarder / Mac / QaU2XU...Jh91 none / no receive source yes 0 0 0 0 0 low-latency No room key, no mic sender, no outbound packets, no inbound packets. It repeatedly requested the root key and stayed awaitingAuthoritativeKey=true.

Side A

Expected profile from symptom:

  • No receive profile; media/key path did not establish.

Actual exported profile:

  • None.

Did classification match?

  • Yes, in the sense that absence of a profile matches the symptom better than any receive-profile classification.

If no:

  • Not applicable. The failure happened before receive classification.

Side B

Expected profile from symptom:

  • No receive profile; waiting for authoritative key.

Actual exported profile:

  • None.

Did classification match?

  • Yes.

Notes:

  • pipelineMode.roomKeyPresent=false, awaitingAuthoritativeKey=true, senderEngine.hasMicStream=false, encodedFrameCallbacks=0, and repeated room-key-requested events explain why Mac never sent or decoded audio.
  • This is a correctness/path setup failure, not a weak listener.

Trend Read

Side A:

  • Flat zero-inbound with active outbound sender.
  • Reasons seen:
    • reticulumAudioPacketPathTimeouts=55.
    • outbound packet sends continued, but inbound samples stayed 0.
    • recent events were dominated by topology heartbeats.

Side B:

  • Flat key-wait state.
  • Reasons seen:
    • recent events were dominated by repeated retained-key-replay-requested and room-key-requested.
    • metrics were stale because no receive-engine updates occurred in the zero-media state.
    • no sender startup occurred because no room key was applied.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-05T16:48Z group-812 A / Mac standby steady-weak-listener yes no/partly selector / readiness priority Done: not-ready buffered state now promotes correctly.
2026-05-05T16:48Z group-812 B / Linux root collapse-recovery yes/partly partly/no selector / collapse priority Done: ready-buffered low-concealment escape added.
2026-05-05T17:10Z group-812 A / Mac standby persistent-lean yes no selector / repair escalation Done: near-empty high-concealment paths latch out of persistent lean.
2026-05-05T17:10Z group-812 B / Linux root buffered-not-ready yes yes selector / readiness Keep current readiness selector.
2026-05-05T17:49Z group-812 A / Linux root none / no receive source yes yes key/media-path establishment Done: preserve non-empty public keys during roster merge and root recipient selection; add key distribution diagnostics.
2026-05-05T17:49Z group-812 B / Mac standby none / no receive source yes yes key/media-path establishment Done: same root key-distribution fix; next export should show room-key-rotate-sent or explicit skip reasons.

Next Fix Target

Current patched target:

  • Room-key distribution / media-path establishment.
  • This batch is not evidence for selector, profile strength, or baseline changes. The key symptom is that the standby never got an authoritative room key, so it never started sending and never decoded the root.
  • The next diagnostic checkpoint is explicit: if this recurs, inspect the new room-key-distribution-skipped, targeted-room-key-skipped, and room-key-rotate-sent events before touching receive policy again.

Call: 2026-05-05 18:11Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-05T18-11-27-779Z.json
  • Side B: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-05T18-11-31-300Z.json

User symptom:

  • The same no-audio symptom recurred after the key-distribution fix.

High-level verdict:

  • Bad one-way media delivery, but not the same failure as 17:49Z.
  • The key path recovered: Mac received and applied the root key, started its sender, and decoded Linux audio. Linux still received zero packets from Mac.

Not the problem:

  • Room-key distribution: Linux logged room-key-rotate-sent twice and targeted-room-key-sent once; Mac logged gcall-key-received and room-key-applied.
  • Mac sender startup: Mac had 1361 encoded frames, 1361 send attempts, and 1361 send successes.
  • Linux sender startup: Linux had 1310 encoded frames, 1310 send attempts, and 1310 send successes.
  • Decode/key mismatch on Linux: Linux had no pending-decrypt or decode drops because no Mac audio reached it at all.

Primary next target:

  • Another subsystem: one-way Reticulum packet media delivery / recovery.
  • Linux root had packetsReceived=0, no playouts, and no receive profiles while continuously sending to Mac.
  • Mac standby had packetsReceived=1379, packetsDecoded=1379, roomKeyPresent=true, and a live sender, but Linux inbound packet samples stayed zero.
  • Fix applied after this review: add an audio-surface zero-inbound watchdog. When connected with a room key and sustained outbound successes but zero inbound media, it calls requestPeerMediaRecovery(roomId, peer, 'path-degraded-warm'), which uses the existing main-process recovery path to warm the packet route and force link fallback for the peer.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QP9Jj4...i6rP none / no receive source yes 0 0 0 0 0 low-latency Sent successfully to Mac but received zero packets from Mac. No receive profile can activate without inbound media.
B standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP silent-lean yes/partly 11.926 294 0 0.005 0 low-latency Key applied and audio decoded, but playout stayed shallow/not-ready: jitterBufferedFrames=10, jitterHasReadyFrame=false.

Side A

Expected profile from symptom:

  • No receive profile; zero inbound packet delivery.

Actual exported profile:

  • None.

Did classification match?

  • Yes.

Notes:

  • This side is the fix target. It needs media-path recovery before selector/profile tuning can matter.

Side B

Expected profile from symptom:

  • silent-lean / readiness protection.

Actual exported profile:

  • silent-lean

Did classification match?

  • Yes/partly.

Notes:

  • The classification is plausible for shallow, not-ready playout with low visible damage counters.
  • This side is not the immediate fix target because it proved the key path and root-to-standby media path were alive.

Trend Read

Side A:

  • Flat zero-inbound while outbound succeeded.
  • Reasons seen:
    • reticulumAudioOutboundPacketSamples rose from 710 to 1267.
    • reticulumAudioInboundPacketSamples stayed 0.
    • packetsReceived, packetsDecoded, playouts, and profiles stayed 0 / empty.

Side B:

  • One-way receive with shallow/not-ready playout.
  • Reasons seen:
    • packetsReceived=1379, packetsDecoded=1379.
    • missingFrames rose from 174 to 294.
    • jitterHasReadyFrame=false with 10 buffered jitter frames.
    • outbound packet samples rose, but Linux still saw no inbound media.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-05T17:49Z group-812 A / Linux root none / no receive source yes yes key/media-path establishment Improved in 18:11Z: key rotate and targeted key send succeeded.
2026-05-05T17:49Z group-812 B / Mac standby none / no receive source yes yes key/media-path establishment Improved in 18:11Z: key was received/applied and sender started.
2026-05-05T18:11Z group-812 A / Linux root none / no receive source yes yes one-way packet media delivery Done: add zero-inbound media watchdog to request path-degraded-warm / link fallback.
2026-05-05T18:11Z group-812 B / Mac standby silent-lean yes/partly yes/partly readiness / secondary Watch after one-way media fix; do not tune selector first from this side.

Next Fix Target

Current patched target:

  • One-way Reticulum packet media delivery recovery.
  • The next export should show zero-inbound-media-recovery-requested on any side that is sending successfully but has no inbound media. If the fallback works, the main-process send diagnostics should move from packet-only toward link fallback for that peer.
  • Do not change baseline or receive profile strength from this call; Linux had no receive source, and Mac’s silent-lean classification was not the primary blocker.

Call: 2026-05-05 18:28Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-05T18-28-17-213Z.json
  • Side B: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-05T18-28-21-202Z.json

User symptom:

  • New paired call after the zero-inbound media recovery change; subjective symptom was not included with the export, so user-bad is inferred from receive metrics, not-ready state, and exported profiles.

High-level verdict:

  • Bad/mixed, but improved versus 18:11Z.
  • The media path is now alive in both directions: both sides received and decoded packets. The remaining failure is receive-policy application, especially on Mac, where the exported profile correctly says repair-collapse but live playout has fallen back to low-latency while reserve is almost empty.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Key/media establishment: both sides have inbound packets and decoded frames, unlike the 17:49Z and 18:11Z failures.
  • Queue/backpressure: Reticulum bridge/binary high-water values are low enough and there are no queue-pressure drops.
  • Failover: root/cluster promotion counts are 0 on both sides.
  • Baseline: this is not broad evidence that every clean call needs a larger target; one side is correctly in a heavy collapse profile and the other is a shallow weak-listener path.

Primary next target:

  • Another subsystem: profile-to-playout/adaptive-mode application.
  • Mac is correctly classified as repair-collapse (avgPcmBufferedMs=1.339, jitterBufferDepthFramesMean=0.068, missingFrames=1478, concealmentTicks=339), but adaptiveNetworkMode and lastJitterAdaptiveMode are both low-latency, and the trend exits recovery exactly as missing frames spike.
  • Do not tune selector first: the worst side selected the right family. Do not raise baseline first: the bad side is already in a heavy profile. The next fix should make repair-collapse hold/apply recovery-mode playout protection until reserve and readiness actually recover.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 steady-weak-listener partly 16.605 170 82 0.032 0.026 low-latency Classification is acceptable/partly mild for a ready but shallow weak-listener path.
B standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP repair-collapse yes 1.339 1478 339 0.039 0.038 low-latency Classification matches severe repair collapse, but the selected protection is not reflected in live playout mode.

Side A

Expected profile from symptom:

  • steady-weak-listener or persistent-lean

Actual exported profile:

  • steady-weak-listener

Did classification match?

  • Partly/yes.

Notes:

  • avgPcmBufferedMs=16.605, jitterBufferDepthFramesMean=0.843, avgPlayoutDeltaMs=-106.123, and concealmentTicks=82 are not clean.
  • jitterHasReadyFrame=true with jitterBufferedFrames=12, low decode/key errors, and modest rate pressure keep this out of buffered-not-ready or full collapse.
  • This side is secondary evidence that weak/lean paths may still be too close to low-latency, but it is not the first fix target while Mac has a correctly classified heavy profile that is not being applied.

Side B

Expected profile from symptom:

  • repair-collapse or collapse-recovery

Actual exported profile:

  • repair-collapse

Did classification match?

  • Yes.

Notes:

  • The side is nearly empty and repair-heavy: avgPcmBufferedMs=1.339, jitterBufferDepthFramesMean=0.068, avgPlayoutDeltaMs=-137.913, missingFrames=1478, and concealmentTicks=339.
  • The playout snapshot also reports jitterBufferedFrames=10 with jitterHasReadyFrame=false, so readiness is still bad.
  • The mismatch is not profile classification; it is that repair-collapse ended the export with adaptiveNetworkMode=low-latency / lastJitterAdaptiveMode=low-latency.

Trend Read

Side A:

  • Gradual weak-listener path with shallow but ready playout.
  • Reasons seen:
    • missingFrames increases from 135 to 170.
    • concealmentTicks stays flat at 82.
    • buffer improves slightly from about 16.1 to 16.6 ms.
    • playout remains ready and low-latency throughout.

Side B:

  • Discrete late collapse while recovery exits too early.
  • Reasons seen:
    • adaptive mode stays in recovery early, then switches to low-latency near the end.
    • missingFrames jumps from 271 to 1478 after the low-latency exit.
    • concealmentTicks rises early from 313 to 339, then stays flat while missing frames explode.
    • buffer remains near-empty, only moving from about 0.6 to 1.3 ms, and the final playout snapshot is not ready.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-05T17:49Z group-812 A / Linux root none / no receive source yes yes key/media-path establishment Improved by 18:11Z: key rotate and targeted key send succeeded.
2026-05-05T17:49Z group-812 B / Mac standby none / no receive source yes yes key/media-path establishment Improved by 18:11Z: key was received/applied and sender started.
2026-05-05T18:11Z group-812 A / Linux root none / no receive source yes yes one-way packet media delivery Improved by 18:28Z: Linux now receives and decodes Mac audio.
2026-05-05T18:11Z group-812 B / Mac standby silent-lean yes/partly yes/partly readiness / secondary Still relevant: Mac remains shallow/not-ready, but now classifies heavier as repair-collapse.
2026-05-05T18:28Z group-812 A / Linux root steady-weak-listener partly partly/yes weak-listener / secondary Watch after the Mac application fix; not enough to justify baseline tuning.
2026-05-05T18:28Z group-812 B / Mac standby repair-collapse yes yes profile application / adaptive-mode sync Fix repair-collapse application/hold so recovery-mode playout remains active until reserve/readiness recover.

Next Fix Target

Current patched target:

  • Profile application / adaptive-mode synchronization.
  • Primary fix: when the live source profile is repair-collapse, keep the jitter/playout adaptive mode in recovery protection and prevent a low-latency exit while reserve is near empty or jitterHasReadyFrame=false.
  • Secondary watch item: Linux’s steady-weak-listener path is still shallow, but classification is not obviously wrong. Revisit weak-listener target/floor only after the heavy-profile application mismatch is fixed.
  • Keep selector thresholds, global baseline, and profile target strength unchanged for the next patch unless code inspection shows that the only way to enforce the recovery hold is inside the repair-collapse profile configuration itself.

Call: 2026-05-05 20:21Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-05T20-21-01-644Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-05T20-20-58-248Z.json

User symptom:

  • New paired call after the profile application / adaptive-mode synchronization change; subjective symptom was not included with the export, so user-bad is inferred from receive metrics and heavy recovery profiles.

High-level verdict:

  • Bad, but improved diagnostically.
  • The previous profile-to-playout mismatch is no longer the primary failure: both sides export repair-collapse, both playout snapshots are active and ready, and both adaptiveNetworkMode / lastJitterAdaptiveMode are recovery. The remaining problem is that recovery protection is not rebuilding enough reserve, especially on Linux.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Key/media establishment: both sides have inbound packets, decoded frames, playouts, and live policy profiles.
  • Startup hidden playout nodes: both sides have active playback/scheduler nodes and jitterHasReadyFrame=true.
  • Failover: root/cluster promotion counts are 0 on both sides.
  • Selector/profile application: classification is plausible on both sides, and recovery mode is now actually applied.

Primary next target:

  • repair-collapse profile strength.
  • Per the decision rules, classification is correct and the heavy profile is active, but immediate quality is still bad: Mac stays around 2 ms buffered with 371 concealment ticks, and Linux stays around 6.7 ms buffered with 0.172 under-target and 0.161 rate-below-0.97.
  • Do not tune selector first from this call. Do not raise global baseline first. The failure is concentrated in a correctly selected heavy profile that is now being applied but is still too weak to rebuild reserve.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP repair-collapse yes 1.998 144 371 0.011 0.011 recovery Classification matches near-empty repair collapse; recovery is applied, but reserve remains pinned around 2 ms.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 repair-collapse yes 6.652 25 255 0.172 0.161 recovery Classification matches shallow reserve plus high concealment/under-target pressure; profile strength is not enough to stabilize playout.

Side A

Expected profile from symptom:

  • repair-collapse or collapse-recovery

Actual exported profile:

  • repair-collapse

Did classification match?

  • Yes.

Notes:

  • avgPcmBufferedMs=1.998, jitterBufferDepthFramesMean=0.101, avgPlayoutDeltaMs=-118.715, and concealmentTicks=371 fit the repair-collapse shape.
  • jitterHasReadyFrame=true with jitterBufferedFrames=21 means this is not the previous buffered-not-ready selector/application problem.
  • adaptiveNetworkMode=recovery and lastJitterAdaptiveMode=recovery show the profile is reaching playout mode; the remaining miss is insufficient reserve rebuilding.

Side B

Expected profile from symptom:

  • repair-collapse or collapse-recovery

Actual exported profile:

  • repair-collapse

Did classification match?

  • Yes.

Notes:

  • avgPcmBufferedMs=6.652, jitterBufferDepthFramesMean=0.338, avgPlayoutDeltaMs=-126.306, concealmentTicks=255, playoutUnderTargetFraction=0.172, and playoutRateFractionBelow097=0.161 are a strong shallow repair-collapse signature.
  • missingFrames=25 is low, but WASM PLC is doing work (wasmFecPlcFrames=95) and concealment/under-target pressure are high, so a heavy recovery profile is justified.
  • This side is the clearest evidence for strengthening repair-collapse target/floor behavior.

Trend Read

Side A:

  • Flat-bad repair-collapse path.
  • Reasons seen:
    • avgPcmBufferedMs stays pinned around 2.0 ms.
    • concealmentTicks climbs steadily from 283 to 371.
    • missingFrames increases from 109 to 144.
    • adaptive mode remains recovery throughout, so the issue is not a low-latency exit.

Side B:

  • Gradual collapse/repair degradation under active recovery.
  • Reasons seen:
    • avgPcmBufferedMs falls from about 7.5 to 5.6 ms, then ends at 6.652 ms.
    • concealmentTicks increases from 176 to 255.
    • playoutUnderTargetFraction stays high around 0.17.
    • playoutRateFractionBelow097 stays high around 0.16.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-05T17:49Z group-812 A / Linux root none / no receive source yes yes key/media-path establishment Improved by 18:11Z: key rotate and targeted key send succeeded.
2026-05-05T17:49Z group-812 B / Mac standby none / no receive source yes yes key/media-path establishment Improved by 18:11Z: key was received/applied and sender started.
2026-05-05T18:11Z group-812 A / Linux root none / no receive source yes yes one-way packet media delivery Improved by 18:28Z: Linux now receives and decodes Mac audio.
2026-05-05T18:11Z group-812 B / Mac standby silent-lean yes/partly yes/partly readiness / secondary Still relevant historically, but the new call has ready playouts on both sides.
2026-05-05T18:28Z group-812 A / Linux root steady-weak-listener partly partly/yes weak-listener / secondary Superseded by 20:21Z as the primary target; Linux now correctly classifies as heavy recovery.
2026-05-05T18:28Z group-812 B / Mac standby repair-collapse yes yes profile application / adaptive-mode sync Improved by 20:21Z: recovery mode now stays applied when repair-collapse is selected.
2026-05-05T20:21Z group-812 A / Mac standby repair-collapse yes yes profile strength Tune repair-collapse target/floor so near-empty ready playout can rebuild above the collapse band.
2026-05-05T20:21Z group-812 B / Linux root repair-collapse yes yes profile strength Same target, stronger evidence because under-target and slow-rate fractions remain high under active recovery.

Next Fix Target

Current patched target:

  • repair-collapse profile strength.
  • Primary fix: increase repair-collapse target/floor behavior, or its recovery reserve headroom, so a correctly selected and applied profile can rebuild from the 2 ms to 7 ms collapse band instead of staying near empty.
  • Keep selector thresholds unchanged from this batch: both sides classified correctly.
  • Keep global baseline unchanged for the next patch: the evidence is profile-specific, not a broad clean-call baseline problem.

Call: 2026-05-05 20:47Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-05T20-47-21-373Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-05T20-47-18-388Z.json

User symptom:

  • New paired call after the repair-collapse strength change; user reported the call was horrible.
  • Clarification after initial review: Linux could almost hear nothing from the Mac side, while Mac hearing Linux was much better.

High-level verdict:

  • Bad one-way/asymmetric media quality, with Mac-to-Linux delivery/sender targeting now the primary suspect.
  • Both sides export repair-collapse and both playouts are active/ready in recovery mode, but the user symptom is asymmetric: Linux barely hears Mac, while Mac hears Linux much better. That matches the packet imbalance better than generic profile strength: Linux received only 678 packets from Mac, while Mac received 3395 from Linux, and Mac had 571 outbound no-target skips.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Key/media establishment: both sides have inbound packets, decoded frames, playouts, and live policy profiles.
  • Startup hidden playout nodes: both sides have active playback/scheduler nodes and jitterHasReadyFrame=true.
  • Failover: root/cluster promotion counts are 0 on both sides.
  • Global baseline: Mac hearing Linux was much better and Mac is already heavily buffered, so a larger baseline would not explain the asymmetric symptom.

Primary next target:

  • Another subsystem: Mac-to-Linux media send/targeting path, with decode/session diagnostics as a secondary check.
  • The best symptom match is not Mac’s large decode-failure counter, because Mac sounded much better despite packetsDroppedDecodeFailure=776. The worse side is Linux receiving Mac: only 678 packets received, avgPcmBufferedMs=15.730, concealmentTicks=293, playoutUnderTargetFraction=0.271, and playoutRateFractionBelow097=0.253.
  • Investigate why Mac skipped 571 outbound frames for no target and why Linux received so much less media from Mac than Mac received from Linux. Keep decode-failure instrumentation too, but do not make decode alone the next target from this clarified symptom.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP repair-collapse partly/no 67.017 567 44 0.050 0.042 recovery User said this direction was much better; classification is too severe for a healthy-buffer, ready playout.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 repair-collapse yes 15.730 35 293 0.271 0.253 recovery Classification matches the bad direction: Linux barely hears Mac, with shallow reserve and heavy under-target/rate pressure.

Side A

Expected profile from symptom:

  • clean-low-latency or at most repair-heavy-connected.

Actual exported profile:

  • repair-collapse

Did classification match?

  • No.

If no:

  • avgPcmBufferedMs=67.017, jitterBufferDepthFramesMean=3.390, jitterBufferedFrames=23, and jitterHasReadyFrame=true do not fit a reserve-collapse profile.
  • The clarified symptom says this direction was much better, even with packetsDroppedDecodeFailure=776.
  • Treat this as evidence that decode failures need instrumentation, but not as the main audible blocker for this call. The profile selector is too pessimistic for Mac’s current receive state.

Side B

Expected profile from symptom:

  • repair-collapse

Actual exported profile:

  • repair-collapse

Did classification match?

  • Yes.

Notes:

  • avgPcmBufferedMs=15.730, jitterBufferDepthFramesMean=0.798, avgPlayoutDeltaMs=-125.936, concealmentTicks=293, playoutUnderTargetFraction=0.271, and playoutRateFractionBelow097=0.253 fit a horrible repair-collapse call.
  • Linux only received 678 packets from Mac, while Mac received 3395 from Linux. That asymmetry matches “Linux almost heard nothing” better than a pure receive-profile strength failure.
  • packetsDroppedDecodeFailure=66 may contribute, but it is smaller than Mac’s decode-failure count despite Linux being the much worse listener.

Trend Read

Side A:

  • Better audible direction with over-severe receive classification and decode failures flat across the sampled window.
  • Reasons seen:
    • packetsDroppedDecodeFailure is 776 in every trend sample.
    • missingFrames increases from 385 to 567.
    • avgPcmBufferedMs stays healthy around 67 to 69 ms.
    • entered-recovery appears once and adaptive mode remains recovery.

Side B:

  • Flat-bad Mac-to-Linux receive path under active recovery.
  • Reasons seen:
    • packetsDroppedDecodeFailure is 66 in every trend sample.
    • concealmentTicks increases from 257 to 293.
    • playoutUnderTargetFraction remains very high around 0.27 to 0.30.
    • playoutRateFractionBelow097 remains very high around 0.25 to 0.28.
    • Linux received far fewer packets than Mac did in the opposite direction.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-05T18:28Z group-812 A / Linux root steady-weak-listener partly partly/yes weak-listener / secondary Superseded by later calls; not the current blocker.
2026-05-05T18:28Z group-812 B / Mac standby repair-collapse yes yes profile application / adaptive-mode sync Improved by 20:21Z: recovery mode stayed applied.
2026-05-05T20:21Z group-812 A / Mac standby repair-collapse yes yes profile strength Done: raised repair-collapse target/floor and allowed collapse-level extra hold.
2026-05-05T20:21Z group-812 B / Linux root repair-collapse yes yes profile strength Done: same repair-collapse strength patch.
2026-05-05T20:47Z group-812 A / Mac standby repair-collapse partly/no no selector / secondary decode diagnostics Mac heard Linux much better; do not use this side to justify more collapse strength.
2026-05-05T20:47Z group-812 B / Linux root repair-collapse yes yes Mac-to-Linux media delivery / sender targeting Investigate Mac outbound no-target skips and the packet imbalance before more receive-profile tuning.

Next Fix Target

Current patched target:

  • Mac-to-Linux media delivery / sender targeting.
  • Primary fix: instrument and fix why Mac skipped 571 outbound frames for no target and why Linux received only 678 packets while Mac received 3395. Capture recipient roster/target availability, selected transport, path warm/fallback state, and per-peer send eligibility at each no-target skip.
  • Secondary diagnostics: keep decode/session instrumentation because both sides report decode failures, but the clarified audible symptom says decode count alone is not the primary selector for this batch.
  • Keep repair-collapse strength and global baseline unchanged for the next patch. Linux’s bad receive profile matches the symptom, but the larger asymmetry points upstream of receive policy.

Call: 2026-05-05 21:27Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-05T21-27-34-330Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-05T21-27-31-309Z.json

User symptom:

  • New paired call after the media sender/targeting diagnostics change; subjective symptom was not included with the export, so user-bad is inferred from receive metrics and correctness counters.

High-level verdict:

  • Mixed, and improved versus 20:47Z.
  • Both sides now have room keys, live senders, inbound packets, decoded frames, active playouts, ready jitter frames, and low-latency playout mode. The previous catastrophic Mac-to-Linux imbalance is reduced, but Mac now has a hard decode correctness signal while Linux still looks like a moderate weak-listener path.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Key/media establishment: both sides have roomKeyPresent=true, live mic senders, inbound packets, decoded frames, playouts, and live policy profiles.
  • Startup hidden playout nodes: both sides have active playback/scheduler nodes and jitterHasReadyFrame=true.
  • Queue/backpressure: bridge/binary high-water values are low (3/3 on Mac, 2/1 on Linux), with no queue-pressure drops.
  • Failover: root/cluster promotion counts are 0 on both sides.
  • Global baseline: Mac has a healthy 69.597 ms receive reserve, so this is not a broad low baseline problem.

Primary next target:

  • Another subsystem: decode/session correctness first, then continue watching Mac-to-Linux media delivery.
  • Mac exports packetsDroppedDecodeFailure=241 while still classifying the receive source as clean-low-latency. Per the triage rules, decode failures are a correctness/path signal and should be explained before selector, profile strength, or baseline tuning.
  • Linux's steady-weak-listener classification mostly matches its metrics (avgPcmBufferedMs=33.369, concealmentTicks=212, playoutUnderTargetFraction=0.083, playoutRateFractionBelow097=0.071), but it is not enough by itself to justify baseline or profile-strength changes while a decode failure is present on the paired side.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP clean-low-latency partly/unknown 69.597 341 0 0.024 0.000 low-latency Reserve/playout profile looks clean, but packetsDroppedDecodeFailure=241 is a correctness blocker that the receive profile does not represent.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 steady-weak-listener partly 33.369 339 212 0.083 0.071 low-latency Classification matches a moderate weak-listener/repair path; not collapse, not startup, and decode is clean on this side.

Side A

Expected profile from symptom:

  • clean-low-latency by receive reserve/playout metrics, but no receive profile can account for the decode failures.

Actual exported profile:

  • clean-low-latency

Did classification match?

  • Partly/unknown.

If no:

  • The profile matches the healthy live receive metrics: avgPcmBufferedMs=69.597, jitterBufferDepthFramesMean=3.547, jitterHasReadyFrame=true, concealmentTicks=0, and playoutRateFractionBelow097=0.
  • It does not match the correctness signal: packetsDroppedDecodeFailure=241 and packetsDropped=241.
  • Do not tune clean-low-latency; inspect decode/session/FEC failure causes and keep the new decode diagnostics active.

Side B

Expected profile from symptom:

  • steady-weak-listener

Actual exported profile:

  • steady-weak-listener

Did classification match?

  • Yes/partly.

Notes:

  • avgPcmBufferedMs=33.369, jitterBufferDepthFramesMean=1.694, avgPlayoutDeltaMs=-100.605, concealmentTicks=212, playoutUnderTargetFraction=0.083, and playoutRateFractionBelow097=0.071 fit an understandable-but-not-clean weak listener.
  • This is not a collapse profile: playout is ready with jitterBufferedFrames=12, reserve is not near empty, and decode/key counters are clean.
  • Revisit weak-listener target/floor only after decode correctness is clean in a paired call.

Trend Read

Side A:

  • Flat healthy-buffer receive path with a persistent decode-failure correctness counter.
  • Reasons seen:
    • packetsDroppedDecodeFailure is 241 in every trend sample.
    • avgPcmBufferedMs stays around 69.5 to 69.7 ms.
    • concealmentTicks stays 0.
    • missingFrames grows mildly from 303 to 341.

Side B:

  • Gradual moderate weak-listener path.
  • Reasons seen:
    • missingFrames grows from 292 to 339.
    • concealmentTicks stays flat at 212.
    • playoutUnderTargetFraction improves slightly from 0.092 to 0.083.
    • playoutRateFractionBelow097 improves from 0.081 to 0.071.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-05T20:21Z group-812 A / Mac standby repair-collapse yes yes profile strength Done: raised repair-collapse target/floor and allowed collapse-level extra hold.
2026-05-05T20:21Z group-812 B / Linux root repair-collapse yes yes profile strength Done: same repair-collapse strength patch.
2026-05-05T20:47Z group-812 A / Mac standby repair-collapse partly/no no selector / secondary decode diagnostics Improved in 21:27Z: Mac now has healthy reserve and clean-low-latency, but decode failures still need investigation.
2026-05-05T20:47Z group-812 B / Linux root repair-collapse yes yes Mac-to-Linux media delivery / sender targeting Improved in 21:27Z: Linux now receives 3512 packets, but remains steady-weak-listener.
2026-05-05T21:27Z group-812 A / Mac standby clean-low-latency partly/unknown partly/unknown decode/session correctness Investigate packetsDroppedDecodeFailure=241; do not tune receive profiles from this side.
2026-05-05T21:27Z group-812 B / Linux root steady-weak-listener partly yes/partly weak-listener / secondary Keep as evidence, but wait for a decode-clean paired call before tuning weak-listener strength or baseline.

Next Fix Target

Current patched target:

  • Decode/session correctness.
  • Primary fix: explain and instrument the Mac-side packetsDroppedDecodeFailure=241 path in a call where reserve/playout otherwise look clean. This is the strongest template triage signal in the new export.
  • Secondary watch item: Linux still has a valid steady-weak-listener receive profile with moderate under-target and concealment pressure. If the next decode-clean call still sounds weak in this shape, tune steady-weak-listener target/floor or application hold.
  • Do not change selector, repair-collapse strength, or global baseline from this batch. Classification is mostly aligned on Linux, Mac's receive profile is not the audible policy problem, and the remaining hard signal is outside receive policy.

Call: 2026-05-06 11:56Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-06T11-56-34-277Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-06T11-56-30-808Z.json

User symptom:

  • New paired call after the decode/session diagnostics change; subjective symptom was not included with the export, so user-bad is inferred from receive metrics and profile mismatch.

High-level verdict:

  • Mixed/bad, but improved versus the previous decode-blocked batch.
  • Decode correctness is clean again on both sides, both media paths are alive, and both playouts are active/ready. The remaining issue is receive classification: Linux exports clean-low-latency despite moderate under-target/missing-frame pressure, while Mac exports only persistent-lean despite a shallow, concealment-heavy path.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Key/media establishment: both sides have inbound packets, decoded frames, active playouts, and live policy profiles.
  • Startup hidden playout nodes: both sides have active playback/scheduler nodes and jitterHasReadyFrame=true.
  • Queue/backpressure: bridge/binary high-water values are low (1/2 on Mac, 7/2 on Linux), with no queue-pressure drops.
  • Failover: root/cluster promotion counts are 0 on both sides.

Primary next target:

  • Selector.
  • Linux should not remain clean-low-latency with missingFrames=608, concealmentTicks=83, playoutUnderTargetFraction=0.077, playoutRateFractionBelow097=0.053, and avgPlayoutDeltaMs=-92.208.
  • Mac's persistent-lean classification is directionally right for shallow reserve, but likely too mild for avgPcmBufferedMs=9.650, concealmentTicks=286, missingFrames=462, and avgPlayoutDeltaMs=-122.162; this should be allowed to escalate toward a repair profile when concealment is active.
  • Do not tune baseline first: both sides are not clean, but the exported profiles do not yet match the symptoms. Do not tune profile strength first: at least one side is not entering a protective profile at all.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP persistent-lean yes 9.650 462 286 0.052 0.046 low-latency Classification partly matches shallow reserve, but is too mild for active concealment and a strongly negative delta.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 clean-low-latency partly/yes 42.823 608 83 0.077 0.053 low-latency Classification is too optimistic: reserve is usable, but under-target, rate, missing-frame, and concealment pressure are not clean.

Side A

Expected profile from symptom:

  • repair-collapse or repair-heavy-connected, with persistent-lean as the weaker fallback.

Actual exported profile:

  • persistent-lean

Did classification match?

  • Partly/no.

If no:

  • avgPcmBufferedMs=9.650, jitterBufferDepthFramesMean=0.489, and avgPlayoutDeltaMs=-122.162 match a persistent shallow-listener shape.
  • But concealmentTicks=286, missingFrames=462, playoutUnderTargetFraction=0.052, and playoutRateFractionBelow097=0.046 make this more repair-heavy than ordinary lean.
  • Retune selector escalation from persistent-lean when shallow reserve and active concealment coexist; do not only raise the persistent-lean target yet.

Side B

Expected profile from symptom:

  • steady-weak-listener or repair-heavy-connected.

Actual exported profile:

  • clean-low-latency

Did classification match?

  • No/partly.

If no:

  • avgPcmBufferedMs=42.823, jitterBufferDepthFramesMean=2.170, jitterBufferedFrames=9, and jitterHasReadyFrame=true explain why this avoided collapse/not-ready profiles.
  • But the side is not clean: missingFrames=608, concealmentTicks=83, playoutUnderTargetFraction=0.077, playoutRateFractionBelow097=0.053, and avgPlayoutDeltaMs=-92.208.
  • Tighten the clean escape/clear conditions so ready buffered paths with sustained damage land in steady-weak-listener or repair-heavy-connected.

Trend Read

Side A:

  • Gradual shallow repair/lean path with early recovery exit.
  • Reasons seen:
    • avgPcmBufferedMs improves only from about 7.5 to 9.65 ms, still shallow.
    • missingFrames increases from 332 to 462.
    • concealmentTicks stays high at 286.
    • adaptive mode exits recovery to low-latency halfway through while the profile remains persistent-lean.

Side B:

  • Gradual moderate weak/repair pressure with early recovery exit.
  • Reasons seen:
    • avgPcmBufferedMs improves from about 39.7 to 42.8 ms.
    • missingFrames increases from 507 to 608.
    • concealmentTicks stays at 83.
    • adaptive mode exits recovery to low-latency while under-target and rate-below-0.97 pressure remain elevated.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-05T20:47Z group-812 A / Mac standby repair-collapse partly/no no selector / secondary decode diagnostics Improved by 21:27Z and 11:56Z: Mac receive reserve recovered from the over-severe collapse classification, and decode failures are gone.
2026-05-05T20:47Z group-812 B / Linux root repair-collapse yes yes Mac-to-Linux media delivery / sender targeting Improved by 21:27Z and 11:56Z: Linux now receives thousands of packets, but classification is now too optimistic.
2026-05-05T21:27Z group-812 A / Mac standby clean-low-latency partly/unknown partly/unknown decode/session correctness Improved in 11:56Z: decode failures are now 0, so decode/session is no longer the next target.
2026-05-05T21:27Z group-812 B / Linux root steady-weak-listener partly yes/partly weak-listener / secondary Still relevant, but 11:56Z regressed to clean-low-latency under similar moderate pressure.
2026-05-06T11:56Z group-812 A / Mac standby persistent-lean yes partly/no selector / repair escalation Escalate shallow active-concealment paths out of ordinary persistent-lean toward repair-heavy/collapse protection.
2026-05-06T11:56Z group-812 B / Linux root clean-low-latency partly/yes no/partly selector / clean escape Tighten clean-low-latency clear/entry so sustained missing-frame, concealment, under-target, and slow-rate pressure cannot remain clean.

Next Fix Target

Current patched target:

  • Selector.
  • Primary fix: make sustained damage counters and under-target/rate pressure disqualify clean-low-latency, even when the ready buffer is not collapsed.
  • Secondary fix: let persistent-lean escalate when shallow reserve is accompanied by meaningful concealment and missing-frame growth.
  • Keep decode/session, media-path, global baseline, and heavy-profile strength unchanged for the next patch. This export is clean on correctness and media establishment; the active failure is that profile classification is too mild for the symptoms.

Call: 2026-05-06 12:19Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-06T12-19-09-566Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-06T12-19-06-336Z.json

User symptom:

  • New paired call after the sustained-damage selector change; subjective symptom was not included with the export, so user-bad is inferred from receive metrics, packet imbalance, and exported profiles.

High-level verdict:

  • Bad/mixed, but selector classification improved versus 11:56Z.
  • The previous selector miss is mostly gone: Mac now exports steady-weak-listener instead of a clean/misleading profile, and Linux exports collapse-recovery for a truly shallow/not-ready path. The remaining blocker is asymmetric media delivery into Linux: Linux received only 330 packets from Mac while Mac received 2060 packets from Linux.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Key/media establishment in the broad sense: both sides have inbound packets, decoded frames, active playouts, and live policy profiles.
  • Startup hidden playout nodes: both sides have active playback/scheduler nodes.
  • Queue/backpressure: bridge/binary high-water values are low (2/1 on Mac, 7/0 on Linux), with no queue-pressure drops.
  • Failover: root/cluster promotion counts are 0 on both sides, although Mac trend advances from topology epoch 3 to 4 at the end.

Primary next target:

  • Another subsystem: Mac-to-Linux media delivery / packet-route reliability.
  • Linux classification is correct and recovery is applied, but it is starving on very little inbound media: packetsReceived=330, avgPcmBufferedMs=4.771, jitterHasReadyFrame=false, concealmentTicks=239, playoutUnderTargetFraction=0.145, and playoutRateFractionBelow097=0.136.
  • Mac sent successfully with outboundSendFailures=0 and outboundNoTargetSkips=0, yet Linux received far fewer packets than Mac received in the opposite direction. That points upstream of receive profile strength.
  • Do not tune baseline from this call. Do not raise collapse-recovery strength first; the bad side has an upstream delivery imbalance and not-ready playout.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP steady-weak-listener partly 32.155 309 3 0.015 0.003 low-latency Classification is acceptable: ready playout, moderate reserve, sustained missing-frame growth, but low concealment/under-target pressure.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 collapse-recovery yes 4.771 38 239 0.145 0.136 recovery Classification matches severe collapse/not-ready symptoms, but the packet imbalance points upstream of profile tuning.

Side A

Expected profile from symptom:

  • steady-weak-listener

Actual exported profile:

  • steady-weak-listener

Did classification match?

  • Yes/partly.

Notes:

  • This side matches the new selector intent: missingFrames=309 prevents a clean profile, while avgPcmBufferedMs=32.155, jitterHasReadyFrame=true, concealmentTicks=3, and playoutRateFractionBelow097=0.003 keep it out of heavy repair/collapse.
  • It is not clean, but it is not the primary blocker in this call.

Side B

Expected profile from symptom:

  • collapse-recovery or repair-collapse

Actual exported profile:

  • collapse-recovery

Did classification match?

  • Yes.

Notes:

  • The side is shallow and not ready: avgPcmBufferedMs=4.771, jitterBufferDepthFramesMean=0.242, jitterBufferedFrames=9, jitterHasReadyFrame=false, and avgPlayoutDeltaMs=-126.022.
  • concealmentTicks=239, playoutUnderTargetFraction=0.145, and playoutRateFractionBelow097=0.136 justify the severe profile.
  • But Linux only received 330 packets from Mac, while Mac received 2060 from Linux. Treat that delivery asymmetry as the next root-cause target before profile strength.

Trend Read

Side A:

  • Gradual moderate weak-listener path.
  • Reasons seen:
    • missingFrames increases from 232 to 309.
    • concealmentTicks stays low at 3.
    • avgPcmBufferedMs improves from about 29.6 to 32.2 ms.
    • adaptive mode remains low-latency, with exported profile steady-weak-listener.

Side B:

  • Flat-bad/degrading collapse path under active recovery.
  • Reasons seen:
    • avgPcmBufferedMs falls from 6.790 to 4.771 ms.
    • concealmentTicks climbs steadily from 151 to 239.
    • playoutUnderTargetFraction rises from 0.136 to 0.145.
    • playoutRateFractionBelow097 rises from 0.123 to 0.136.
    • final playout is not ready despite 9 buffered jitter frames.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-05T21:27Z group-812 A / Mac standby clean-low-latency partly/unknown partly/unknown decode/session correctness Improved by 11:56Z and 12:19Z: decode failures are now 0.
2026-05-05T21:27Z group-812 B / Linux root steady-weak-listener partly yes/partly weak-listener / secondary Still relevant historically, but not the current blocker.
2026-05-06T11:56Z group-812 A / Mac standby persistent-lean yes partly/no selector / repair escalation Improved in 12:19Z: analogous Mac side is now steady-weak-listener, not persistent lean.
2026-05-06T11:56Z group-812 B / Linux root clean-low-latency partly/yes no/partly selector / clean escape Improved in 12:19Z: Linux no longer stays clean under damage; it now selects collapse-recovery.
2026-05-06T12:19Z group-812 A / Mac standby steady-weak-listener partly yes/partly weak-listener / secondary Keep as acceptable selector result; do not tune first.
2026-05-06T12:19Z group-812 B / Linux root collapse-recovery yes yes Mac-to-Linux media delivery / not-ready collapse Investigate packet-route/delivery asymmetry before tuning collapse-recovery strength.

Next Fix Target

Current patched target:

  • Another subsystem: Mac-to-Linux media delivery / packet-route reliability.
  • Primary fix: instrument and recover the path where Mac reports successful outbound sends, but Linux receives a much smaller packet count and collapses into not-ready recovery.
  • Secondary watch item: if the next call has balanced inbound packet counts and Linux still stays near empty while correctly classified as collapse-recovery, then tune collapse-recovery or repair-collapse strength/hold.
  • Keep selector, baseline, decode/session, and global profile strength unchanged for the next patch. This batch says the selector fix worked; the remaining bad side is correctly classified but underfed.

Call: 2026-05-06 12:34Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-06T12-34-56-851Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-06T12-34-53-905Z.json

User symptom:

  • New paired call after the media delivery / packet-route reliability change; subjective symptom was not included with the export, so user-bad is inferred from receive metrics, packet imbalance, readiness state, and exported profiles.

High-level verdict:

  • Bad/mixed.
  • Correctness remains clean and both sides receive/decode audio, but the call is still not diagnostically clean: Mac is shallow and not-ready while classified too mildly as steady-weak-listener, and Linux is ready with usable reserve while classified too severely as collapse-recovery. The packet imbalance also flipped direction versus 12:19Z: Mac received only 688 packets from Linux while Linux received 2208 packets from Mac.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Key/media establishment in the broad sense: both sides have inbound packets, decoded frames, active playouts, and live policy profiles.
  • Startup hidden playout nodes: both sides have active playback/scheduler nodes.
  • Queue/backpressure: bridge/binary high-water values are low (1/2 on Mac, 2/0 on Linux), with no queue-pressure drops.
  • Failover: root/cluster promotion counts are 0 on both sides.

Primary next target:

  • Selector / readiness priority, with packet-route asymmetry as a secondary subsystem watch.
  • Mac should not stay ordinary steady-weak-listener with avgPcmBufferedMs=10.134, jitterBufferedFrames=9, jitterHasReadyFrame=false, concealmentTicks=123, and playoutUnderTargetFraction=0.063; this should enter a readiness/lean protection profile such as buffered-not-ready or silent-lean.
  • Linux should not stay collapse-recovery with avgPcmBufferedMs=30.995, jitterBufferedFrames=20, jitterHasReadyFrame=true, low/moderate concealment, and live mode already back to low-latency; this fits steady-weak-listener or repair-heavy-connected better than full collapse.
  • Do not tune profile strength or baseline from this call. The exported profiles do not match the symptoms, so selector priority/escape logic comes before target/floor changes. Keep watching the flipped packet imbalance because Mac is the underfed side in this export.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP steady-weak-listener yes 10.134 86 123 0.063 0.058 low-latency Classification is too mild: playout is shallow and not-ready with active concealment, yet mode/profile remain weak/low-latency.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 collapse-recovery partly 30.995 219 57 0.076 0.059 low-latency Classification is too severe: playout is ready with 20 buffered frames and usable reserve, so this should clear toward weak/repair, not full collapse.

Side A

Expected profile from symptom:

  • buffered-not-ready or silent-lean, possibly repair-collapse if active concealment is weighted heavily.

Actual exported profile:

  • steady-weak-listener

Did classification match?

  • No/partly.

If no:

  • avgPcmBufferedMs=10.134, jitterBufferDepthFramesMean=0.513, avgPlayoutDeltaMs=-116.729, and jitterHasReadyFrame=false with 9 buffered jitter frames are a readiness/lean failure shape.
  • concealmentTicks=123, playoutUnderTargetFraction=0.063, and playoutRateFractionBelow097=0.058 make the side more damaged than an ordinary weak listener.
  • The selector should promote this into readiness/lean protection and keep recovery mode applied until ready/reserve recovers.

Side B

Expected profile from symptom:

  • steady-weak-listener or repair-heavy-connected.

Actual exported profile:

  • collapse-recovery

Did classification match?

  • No/partly.

If no:

  • avgPcmBufferedMs=30.995, jitterBufferDepthFramesMean=1.573, jitterBufferedFrames=20, and jitterHasReadyFrame=true do not fit reserve collapse.
  • The damage counters are real but moderate: missingFrames=219, concealmentTicks=57, playoutUnderTargetFraction=0.076, and playoutRateFractionBelow097=0.059.
  • Tighten the ready-buffered escape from collapse-recovery so this shape lands in weak/repair recovery instead of the strongest collapse profile.

Trend Read

Side A:

  • Gradual shallow/not-ready path with recovery exiting too early.
  • Reasons seen:
    • avgPcmBufferedMs improves from about 2.7 to 10.1 ms, but remains shallow.
    • concealmentTicks stays high at 123.
    • missingFrames grows from 25 to 86.
    • adaptive mode exits recovery to low-latency while final playout is still not ready.

Side B:

  • Gradual moderate weak/repair pressure with an over-severe exported profile.
  • Reasons seen:
    • avgPcmBufferedMs improves from about 27.7 to 31.0 ms.
    • missingFrames grows from 135 to 219.
    • concealmentTicks stays flat at 57.
    • adaptive mode exits recovery to low-latency, and final playout is ready with 20 buffered jitter frames.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-06T11:56Z group-812 A / Mac standby persistent-lean yes partly/no selector / repair escalation Improved in 12:19Z, but 12:34Z shows Mac still needs readiness/lean promotion when not-ready.
2026-05-06T11:56Z group-812 B / Linux root clean-low-latency partly/yes no/partly selector / clean escape Improved in later calls: Linux no longer stays clean under damage, but 12:34Z over-corrects to collapse.
2026-05-06T12:19Z group-812 A / Mac standby steady-weak-listener partly yes/partly weak-listener / secondary Still acceptable for ready/moderate pressure, but 12:34Z is not-ready and needs a stronger readiness profile.
2026-05-06T12:19Z group-812 B / Linux root collapse-recovery yes yes Mac-to-Linux media delivery / not-ready collapse The severe profile was correct there; 12:34Z has the opposite ready-buffered shape and should escape collapse.
2026-05-06T12:34Z group-812 A / Mac standby steady-weak-listener yes no/partly selector / readiness priority Promote shallow buffered-not-ready state into buffered-not-ready / silent-lean and prevent low-latency exit while not ready.
2026-05-06T12:34Z group-812 B / Linux root collapse-recovery partly no/partly selector / collapse escape Tighten ready-buffered low/moderate-concealment escape from collapse-recovery into weak/repair.

Next Fix Target

Current patched target:

  • Selector / readiness priority.
  • Primary fix: make not-ready shallow playout win over ordinary steady-weak-listener, especially when jitterHasReadyFrame=false with buffered jitter frames and active concealment.
  • Secondary fix: make ready-buffered moderate-damage playout escape collapse-recovery into steady-weak-listener or repair-heavy-connected.
  • Keep baseline and profile strength unchanged for the next patch. The classification is wrong/partly wrong on both sides, and the remaining packet imbalance is a watch item rather than enough evidence for another media-path-only patch.

Call: 2026-05-06 12:50Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-06T12-50-22-139Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-06T12-50-18-689Z.json

User symptom:

  • New paired call after the link-lifecycle / heartbeat-liveness changes; subjective symptom was not included with the export, so user-bad is inferred from receive metrics, packet imbalance, and exported profiles.

High-level verdict:

  • Bad/asymmetric.
  • Correctness and queue paths are clean, and selector behavior is mostly defensible. The bad side is Mac receiving Linux/root: Mac is correctly in repair-collapse, has tiny reserve, and only received 420 packets while Linux/root reports 2681 successful sends toward Mac. Linux/root receiving Mac is much healthier and exports clean-low-latency.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Key/state: both sides are connected, have topology epoch 2, participant count 2, active room keys, and awaitingAuthoritativeKey=false.
  • Startup hidden playout nodes: both sides have active playback/scheduler nodes, jitterHasReadyFrame=true, and running audio contexts.
  • Queue/backpressure: bridge/binary high-water values are low (1/0 on Mac, 2/1 on Linux), with no queue-pressure drops.
  • Failover: root/cluster promotion counts are 0 on both sides.

Primary next target:

  • Another subsystem: Linux/root-to-Mac media delivery after packet/link fallback.
  • The selector is not the first target: Mac is correctly classified as repair-collapse, and Linux is plausibly clean/low-latency despite missing-frame growth because reserve and concealment are low-risk.
  • The root problem is that Linux reports clean outbound success (sendSuccesses=2681, sendFailures=0, skippedNoTargets=0, lastMainDiagnostics.transport=link, linkFallbackActive=true), while Mac only receives 420 packets and repeatedly requests low-inbound media recovery with inbound/outbound ratios around 0.14 to 0.22.
  • Next patch should instrument and fix the main/Reticulum delivery path where link-fallback enqueue succeeds locally but the peer receives too little audio.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP repair-collapse yes 3.579 19 276 0.095 0.090 recovery Classification matches: tiny reserve, active concealment, under-target pressure, and recovery mode. The upstream signal is low inbound from Linux/root.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 clean-low-latency no/partly 54.329 399 18 0.031 0.018 low-latency Classification is acceptable/partly optimistic: missing-frame count is high, but reserve is strong and concealment/under-target pressure are low.

Side A

Expected profile from symptom:

  • repair-collapse or collapse-recovery

Actual exported profile:

  • repair-collapse

Did classification match?

  • Yes.

Notes:

  • avgPcmBufferedMs=3.579, jitterBufferDepthFramesMean=0.182, avgPlayoutDeltaMs=-138.067, concealmentTicks=276, playoutUnderTargetFraction=0.095, and playoutRateFractionBelow097=0.090 fit a severe repair/collapse listener.
  • The playout itself is not hidden: jitterBufferedFrames=22, jitterHasReadyFrame=true, playbackNodeActive=true, and schedulerNodeActive=true.
  • Mac repeatedly emits low-inbound-media-recovery-requested; packet count stalls around 286 for much of the sampled window and ends at only 420.

Side B

Expected profile from symptom:

  • clean-low-latency or steady-weak-listener

Actual exported profile:

  • clean-low-latency

Did classification match?

  • Yes/partly.

If no:

  • The only suspicious signal is sustained missingFrames=399.
  • But the side has avgPcmBufferedMs=54.329, jitterBufferedFrames=11, jitterHasReadyFrame=true, concealmentTicks=18, playoutUnderTargetFraction=0.031, and playoutRateFractionBelow097=0.018.
  • This is not the first profile to tune from this call; at most, keep watching whether high missing-frame counts with strong reserve should select steady-weak-listener.

Trend Read

Side A:

  • Flat-bad/degrading receive starvation.
  • Reasons seen:
    • avgPcmBufferedMs falls from about 3.19 to 2.55 ms, then only recovers to 3.58 ms.
    • concealmentTicks climbs from 207 to 276.
    • playoutUnderTargetFraction stays near 0.095 to 0.100.
    • repeated low-inbound-media-recovery-requested events show inbound/outbound ratio around 0.14 to 0.22.

Side B:

  • Mostly buffered/usable with moderate missing-frame growth.
  • Reasons seen:
    • avgPcmBufferedMs stays strong around 54 to 56 ms.
    • missingFrames grows from 311 to 399.
    • concealmentTicks stays low at 18.
    • adaptive mode briefly enters recovery and returns to low-latency.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-06T12:19Z group-812 A / Mac standby steady-weak-listener partly yes/partly weak-listener / secondary Still acceptable for ready/moderate pressure; not the current blocker.
2026-05-06T12:19Z group-812 B / Linux root collapse-recovery yes yes Mac-to-Linux media delivery / not-ready collapse Packet imbalance made this an upstream delivery case, not profile strength.
2026-05-06T12:34Z group-812 A / Mac standby steady-weak-listener yes no/partly selector / readiness priority Improved in 12:50Z: Mac now selects severe repair/collapse when it is truly shallow and damaged.
2026-05-06T12:34Z group-812 B / Linux root collapse-recovery partly no/partly selector / collapse escape Improved in 12:50Z: analogous Linux side now clears to clean-low-latency with ready buffer and low concealment.
2026-05-06T12:50Z group-812 A / Mac standby repair-collapse yes yes Linux-to-Mac media delivery / receive starvation Instrument/fix link-fallback delivery where Linux reports successful outbound sends but Mac receives too little.
2026-05-06T12:50Z group-812 B / Linux root clean-low-latency no/partly yes/partly secondary missing-frame watch No profile-strength change first; only watch high missing-frame counts under strong reserve.

Next Fix Target

Current patched target:

  • Another subsystem: Linux/root-to-Mac media delivery during packet/link fallback.
  • Primary fix: add delivery diagnostics around the successful enqueue path, link fallback dwell/probe exits, and peer receive evidence so we can distinguish “queued to bridge” from “arrived at peer”.
  • Secondary fix candidate: if diagnostics show link fallback is selected but not delivering, prefer packet path or reopen/reselect the canonical link faster for that peer.
  • Keep selector, profile strength, and baseline unchanged for the next patch. In this call, classification mostly matches the symptoms; the bad side is correctly classified but underfed.

Call: 2026-05-06 14:30Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-06T14-30-36-970Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-06T14-30-34-292Z.json

User symptom:

  • New paired call after the latest media delivery / link-fallback changes; subjective symptom was not included with the export, so user-bad is inferred from receive metrics, readiness state, and exported profiles.

High-level verdict:

  • Mixed/bad, but improved versus 12:50Z delivery starvation.
  • Both directions now have inbound packets, decoded frames, live profiles, and active playouts. Correctness and queue paths are clean. The remaining failures are receive-side: Mac is correctly classified as silent-lean but the final playout mode has fallen back to low-latency while still not ready, and Linux is over-classified as repair-collapse despite usable reserve and a ready playout.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Key/media establishment in the broad sense: both sides have inbound packets, decoded frames, active playouts, and live policy profiles.
  • Queue/backpressure: bridge/binary high-water values are low (2/1 on Mac, 4/1 on Linux), with no queue-pressure drops.
  • Failover: root/cluster promotion counts are 0 on both sides.
  • Baseline: this is not evidence for a global target increase; the profiles/modes are not aligned enough to tune baseline first.

Primary next target:

  • Another subsystem: profile-to-playout / adaptive-mode application, with selector cleanup as the secondary target.
  • Mac is the clearest bad-side signal: silent-lean matches avgPcmBufferedMs=6.573, jitterBufferedFrames=10, jitterHasReadyFrame=false, and avgPlayoutDeltaMs=-128.184, but both exported live mode and final jitter mode are low-latency. A correctly selected lean/not-ready profile is not holding recovery-mode protection.
  • Linux should also not be repair-collapse with avgPcmBufferedMs=39.408, jitterBufferedFrames=21, jitterHasReadyFrame=true, and only moderate concealment. That is a selector/escape issue, but it is secondary to the Mac application mismatch because the worst-looking side selected the right profile family and then exited protection.
  • Do not tune profile strength first. Do not tune baseline first. This call says the next fix is to make selected protective profiles actually drive/hold the playout mode, then tighten the ready-buffered escape from repair-collapse.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP silent-lean yes 6.573 235 68 0.015 0.011 low-latency Classification matches the tiny-reserve not-ready shape, but protection is not applied/held: final playout has 10 buffered jitter frames, no ready frame, and low-latency mode.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 repair-collapse partly 39.408 185 55 0.087 0.077 recovery Classification is too severe for a ready, usable-reserve path; this fits steady-weak-listener or repair-heavy-connected better than collapse.

Side A

Expected profile from symptom:

  • silent-lean or buffered-not-ready

Actual exported profile:

  • silent-lean

Did classification match?

  • Yes for profile family, no/partly for applied playout behavior.

Notes:

  • avgPcmBufferedMs=6.573, jitterBufferDepthFramesMean=0.333, avgPlayoutDeltaMs=-128.184, and jitterHasReadyFrame=false with 10 buffered jitter frames match the silent-lean/readiness blind spot.
  • Damage counters are present but not explosive: missingFrames=235, concealmentTicks=68, playoutUnderTargetFraction=0.015, and playoutRateFractionBelow097=0.011.
  • The bad part is that the trend exits from recovery to low-latency at the end while the final playout snapshot is still not ready. That points at profile application/hold, not profile strength.

Side B

Expected profile from symptom:

  • steady-weak-listener or repair-heavy-connected

Actual exported profile:

  • repair-collapse

Did classification match?

  • No/partly.

If no:

  • avgPcmBufferedMs=39.408, jitterBufferDepthFramesMean=1.996, jitterBufferedFrames=21, and jitterHasReadyFrame=true do not fit a reserve-collapse profile.
  • The side is still not clean: playoutUnderTargetFraction=0.087, playoutRateFractionBelow097=0.077, avgPlayoutDeltaMs=-94.443, missingFrames=185, and concealmentTicks=55.
  • Tighten the ready-buffered escape from repair-collapse into weak/repair recovery, but do that after fixing the selected-profile-to-mode mismatch on Mac.

Trend Read

Side A:

  • Gradual shallow/not-ready path with recovery exiting too early.
  • Reasons seen:
    • avgPcmBufferedMs improves only from about 6.16 to 6.57 ms, still very shallow.
    • missingFrames increases from 204 to 235.
    • concealmentTicks stays at 68.
    • adaptive mode switches from recovery to low-latency in the final sample while jitterHasReadyFrame=false.

Side B:

  • Gradual moderate weak/repair pressure under recovery, with over-severe collapse classification.
  • Reasons seen:
    • avgPcmBufferedMs improves from about 38.26 to 39.41 ms.
    • missingFrames increases from 154 to 185.
    • concealmentTicks stays at 55.
    • playoutUnderTargetFraction and playoutRateFractionBelow097 improve but remain elevated around 0.087 / 0.077.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-06T12:19Z group-812 A / Mac standby steady-weak-listener partly yes/partly weak-listener / secondary Still acceptable for ready/moderate pressure; not the current blocker.
2026-05-06T12:19Z group-812 B / Linux root collapse-recovery yes yes Mac-to-Linux media delivery / not-ready collapse Packet imbalance made this an upstream delivery case; later calls show both directions alive again.
2026-05-06T12:34Z group-812 A / Mac standby steady-weak-listener yes no/partly selector / readiness priority Improved in 14:30Z: analogous Mac side now selects silent-lean, but mode still exits recovery too early.
2026-05-06T12:34Z group-812 B / Linux root collapse-recovery partly no/partly selector / collapse escape Still relevant: 14:30Z again over-classifies a ready buffered Linux side, now as repair-collapse.
2026-05-06T12:50Z group-812 A / Mac standby repair-collapse yes yes Linux-to-Mac media delivery / receive starvation Improved in 14:30Z: Mac received/decoded 1443 packets and the failure is no longer zero/low inbound delivery.
2026-05-06T12:50Z group-812 B / Linux root clean-low-latency no/partly yes/partly secondary missing-frame watch Superseded by 14:30Z: Linux now has moderate pressure but is over-classified as repair-collapse.
2026-05-06T14:30Z group-812 A / Mac standby silent-lean yes yes/partly profile application / adaptive-mode hold Make silent-lean / not-ready protection keep recovery mode until ready/reserve recovers; do not let final mode fall to low-latency.
2026-05-06T14:30Z group-812 B / Linux root repair-collapse partly no/partly selector / repair-collapse escape Tighten ready-buffered escape so this lands in steady-weak-listener or repair-heavy-connected, not collapse.

Next Fix Target

Current patched target:

  • Profile-to-playout / adaptive-mode application first; selector cleanup second.
  • Primary fix: when a live source profile is silent-lean or another not-ready lean protection profile, keep jitter/playout in recovery protection while jitterHasReadyFrame=false or reserve remains in the collapse band. The Mac side selected the right profile family but still ended in low-latency.
  • Secondary fix: tighten the ready-buffered escape from repair-collapse for Linux-style paths with jitterHasReadyFrame=true, many buffered frames, usable reserve, and only moderate concealment.
  • Keep baseline and profile strength unchanged for the next patch. The issue is not that a correctly applied profile is too weak; it is that one correctly selected profile is not being applied/held, and the other side is over-selected into a collapse profile.

Call: 2026-05-06 18:39Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-06T18-39-13-366Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-06T18-39-09-213Z.json

User symptom:

  • New paired call after the latest changes; subjective symptom was not included with the export, so user-bad is inferred from receive metrics, packet imbalance, readiness state, and exported profiles.

High-level verdict:

  • Bad/asymmetric.
  • The worst side is Linux/root receiving Mac: it is correctly classified as repair-collapse, recovery mode is applied, but it only received 617 packets while Mac/standby received 6632 packets from Linux. Linux is not-ready for most of the sampled window and shows extreme under-target/slow-rate pressure.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Key/media establishment in the broad sense: both sides have inbound packets, decoded frames, active playouts, and live policy profiles.
  • Startup hidden playout nodes: both sides have active playback/scheduler nodes, although both final playout snapshots report buffered frames with jitterHasReadyFrame=false.
  • Failover: root/cluster promotion counts are 0 on both sides.
  • Baseline: Mac has a moderate 32.241 ms receive reserve and Linux is already in a heavy recovery profile, so this is not broad evidence for raising the global baseline.

Primary next target:

  • Another subsystem: Mac-to-Linux media delivery / packet-route reliability, with decode/session diagnostics as a secondary check.
  • Linux/root is the bad side and the receive profile matches the symptom: repair-collapse, concealmentTicks=390, playoutUnderTargetFraction=0.867, playoutRateFractionBelow097=0.843, avgPlayoutDeltaMs=-153.297, and jitterHasReadyFrame=false with 11 buffered jitter frames.
  • The profile is selected and recovery mode is applied, but Linux is underfed: its trend only grows from 527 to 617 received packets over the sampled window, while Mac received thousands of packets from Linux. That points upstream of profile tuning.
  • Linux also has packetsDroppedDecodeFailure=5, so keep decode/session instrumentation active, but the larger symptom match is receive starvation from Mac to Linux.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP steady-weak-listener partly 32.241 326 2 0.048 0.005 low-latency Classification is acceptable/mildly suspicious: reserve is usable and concealment is tiny, but final playout is not ready with 9 buffered jitter frames and missing frames keep growing.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 repair-collapse yes 30.508 95 390 0.867 0.843 recovery Classification matches the bad symptom: not-ready playout, heavy concealment, severe under-target and slow-rate pressure. The upstream issue is very low Mac-to-Linux packet arrival.

Side A

Expected profile from symptom:

  • steady-weak-listener or buffered-not-ready if the final not-ready state is persistent.

Actual exported profile:

  • steady-weak-listener

Did classification match?

  • Partly.

Notes:

  • avgPcmBufferedMs=32.241, jitterBufferDepthFramesMean=1.633, concealmentTicks=2, and playoutRateFractionBelow097=0.005 are not a collapse profile.
  • The suspicious part is readiness: final playout has jitterBufferedFrames=9 with jitterHasReadyFrame=false, while missingFrames grows from 243 to 326.
  • This is not the first fix target because this side receives plenty of Linux audio and has low audible damage counters compared with Linux.

Side B

Expected profile from symptom:

  • repair-collapse or collapse-recovery

Actual exported profile:

  • repair-collapse

Did classification match?

  • Yes.

Notes:

  • The bad profile matches the exported symptom: concealmentTicks=390, playoutUnderTargetFraction=0.867, playoutRateFractionBelow097=0.843, jitterNotReadyFraction=0.867, and final jitterHasReadyFrame=false.
  • avgPcmBufferedMs=30.508 is not near-empty, but the readiness and playout-rate counters dominate; this is a not-ready repair/collapse receive path.
  • Do not tune selector or heavy-profile strength first from this side because the classifier and applied mode are already protective. The bigger failure is that Linux receives far too little Mac audio.

Trend Read

Side A:

  • Gradual moderate weak-listener path with one recovery entry and a final not-ready playout snapshot.
  • Reasons seen:
    • entered-recovery appears once.
    • missingFrames increases from 243 to 326.
    • concealmentTicks stays low at 1 to 2.
    • avgPcmBufferedMs stays around 31 to 32 ms.

Side B:

  • Flat-bad/degrading not-ready repair-collapse path under active recovery.
  • Reasons seen:
    • concealmentTicks climbs from 315 to 390.
    • playoutUnderTargetFraction stays extreme around 0.856 to 0.877.
    • playoutRateFractionBelow097 stays extreme around 0.831 to 0.857.
    • packetsReceived only increases from 527 to 617, showing sustained Mac-to-Linux under-delivery.
    • packetsDroppedDecodeFailure=5 persists across the trend and should stay instrumented.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-06T12:50Z group-812 A / Mac standby repair-collapse yes yes Linux-to-Mac media delivery / receive starvation Improved in later calls: both directions now receive/decode, but asymmetry can still flip sides.
2026-05-06T12:50Z group-812 B / Linux root clean-low-latency no/partly yes/partly secondary missing-frame watch Still secondary; not the current blocker.
2026-05-06T14:30Z group-812 A / Mac standby silent-lean yes yes/partly profile application / adaptive-mode hold Improved for the new worst side: Linux has recovery mode applied when classified heavy.
2026-05-06T14:30Z group-812 B / Linux root repair-collapse partly no/partly selector / repair-collapse escape Not the current Linux shape; 18:39Z Linux is legitimately bad and correctly heavy.
2026-05-06T18:39Z group-812 A / Mac standby steady-weak-listener partly partly readiness / secondary Watch final buffered-not-ready state, but do not tune first from this side.
2026-05-06T18:39Z group-812 B / Linux root repair-collapse yes yes Mac-to-Linux media delivery / decode watch Investigate why Linux receives very little Mac audio despite active media; keep packetsDroppedDecodeFailure=5 diagnostics active.

Next Fix Target

Current patched target:

  • Another subsystem: Mac-to-Linux media delivery / packet-route reliability.
  • Primary fix: instrument and recover the direction where Mac appears to be sending but Linux receives only a small packet count and remains not-ready under an already-correct heavy profile.
  • Secondary watch item: explain Linux packetsDroppedDecodeFailure=5, but do not make decode the only target unless the packet delivery imbalance is resolved and decode failures remain.
  • Keep selector, profile strength, and baseline unchanged for the next patch. Classification matched the bad Linux symptom, and recovery mode was applied; the missing piece is enough inbound media reaching that receiver.

Follow-up Correction: 2026-05-06 18:39Z

After re-checking the transport logic, the stronger next target is narrower:

  • Sender-side fallback exit / link-fallback request-window handling.
  • The earlier route/identity replay theory is not the best match. Linux did receive some Mac audio over the established link, so the route was not simply missing.
  • The important asymmetry is that Mac exited link fallback after a short local packet-path probe dwell even though Linux still reported low inbound media. In code, requestReticulumPacketLinkFallback() set a 15s fallback request window, but activateReticulumAudioLinkFallback() immediately cleared it; this allowed the fallback to leave after the 3s probe dwell.
  • Patch target: preserve packetLinkFallbackRequestedUntilMs / packetLinkFallbackReason when activating fallback, require the request window and peer-RX-missing hold to expire before leaving fallback, and let peer RX-missing heartbeats refresh the hold while fallback is active.
  • This remains “another subsystem,” not selector/profile strength/baseline. The Linux receive profile matched the symptom; the receiver was underfed because the sender did not stay on the working fallback path long enough.

Call: 2026-05-06 21:56Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-06T21-56-49-017Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-06T21-56-44-758Z.json

User symptom:

  • New paired call after the packet/link fallback policy changes; subjective symptom was not included with the export, so user-bad is inferred from receive metrics, profiles, and transport balance.

High-level verdict:

  • Mixed/improved.
  • The earlier sender-side fallback/underfed-link problem is much improved: both directions received thousands of packets, both sides ended on packet, packet send failures are 0, decode/key/queue paths are clean, and the packet/link sample mix is mostly packet. The remaining issue is moderate receive-policy quality: Mac is in persistent-lean under recovery, while Linux is in steady-weak-listener but exits back to low-latency despite sustained missing-frame and under-target pressure.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Key/media establishment: both sides have room keys, live mic senders, inbound packets, decoded frames, active playouts, and live policy profiles.
  • Startup hidden playout nodes: both sides have active playback/scheduler nodes and jitterHasReadyFrame=true.
  • Queue/backpressure: bridge/binary high-water values are low (2/2 on Mac, 4/2 on Linux), with no queue-pressure or stale drops.
  • Packet media path: packet send failures are 0, packet fresh sends are high, and both sides ended with last transport packet.
  • Failover: root/cluster promotion counts are 0 on both sides.

Primary next target:

  • Profile strength / hold for the moderate weak/lean receive profiles.
  • This is not primarily selector: Mac’s persistent-lean is directionally plausible for avgPcmBufferedMs=20.437, low jitter depth, negative playout delta, and persistent under-target pressure. Linux’s steady-weak-listener is also plausible for sustained missing-frame/concealment pressure with moderate under-target/rate pressure.
  • This is not another transport subsystem first: unlike 18:39Z, packet arrival is balanced enough for both sides to decode thousands of frames, and both sides ended on packet.
  • This is not a global baseline change yet: the evidence is concentrated in non-clean weak/lean profiles rather than clean-low-latency sounding bad.
  • Next patch should tune the weak/lean family first: make persistent-lean and steady-weak-listener hold recovery/protection a little longer, or give them slightly stronger target/floor behavior, so they do not oscillate back to low-latency while under-target/missing-frame pressure is still present.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP persistent-lean partly 20.437 274 5 0.089 0.008 recovery Classification mostly matches a persistent lean/under-target listener: ready playout and low concealment, but low reserve, negative delta, and recovery mode.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 steady-weak-listener partly 49.016 647 63 0.048 0.035 low-latency Classification is plausible for buffered weak-listener pressure; reserve is healthy enough to avoid collapse, but missing/concealment counters keep it non-clean.

Side A

Expected profile from symptom:

  • persistent-lean or steady-weak-listener

Actual exported profile:

  • persistent-lean

Did classification match?

  • Yes/partly.

Notes:

  • avgPcmBufferedMs=20.437, jitterBufferDepthFramesMean=1.040, and avgPlayoutDeltaMs=-118.118 fit a persistent shallow/lean listener more than a clean call.
  • jitterHasReadyFrame=true with 21 buffered jitter frames, concealmentTicks=5, and playoutRateFractionBelow097=0.008 keep this out of repair-collapse or buffered-not-ready.
  • The profile family is plausible; if the side still sounded rough, tune persistent-lean strength/hold rather than selector priority.

Side B

Expected profile from symptom:

  • steady-weak-listener

Actual exported profile:

  • steady-weak-listener

Did classification match?

  • Yes/partly.

Notes:

  • avgPcmBufferedMs=49.016, jitterBufferDepthFramesMean=2.478, jitterBufferedFrames=12, and jitterHasReadyFrame=true make this a ready buffered listener, not collapse or startup.
  • missingFrames=647, concealmentTicks=63, playoutUnderTargetFraction=0.048, playoutRateFractionBelow097=0.035, and avgPlayoutDeltaMs=-81.571 justify keeping it out of clean-low-latency.
  • The final adaptive mode is low-latency despite repeated recovery entries and sustained missing-frame growth, so weak-listener hold/clear behavior is the likely tuning point.

Trend Read

Side A:

  • Gradual moderate lean path with one recovery re-entry.
  • Reasons seen:
    • missingFrames increases from 238 to 274.
    • concealmentTicks stays flat at 5.
    • avgPcmBufferedMs stays around 20.4 to 21.0 ms, never rebuilding into a clearly healthy reserve.
    • adaptive mode briefly exits to low-latency, then re-enters recovery.

Side B:

  • Gradual buffered weak-listener path with oscillating recovery entries.
  • Reasons seen:
    • entered-recovery appears twice.
    • missingFrames increases from 545 to 647.
    • concealmentTicks increases from 58 to 63.
    • avgPcmBufferedMs improves from about 47.5 to 49.0 ms, but under-target and rate-below-0.97 pressure persist.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-06T14:30Z group-812 A / Mac standby silent-lean yes yes/partly profile application / adaptive-mode hold Improved in 21:56Z: Mac now has ready playout and recovery mode applied under a lean profile.
2026-05-06T14:30Z group-812 B / Linux root repair-collapse partly no/partly selector / repair-collapse escape Improved in 21:56Z: Linux now selects steady-weak-listener, not collapse, for a ready buffered path.
2026-05-06T18:39Z group-812 A / Mac standby steady-weak-listener partly partly readiness / secondary Improved in 21:56Z: Mac playout is ready and receives thousands of frames.
2026-05-06T18:39Z group-812 B / Linux root repair-collapse yes yes sender-side fallback exit / underfed receiver Improved in 21:56Z: Linux receives 3956 packets and ends on packet transport; underfed-link failure is no longer dominant.
2026-05-06T21:56Z group-812 A / Mac standby persistent-lean partly yes/partly weak/lean profile strength Tune persistent-lean target/floor or hold so reserve can rebuild above the lean band.
2026-05-06T21:56Z group-812 B / Linux root steady-weak-listener partly yes/partly weak-listener hold/strength Tune weak-listener hold/clear so recovery does not exit while missing-frame and under-target pressure persist.

Next Fix Target

Current patched target:

  • Profile strength / hold for moderate weak/lean receive profiles.
  • Primary fix: strengthen persistent-lean and/or steady-weak-listener protection modestly, especially hold/clear behavior after recovery entry, so ready-but-stressed listeners do not fall back to low-latency before missing-frame and under-target pressure quiet down.
  • Keep selector thresholds mostly unchanged from this batch: classification is no longer obviously wrong on either side.
  • Keep packet/link fallback and media-path delivery unchanged for the next patch: the new call shows packet recovery and balanced inbound media compared with the earlier underfed-link failures.
  • Keep global baseline unchanged for now. This batch is evidence for non-clean profile tuning, not clean-call baseline failure.

Call: 2026-05-06 23:26Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-06T23-26-32-953Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-06T23-26-28-059Z.json

User symptom:

  • New paired call after the weak/lean receive-policy changes; user reported the call was pretty bad.

High-level verdict:

  • Bad.
  • Correctness, startup, and broad media establishment are clean, but both sides remain in ready stressed receive paths. The exported profiles are both steady-weak-listener; Mac is a plausible weak-listener, while Linux looks too damaged for ordinary weak-listener and should be promoted toward a repair profile.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Key/media establishment: both sides have inbound packets, decoded frames, active playouts, and live policy profiles.
  • Startup hidden playout nodes: both sides have active playback/scheduler nodes and jitterHasReadyFrame=true.
  • Queue/backpressure: bridge/binary high-water values are low (3/0 on Mac, 4/1 on Linux), with no queue-pressure or stale drops.
  • Failover: root/cluster promotion counts are 0 on both sides.
  • Baseline: neither side is clean-low-latency; this is not evidence that the global clean baseline is too low.

Primary next target:

  • Selector.
  • Specifically, tune the boundary between steady-weak-listener and repair-heavy-connected for ready-buffered but audibly bad paths. Linux has usable reserve and ready playout, but missingFrames=689, concealmentTicks=74, playoutUnderTargetFraction=0.086, playoutRateFractionBelow097=0.074, and avgPlayoutDeltaMs=-92.283; that is closer to buffered repair pressure than ordinary weak-listener.
  • Do not tune baseline first. Do not jump to another transport subsystem first: packet arrival is reasonably balanced (2526 packets on Mac, 2412 on Linux), both directions decode, and there are no send/decode/key drops. Keep Linux reticulumAudioPacketPathTimeouts=98 as a secondary watch item, but the next receive-policy fix is classification strength/priority into repair-heavy.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP steady-weak-listener yes 23.397 443 45 0.044 0.021 recovery Classification partly matches a weak/lean path: ready playout, low reserve, negative delta, and moderate damage.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 steady-weak-listener yes 41.742 689 74 0.086 0.074 recovery Classification is too mild for the reported bad call and sustained under-target/slow-rate pressure; this should border repair-heavy-connected.

Side A

Expected profile from symptom:

  • steady-weak-listener or repair-heavy-connected.

Actual exported profile:

  • steady-weak-listener

Did classification match?

  • Partly/yes.

Notes:

  • avgPcmBufferedMs=23.397, jitterBufferDepthFramesMean=1.185, and avgPlayoutDeltaMs=-105.875 fit a persistent weak-listener shape.
  • jitterHasReadyFrame=true with 21 buffered jitter frames keeps this out of buffered-not-ready or collapse.
  • The damage is still real: missingFrames=443, concealmentTicks=45, and recovery mode is active. If this direction sounded bad, it is evidence for either a stronger weak-listener hold or promotion when damage persists.

Side B

Expected profile from symptom:

  • repair-heavy-connected, with steady-weak-listener only as the weaker fallback.

Actual exported profile:

  • steady-weak-listener

Did classification match?

  • Partly/no.

If no:

  • The side is ready and not collapsed: avgPcmBufferedMs=41.742, jitterBufferDepthFramesMean=2.113, jitterBufferedFrames=23, and jitterHasReadyFrame=true.
  • But the bad-call symptom and damage counters are stronger than ordinary weak-listener: missingFrames=689, concealmentTicks=74, playoutUnderTargetFraction=0.086, playoutRateFractionBelow097=0.074, and avgPlayoutDeltaMs=-92.283.
  • Tune selector escalation into repair-heavy-connected before raising global baseline or making another broad profile-strength increase.

Trend Read

Side A:

  • Gradual weak-listener path under recovery.
  • Reasons seen:
    • missingFrames increases from 410 to 443.
    • concealmentTicks stays flat at 45.
    • avgPcmBufferedMs stays around 23.1 to 23.4 ms.
    • adaptive mode remains recovery, so this is not a low-latency exit problem.

Side B:

  • Gradual buffered repair/weak path with oscillating recovery.
  • Reasons seen:
    • entered-recovery appears twice.
    • adaptive mode exits to low-latency for much of the middle of the window, then re-enters recovery.
    • missingFrames increases from 552 to 689.
    • concealmentTicks rises from 69 to 74.
    • playoutUnderTargetFraction and playoutRateFractionBelow097 remain elevated around 0.086 / 0.074 at the end.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-06T14:30Z group-812 A / Mac standby silent-lean yes yes/partly profile application / adaptive-mode hold Improved by 21:56Z and 23:26Z: Mac playout is ready and recovery mode is applied when non-clean.
2026-05-06T14:30Z group-812 B / Linux root repair-collapse partly no/partly selector / repair-collapse escape Improved in later calls: Linux no longer over-selects collapse for ready buffered paths.
2026-05-06T18:39Z group-812 B / Linux root repair-collapse yes yes sender-side fallback exit / underfed receiver Improved in later calls: Linux receives thousands of packets, so underfed-link is not the dominant 23:26Z issue.
2026-05-06T21:56Z group-812 A / Mac standby persistent-lean partly yes/partly weak/lean profile strength Improved/shifted in 23:26Z: Mac now selects steady-weak-listener and stays in recovery, but still has moderate damage.
2026-05-06T21:56Z group-812 B / Linux root steady-weak-listener partly yes/partly weak-listener hold/strength Still relevant, but 23:26Z suggests the boundary should escalate worse ready-buffered damage into repair-heavy.
2026-05-06T23:26Z group-812 A / Mac standby steady-weak-listener yes partly/yes weak-listener / secondary Keep as evidence; do not tune baseline from this side alone.
2026-05-06T23:26Z group-812 B / Linux root steady-weak-listener yes partly/no selector / repair-heavy escalation Promote ready-buffered paths with sustained missing/concealment plus under-target/slow-rate pressure into repair-heavy-connected.

Next Fix Target

Current patched target:

  • Selector.
  • Primary fix: strengthen the steady-weak-listener to repair-heavy-connected escalation when a ready buffered listener has sustained missing-frame growth, active concealment, elevated under-target fraction, elevated slow-rate fraction, and a user-bad symptom.
  • Secondary watch item: Linux has reticulumAudioPacketPathTimeouts=98, so keep packet-route diagnostics visible, but do not make transport the first patch from this call because both sides received and decoded comparable packet counts.
  • Keep global baseline unchanged. Keep collapse/repair-collapse strength unchanged. This batch is not a clean-call baseline failure and not a correctly selected heavy-profile weakness; the miss is that the worse side stayed in an ordinary weak-listener profile.

Call: 2026-05-07 14:07Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-07T14-07-27-221Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-07T14-07-23-457Z.json

User symptom:

  • New paired call after the steady-weak-listener to repair-heavy-connected selector change; subjective symptom was not included with the export, so user-bad is inferred from receive metrics and non-clean profiles.

High-level verdict:

  • Mixed/bad, but the selector moved in the intended direction.
  • Correctness, key/media establishment, startup playout nodes, and queue paths are clean. Mac is a plausible persistent-lean path that is slowly rebuilding reserve under recovery. Linux now escalates to repair-heavy-connected, matching the prior target, but still has high not-ready, under-target, and slow-rate pressure while recovery is active.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Key/media establishment: both sides have room keys, live mic senders, inbound packets, decoded frames, active playouts, and live policy profiles.
  • Startup hidden playout nodes: both sides have active playback/scheduler nodes and final jitterHasReadyFrame=true.
  • Queue/backpressure: bridge/binary high-water values are low (2/0 on Mac, 4/1 on Linux), with no queue-pressure, stale, link-unready, or send-failure drops.
  • Failover: root/cluster promotion counts are 0 on both sides.
  • Baseline: neither side is clean-low-latency, so this is not evidence for raising the global clean baseline.

Primary next target:

  • repair-heavy-connected profile strength / hold.
  • The selector target from 23:26Z appears improved: Linux no longer stays in steady-weak-listener; it now exports repair-heavy-connected.
  • Per the decision rules, classification is mostly correct but immediate quality is still bad on Linux: avgPcmBufferedMs=16.033, jitterNotReadyFraction=0.268, concealmentTicks=85, playoutUnderTargetFraction=0.268, and playoutRateFractionBelow097=0.245 while recovery mode is active.
  • Do not tune selector first from this call. Do not raise baseline first. The current evidence is profile-specific: a correctly selected buffered repair profile is not strong or sticky enough to stabilize playout.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP persistent-lean partly 14.193 45 3 0.023 0.009 recovery Classification is plausible: reserve is still shallow with strongly negative delta, but damage counters are low and reserve is improving.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 repair-heavy-connected yes 16.033 43 85 0.268 0.245 recovery Classification matches the improved selector target, but recovery is not rebuilding enough reserve or readiness.

Side A

Expected profile from symptom:

  • persistent-lean or steady-weak-listener

Actual exported profile:

  • persistent-lean

Did classification match?

  • Yes/partly.

Notes:

  • avgPcmBufferedMs=14.193, jitterBufferDepthFramesMean=0.720, and avgPlayoutDeltaMs=-120.868 fit a lean listener more than a clean call.
  • jitterHasReadyFrame=true with 21 buffered jitter frames, concealmentTicks=3, missingFrames=45, and playoutRateFractionBelow097=0.009 keep it out of repair-heavy or collapse.
  • This side is secondary: its trend improves from about 6 ms to 14 ms reserve while staying in recovery.

Side B

Expected profile from symptom:

  • repair-heavy-connected, possibly bordering repair-collapse if not-ready pressure persists.

Actual exported profile:

  • repair-heavy-connected

Did classification match?

  • Yes/partly.

Notes:

  • This is the shape the last selector patch was meant to catch: ready final playout, not full collapse, but sustained repair pressure and poor playout timing.
  • jitterNotReadyFraction=0.268, concealmentTicks=85, playoutUnderTargetFraction=0.268, playoutRateFractionBelow097=0.245, and avgPlayoutDeltaMs=-124.907 make this a user-bad repair profile despite only 43 missing frames.
  • Since recovery mode is already active and the profile is plausible, the next patch should tune repair-heavy-connected target/floor/hold or clear conditions, not selector priority.

Trend Read

Side A:

  • Gradual lean recovery.
  • Reasons seen:
    • entered-recovery appears once with packet-path-timeouts-started.
    • avgPcmBufferedMs improves from about 6.2 to 14.2 ms.
    • missingFrames only grows from 23 to 45 after topology epoch 3.
    • concealmentTicks stays low at 3.

Side B:

  • Early severe repair/not-ready pressure with partial reserve rebuild under recovery.
  • Reasons seen:
    • avgPcmBufferedMs starts around 5.1 ms, falls near 2.4 ms, then rebuilds to 16.0 ms.
    • concealmentTicks rises from 34 to 85.
    • playoutUnderTargetFraction remains high at 0.268.
    • playoutRateFractionBelow097 remains high at 0.245.
    • final playout is ready with 15 buffered jitter frames, so this is not a pure buffered-not-ready selector miss.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-06T21:56Z group-812 A / Mac standby persistent-lean partly yes/partly weak/lean profile strength Still relevant; 14:07Z Mac remains lean but is improving and not the primary bad side.
2026-05-06T21:56Z group-812 B / Linux root steady-weak-listener partly yes/partly weak-listener hold/strength Superseded by 23:26Z and 14:07Z: the worse Linux shape now escalates past weak-listener.
2026-05-06T23:26Z group-812 A / Mac standby steady-weak-listener yes partly/yes weak-listener / secondary Keep as evidence, but not the current first target.
2026-05-06T23:26Z group-812 B / Linux root steady-weak-listener yes partly/no selector / repair-heavy escalation Improved in 14:07Z: Linux now selects repair-heavy-connected for the worse ready-buffered repair path.
2026-05-07T14:07Z group-812 A / Mac standby persistent-lean partly yes/partly lean profile / secondary Watch; do not tune first because damage counters are low and reserve is rebuilding.
2026-05-07T14:07Z group-812 B / Linux root repair-heavy-connected yes yes/partly repair-heavy profile strength / hold Tune repair-heavy-connected target/floor/hold or stricter clear conditions so active recovery can rebuild reserve and reduce under-target/slow-rate pressure.

Next Fix Target

Current patched target:

  • repair-heavy-connected profile strength / hold.
  • Primary fix: strengthen or lengthen repair-heavy-connected protection after escalation from weak-listener, especially while jitterNotReadyFraction, playoutUnderTargetFraction, and playoutRateFractionBelow097 remain high.
  • Secondary watch item: Mac persistent-lean still has shallow reserve, but low concealment and improving reserve make it a lower-priority profile-strength signal.
  • Keep selector, baseline, key/media delivery, and decode/session unchanged for the next patch. This call says classification has mostly caught up; the correctly selected repair profile now needs to do more work.

Call: 2026-05-07 17:25Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-07T17-25-28-379Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-07T17-25-25-085Z.json

User symptom:

  • New paired call after the latest receive-policy changes; subjective symptom was not included with the export, so user-bad is inferred from receive metrics and non-clean profiles.

High-level verdict:

  • Mixed/bad.
  • Correctness, startup playout, queue/backpressure, and failover paths are clean. Both sides are ready and in recovery, but both are still near-empty with strongly negative playout delta. The exported profile is persistent-lean on both sides, while the metric shape now looks closer to the existing silent-lean blind spot.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Key/media establishment: both sides have room keys, inbound packets, decoded frames, active playouts, and live policy profiles.
  • Startup hidden playout nodes: both sides have active playback/scheduler nodes and jitterHasReadyFrame=true.
  • Queue/backpressure: bridge/binary high-water values are low (2/1 on Mac, 4/1 on Linux), with no queue-pressure, stale, link-unready, or send-failure drops.
  • Failover: root/cluster promotion counts are 0 on both sides.
  • Baseline: neither side is clean-low-latency, so this is not a clean-call baseline failure.

Primary next target:

  • Selector.
  • Specifically, tune the persistent-lean versus silent-lean boundary. Both sides have tiny reserve (4.907 ms Mac, 7.181 ms Linux), very low jitter-depth mean (0.249 / 0.366 frames), strongly negative playout delta (-136.111 ms / -151.507 ms), and low obvious damage pressure (concealmentTicks=0 / 56, playoutRateFractionBelow097=0.001 / 0.012).
  • Per docs/gcall-receive-profiles.md, that is the silent-lean blind spot more than ordinary persistent-lean: bad/fragile audibility can exist before concealment and slow-rate counters explode.
  • Do not tune repair-heavy-connected from this call. The latest repair-heavy target is not active here. Do not raise baseline or move to another subsystem first.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP persistent-lean yes/partly 4.907 152 0 0.005 0.001 recovery Classification is too mild/specific: this is ready but almost empty, with low damage counters, matching silent-lean better.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 persistent-lean yes 7.181 135 56 0.022 0.012 recovery Classification partly matches lean behavior, but reserve and delta are severe enough to prefer silent-lean over ordinary persistent lean.

Side A

Expected profile from symptom:

  • silent-lean

Actual exported profile:

  • persistent-lean

Did classification match?

  • Partly/no.

If no:

  • avgPcmBufferedMs=4.907, jitterBufferDepthFramesMean=0.249, and avgPlayoutDeltaMs=-136.111 are more severe than ordinary persistent lean.
  • concealmentTicks=0, playoutUnderTargetFraction=0.005, and playoutRateFractionBelow097=0.001 are exactly why this should use the silent-lean blind-spot profile instead of waiting for repair-heavy damage signals.
  • The playout snapshot is ready (jitterBufferedFrames=24, jitterHasReadyFrame=true), so this is not the buffered-not-ready/startup path.

Side B

Expected profile from symptom:

  • silent-lean, possibly persistent-lean as the weaker fallback.

Actual exported profile:

  • persistent-lean

Did classification match?

  • Partly.

If no:

  • This side has slightly more visible damage than Mac (concealmentTicks=56, missingFrames=135), but the dominant shape is still tiny reserve plus strongly negative delta: avgPcmBufferedMs=7.181, jitterBufferDepthFramesMean=0.366, and avgPlayoutDeltaMs=-151.507.
  • Final playout is ready with 23 buffered jitter frames, and decode/key paths are clean, so selector tuning should come before subsystem work.

Trend Read

Side A:

  • Flat tiny-reserve lean path under recovery.
  • Reasons seen:
    • avgPcmBufferedMs only improves from 4.755 to 4.907 ms.
    • missingFrames increases from 117 to 152.
    • concealmentTicks remains 0, so the failure is hidden from repair-heavy/collapse damage counters.
    • adaptive mode remains recovery; this is not an early low-latency exit.

Side B:

  • Flat tiny-reserve lean path with mild damage.
  • Reasons seen:
    • avgPcmBufferedMs only improves from 6.197 to 7.181 ms.
    • missingFrames increases from 100 to 135.
    • concealmentTicks stays flat at 56.
    • playoutUnderTargetFraction and playoutRateFractionBelow097 ease slightly but remain non-clean.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-06T23:26Z group-812 A / Mac standby steady-weak-listener yes partly/yes weak-listener / secondary Superseded as first target by later calls.
2026-05-06T23:26Z group-812 B / Linux root steady-weak-listener yes partly/no selector / repair-heavy escalation Improved in 14:07Z: Linux escalated to repair-heavy-connected.
2026-05-07T14:07Z group-812 A / Mac standby persistent-lean partly yes/partly lean profile / secondary Still relevant; 17:25Z shows this lean/tiny-reserve shape recurring.
2026-05-07T14:07Z group-812 B / Linux root repair-heavy-connected yes yes/partly repair-heavy profile strength / hold Not active in 17:25Z, so do not continue repair-heavy tuning from the new call alone.
2026-05-07T17:25Z group-812 A / Mac standby persistent-lean yes/partly partly/no selector / silent-lean escalation Promote ready, near-empty, low-damage paths into silent-lean.
2026-05-07T17:25Z group-812 B / Linux root persistent-lean yes partly selector / silent-lean escalation Promote tiny-reserve, very negative-delta paths into silent-lean before profile-strength or baseline changes.

Next Fix Target

Current patched target:

  • Selector.
  • Primary fix: strengthen silent-lean entry/priority over persistent-lean when reserve is extremely low and playout delta is strongly negative, even if concealment, under-target, and slow-rate counters are still mild.
  • Keep repair-heavy-connected strength/hold as a previous improvement, but pause further repair-heavy tuning until another call actually selects that profile and still sounds bad.
  • Keep global baseline, key/decode/session, startup readiness, and transport paths unchanged for the next patch. This batch points at an existing profile selector miss, not a new subsystem or baseline problem.

Call: 2026-05-07 18:57Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-07T18-57-26-268Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-07T18-57-31-301Z.json

User symptom:

  • New paired call after the ready silent-lean selector change; subjective symptom was not included with the export, so user-bad is inferred from receive metrics and profile mismatch.

High-level verdict:

  • Mixed/bad.
  • Correctness, key/media establishment, startup playout nodes, queue/backpressure, and failover paths are clean. Mac remains a plausible lean recovery path, but Linux is a clear false-clean classification: it exported clean-low-latency while carrying sustained missing-frame, concealment, under-target, and slow-rate pressure.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Key/media establishment: both sides have room keys, inbound packets, decoded frames, active playouts, and live policy profiles.
  • Startup hidden playout nodes: both sides have active playback/scheduler nodes and jitterHasReadyFrame=true.
  • Queue/backpressure: bridge/binary high-water values are low (2/2 on Mac, 1/3 on Linux), with no queue-pressure, stale, link-unready, or send-failure drops.
  • Failover: root/cluster promotion counts are 0 on both sides.
  • Transport: packet path is active in both directions with thousands of inbound packet samples and no send failures; packet path timeouts are present but not the dominant blocker in this export.

Primary next target:

  • Selector.
  • Specifically, prevent clean-low-latency from winning on ready buffered repair-pressure paths. Linux has avgPcmBufferedMs=47.367, jitterHasReadyFrame=true, and jitterBufferedFrames=10, so it is not collapsed or startup-blocked, but it also has missingFrames=278, concealmentTicks=90, playoutUnderTargetFraction=0.132, playoutRateFractionBelow097=0.082, and avgPlayoutDeltaMs=-88.342.
  • That shape fits repair-heavy-connected or at least steady-weak-listener, not clean-low-latency.
  • Do not tune baseline first. This is not a clean healthy listener sounding bad; it is an exported clean profile despite non-clean metrics. Do not tune silent-lean first from this call: Mac did not cross the new tiny-reserve ready gate, and Linux is buffered/damaged rather than silent/tiny.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP persistent-lean partly 16.920 154 0 0.014 0.002 recovery Classification mostly matches: ready, low reserve, low jitter depth, strongly negative delta, and low damage counters.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 clean-low-latency yes 47.367 278 90 0.132 0.082 low-latency Classification is wrong: ready/buffered but damaged and under-target; should promote to repair-heavy-connected or steady-weak-listener.

Side A

Expected profile from symptom:

  • persistent-lean, possibly bordering silent-lean only if reserve falls further.

Actual exported profile:

  • persistent-lean

Did classification match?

  • Yes/partly.

Notes:

  • avgPcmBufferedMs=16.920, jitterBufferDepthFramesMean=0.858, and avgPlayoutDeltaMs=-129.074 fit a persistent lean path.
  • concealmentTicks=0, playoutUnderTargetFraction=0.014, and playoutRateFractionBelow097=0.002 keep this out of repair-heavy.
  • The side is already in recovery and its reserve is slowly improving from 16.535 to 16.920 ms, so it is not the first next-fix target.

Side B

Expected profile from symptom:

  • repair-heavy-connected, with steady-weak-listener as the weaker fallback.

Actual exported profile:

  • clean-low-latency

Did classification match?

  • No.

If no:

  • The side is not shallow-collapse: avgPcmBufferedMs=47.367, jitterBufferDepthFramesMean=2.406, jitterBufferedFrames=10, and jitterHasReadyFrame=true.
  • But it is also not clean: missingFrames=278, concealmentTicks=90, playoutUnderTargetFraction=0.132, playoutRateFractionBelow097=0.082, and avgPlayoutDeltaMs=-88.342.
  • Tune selector entry/priority for ready buffered damage before changing profile strength or baseline.

Trend Read

Side A:

  • Flat/slowly improving lean recovery.
  • Reasons seen:
    • avgPcmBufferedMs improves slightly from 16.535 to 16.920 ms.
    • missingFrames increases from 120 to 154.
    • concealmentTicks remains 0.
    • adaptive mode remains recovery.

Side B:

  • Oscillating false-clean buffered repair path.
  • Reasons seen:
    • starts and ends in low-latency despite non-clean metrics.
    • entered-recovery appears once, then the side exits back to low-latency.
    • missingFrames increases from 181 to 278.
    • concealmentTicks rises from 86 to 90.
    • playoutUnderTargetFraction remains high at 0.132, and playoutRateFractionBelow097 remains high at 0.082.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-07T14:07Z group-812 A / Mac standby persistent-lean partly yes/partly lean profile / secondary Still watch, but not the first target.
2026-05-07T14:07Z group-812 B / Linux root repair-heavy-connected yes yes/partly repair-heavy profile strength / hold Superseded as first target by the 18:57Z false-clean selector miss.
2026-05-07T17:25Z group-812 A / Mac standby persistent-lean yes/partly partly/no selector / silent-lean escalation Partly improved by the ready silent-lean selector change, but 18:57Z Mac is no longer tiny-reserve enough to be the primary miss.
2026-05-07T17:25Z group-812 B / Linux root persistent-lean yes partly selector / silent-lean escalation Current batch shifted: Linux is now buffered/damaged and incorrectly clean, not silent/tiny lean.
2026-05-07T18:57Z group-812 A / Mac standby persistent-lean partly yes/partly persistent-lean / secondary Keep as evidence; no selector change first from this side.
2026-05-07T18:57Z group-812 B / Linux root clean-low-latency yes no selector / false-clean repair pressure Promote ready buffered listeners with sustained missing/concealment plus under-target/slow-rate pressure into repair-heavy-connected or steady-weak-listener.

Next Fix Target

Current patched target:

  • Selector.
  • Primary fix: add or strengthen a false-clean escape for ready buffered listeners with sustained damage and playout pressure: missing-frame growth, active concealment, high under-target fraction, slow-rate pressure, and strongly negative delta should not remain clean-low-latency.
  • Preferred destination is repair-heavy-connected when both damage and under-target/slow-rate pressure are present; otherwise steady-weak-listener is the weaker fallback.
  • Keep global baseline unchanged. Keep key/decode/session, startup readiness, transport, and silent-lean strength unchanged for the next patch. This batch points at a selector false negative, not baseline or another subsystem.

Call: 2026-05-07 19:25Z / group 937

Room:

  • gcall-qortal-937

Files:

  • Side A: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-07T19-25-22-670Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-07T19-25-23-220Z.json

User symptom:

  • New paired call after the latest selector changes; subjective symptom was not included with the export, so user-bad is inferred from receive metrics and profile mismatch.

High-level verdict:

  • Mixed/bad.
  • Correctness, key/media establishment, startup playout nodes, queue/backpressure, and failover paths are clean enough to keep this in receive-policy territory. Root still exports clean-low-latency despite sustained repair pressure, while standby remains in a tiny-buffer lean shape that is closer to the existing silent-lean blind spot than ordinary persistent-lean.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Key/media establishment: both sides have room keys, inbound packets, decoded frames, active playouts, and live policy profiles.
  • Startup hidden playout nodes: both sides have active playback/scheduler nodes and jitterHasReadyFrame=true.
  • Queue/backpressure: no bridge drain wait, no queue-pressure drops, no stale drops, no link-unready drops, and no send failures. Bridge/binary high-water values are modest (7/5 on root, 2/4 on standby).
  • Failover: root/cluster promotion counts are 0 on both sides.

Primary next target:

  • Selector.
  • The first target remains the false-clean escape for ready buffered repair pressure. Side A has a healthy-looking reserve (avgPcmBufferedMs=59.879, jitterBufferDepthFramesMean=3.036) but non-clean damage and pressure (missingFrames=2965, concealmentTicks=192, playoutUnderTargetFraction=0.086, playoutRateFractionBelow097=0.024, avgPlayoutDeltaMs=-73.182) while still classified as clean-low-latency.
  • Side B is a secondary selector miss: it is ready but almost empty (avgPcmBufferedMs=9.506, jitterBufferDepthFramesMean=0.482, avgPlayoutDeltaMs=-139.744) with mild obvious damage, which still fits silent-lean better than ordinary persistent-lean.
  • Do not tune global baseline first. This is not a clean healthy listener sounding bad; the exported classifications are missing existing bad-profile shapes. Do not move to another subsystem first because the quick-triage correctness paths are clean.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QiNKXR...RHHo receiving QP9Jj4...i6rP clean-low-latency yes 59.879 2965 192 0.086 0.024 low-latency Classification is wrong: ready and buffered, but damaged and under-target enough to leave clean mode.
B standby-forwarder / Linux / QP9Jj4...i6rP receiving QiNKXR...RHHo persistent-lean yes/partly 9.506 2354 51 0.002 0.001 recovery Classification is partly too mild/specific: ready, near-empty, strongly negative delta, and low damage counters fit silent-lean better.

Side A

Expected profile from symptom:

  • repair-heavy-connected, with steady-weak-listener as the weaker fallback.

Actual exported profile:

  • clean-low-latency

Did classification match?

  • No.

If no:

  • The side is ready and buffered (jitterBufferedFrames=10, jitterHasReadyFrame=true, avgPcmBufferedMs=59.879), so this is not collapse or startup readiness.
  • It is also not clean: missingFrames rose from 2922 to 2965 during the sampled window, concealmentTicks=192, playoutUnderTargetFraction=0.086, and avgPlayoutDeltaMs=-73.182.
  • Tune selector entry/priority so buffered listeners with sustained missing-frame/concealment pressure and under-target pressure cannot remain clean-low-latency.

Side B

Expected profile from symptom:

  • silent-lean, with persistent-lean as the weaker fallback.

Actual exported profile:

  • persistent-lean

Did classification match?

  • Partly/no.

If no:

  • avgPcmBufferedMs=9.506, jitterBufferDepthFramesMean=0.482, and avgPlayoutDeltaMs=-139.744 are severe lean signals.
  • concealmentTicks=51, playoutUnderTargetFraction=0.002, and playoutRateFractionBelow097=0.001 explain why repair/collapse profiles should not win, but they also match the silent-lean blind spot: very shallow reserve before obvious damage counters explode.
  • Playout is ready (jitterBufferedFrames=23, jitterHasReadyFrame=true), so this is not the buffered-not-ready/startup path.

Trend Read

Side A:

  • Flat false-clean buffered repair path.
  • Reasons seen:
    • adaptive mode remains low-latency for the whole sampled trend.
    • missingFrames increases from 2922 to 2965.
    • concealmentTicks stays at 192.
    • avgPcmBufferedMs stays near 59.7 to 59.9 ms, so the problem is not a collapsed reserve.

Side B:

  • Flat tiny-reserve lean recovery.
  • Reasons seen:
    • adaptive mode remains recovery for the whole sampled trend.
    • avgPcmBufferedMs is pinned around 9.503 to 9.506 ms.
    • missingFrames increases from 2316 to 2354.
    • concealmentTicks stays at 51, with very low under-target and slow-rate pressure.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-07T17:25Z group-812 A / Mac standby persistent-lean yes/partly partly/no selector / silent-lean escalation Still relevant as secondary evidence for near-empty ready listeners.
2026-05-07T17:25Z group-812 B / Linux root persistent-lean yes partly selector / silent-lean escalation Still relevant as secondary evidence, but current first target is false-clean repair pressure.
2026-05-07T18:57Z group-812 A / Mac standby persistent-lean partly yes/partly persistent-lean / secondary Watch only; not the first target.
2026-05-07T18:57Z group-812 B / Linux root clean-low-latency yes no selector / false-clean repair pressure Repeats in 19:25Z; selector escape is still insufficient.
2026-05-07T19:25Z group-937 A / Linux root clean-low-latency yes no selector / false-clean repair pressure Promote ready buffered listeners with sustained missing/concealment plus under-target/negative-delta pressure into repair-heavy-connected or steady-weak-listener.
2026-05-07T19:25Z group-937 B / Linux standby persistent-lean yes/partly partly/no selector / silent-lean escalation Secondary: promote ready near-empty, low-damage paths into silent-lean, but do this after the repeated false-clean escape.

Next Fix Target

Current patched target:

  • Selector.
  • Primary fix: strengthen the false-clean escape for ready buffered repair pressure. The repeated miss is now clearer because Side A is not shallow, not startup-blocked, not decode/key broken, and not transport-backed up; it is simply damaged enough that clean-low-latency should not win.
  • Preferred destination remains repair-heavy-connected when missing-frame/concealment pressure combines with under-target or strongly negative playout delta; otherwise use steady-weak-listener as the weaker fallback.
  • Secondary selector fix: after the false-clean escape, tighten silent-lean priority over persistent-lean for ready near-empty listeners with very negative playout delta and low obvious damage counters.
  • Keep profile strength, global baseline, startup readiness, key/decode/session, and transport unchanged for the next patch. The batch points at selector false negatives, not profile strength or another subsystem.

Call: 2026-05-07 19:48Z / group 937

Room:

  • gcall-qortal-937

Files:

  • Side A: /home/qortal/Downloads/phil-kenny-one-on-one-109.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-07T19-48-09-713Z.json

User symptom:

  • Another group call from before the latest selector patch. Subjective symptom was not included with the export, so user-bad is inferred from receive metrics and profile mismatch.

High-level verdict:

  • Bad.
  • Correctness, key/media establishment, startup playout nodes, queue/backpressure, and failover paths are clean. This is receive-policy dominated, but it is not just the previous false-clean case: root is already in steady-weak-listener and still looks too mild for the damage, while standby is classified as silent-lean even though the damage counters are far beyond the low-damage silent-lean shape.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Key/media establishment: both sides have room keys, inbound packets, decoded frames, active playouts, and live policy profiles.
  • Startup hidden playout nodes: both sides have active playback/scheduler nodes and jitterHasReadyFrame=true.
  • Queue/backpressure: no bridge drain wait, no queue-pressure drops, no stale drops, no link-unready drops, and no send failures. Bridge/binary high-water values are modest (13/5 on root, 2/4 on standby).
  • Failover: root/cluster promotion counts are 0 on both sides.

Primary next target:

  • Selector, with a broader repair-damage escalation after the false-clean patch.
  • Side A says the selector should not stop at steady-weak-listener when a ready listener has shallow/moderate reserve plus sustained missing/concealment damage and very negative delta.
  • Side B says silent-lean should be reserved for near-empty low-damage paths. Near-empty plus exploding missing/concealment should escalate to repair-collapse or collapse-recovery, not remain silent-lean.
  • This does not change the immediate patch already made for the repeated false-clean miss, but it should be the next selector refinement if another post-fix call still sounds bad.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QTSzRS...9jMn receiving QP9Jj4...i6rP steady-weak-listener yes 28.707 1695 248 0.029 0.023 recovery Classification is too mild: ready, shallow/moderate reserve, high damage, and very negative delta fit repair-heavy-connected better.
B standby-forwarder / Linux / QP9Jj4...i6rP receiving QTSzRS...9jMn silent-lean yes 4.140 2612 3882 0.052 0.051 recovery Classification is wrong/too weak for damage: this is near-empty repair collapse, not low-damage silent-lean.

Side A

Expected profile from symptom:

  • repair-heavy-connected, with steady-weak-listener as the weaker fallback only if damage pressure is mild.

Actual exported profile:

  • steady-weak-listener

Did classification match?

  • Partly/no.

If no:

  • avgPcmBufferedMs=28.707, jitterBufferDepthFramesMean=1.455, and avgPlayoutDeltaMs=-101.850 show a ready but shallow/moderate reserve.
  • missingFrames=1695 and concealmentTicks=248 are too damaged for ordinary weak-listener behavior, even though playoutUnderTargetFraction=0.029 and playoutRateFractionBelow097=0.023 are only moderate.
  • Tune selector escalation from steady-weak-listener to repair-heavy-connected for sustained ready damage with strongly negative delta.

Side B

Expected profile from symptom:

  • repair-collapse or collapse-recovery.

Actual exported profile:

  • silent-lean

Did classification match?

  • No.

If no:

  • avgPcmBufferedMs=4.140, jitterBufferDepthFramesMean=0.210, and avgPlayoutDeltaMs=-141.553 are severe reserve-collapse signals.
  • The usual damage counters are not mild: missingFrames=2612, concealmentTicks=3882, playoutUnderTargetFraction=0.052, and playoutRateFractionBelow097=0.051.
  • This should not be handled as the silent-lean blind spot. Tune selector priority so high-concealment near-empty ready paths promote into repair-collapse or collapse-recovery.

Trend Read

Side A:

  • Flat bad repair path under recovery.
  • Reasons seen:
    • adaptive mode remains recovery.
    • avgPcmBufferedMs stays around 28.6 to 28.7 ms.
    • missingFrames increases from 1656 to 1695.
    • concealmentTicks stays high at 248.

Side B:

  • Flat severe near-empty repair collapse.
  • Reasons seen:
    • adaptive mode remains recovery.
    • avgPcmBufferedMs stays pinned around 4.1 ms.
    • missingFrames increases from 2495 to 2612.
    • concealmentTicks increases from 3700 to 3882.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-07T18:57Z group-812 B / Linux root clean-low-latency yes no selector / false-clean repair pressure Covered by latest code change: ready buffered damage now escapes clean.
2026-05-07T19:25Z group-937 A / Linux root clean-low-latency yes no selector / false-clean repair pressure Covered by latest code change for moderate-reserve false-clean repair pressure.
2026-05-07T19:25Z group-937 B / Linux standby persistent-lean yes/partly partly/no selector / silent-lean escalation Partly covered by latest code change: ready near-empty low-damage paths get silent-lean.
2026-05-07T19:48Z group-937 A / Linux root steady-weak-listener yes partly/no selector / repair-heavy escalation Next refinement: promote ready shallow/moderate-reserve damage from weak-listener into repair-heavy-connected.
2026-05-07T19:48Z group-937 B / Linux standby silent-lean yes no selector / repair-collapse escalation Next refinement: high-concealment near-empty ready paths should promote from silent-lean into repair-collapse or collapse-recovery.

Next Fix Target

Current patched target:

  • Selector.
  • The latest code change still addresses the most repeated pre-fix miss: false-clean ready buffered repair pressure.
  • This additional pre-fix call suggests the next selector refinement if post-fix diagnostics remain bad: repair-damage escalation above weak/lean profiles. steady-weak-listener should not hold when sustained damage and very negative delta are present, and silent-lean should not hold when concealment/missing counters are already severe.
  • Do not tune baseline or another subsystem from this call. The paths are established and correctness counters are clean.

Call: 2026-05-07 20:30Z / group 937

Room:

  • gcall-qortal-937

Files:

  • Side A: /home/qortal/Downloads/phil-kenny-one-on-one-110.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-07T20-30-11-392Z.json

User symptom:

  • New call after the latest changes; user reported it was a horrible call.

High-level verdict:

  • Catastrophic.
  • This call is not primarily a baseline or profile-strength failure. Both sides are already in recovery-class receive behavior, but the paired exports show authority/topology divergence and send-target symptoms: Side A says root is QTSzRS...9jMn at epoch 3 with QP9Jj4...i6rP as standby, while Side B says root is QP9Jj4...i6rP at epoch 4 with no standby. Side B also has outboundNoTargetSkips=4407 and forwardRecipientCount=0.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure and packetsDroppedDecoderThrow are 0 on both sides.
  • Queue/backpressure: no bridge drain wait, no queue-pressure drops, no stale drops, no link-unready drops, and no send failures. Bridge/binary high-water values are modest (7/7 on Side A, 4/3 on Side B).
  • Basic media establishment: both sides have room keys, inbound packets, decoded frames, active playouts, playback nodes, scheduler nodes, and live policy profiles.
  • Baseline: neither side is healthy-looking or clean-low-latency; this is not a low-latency baseline sounding bad.

Primary next target:

  • Another subsystem: authority/topology convergence and send-target selection after root/standby transition.
  • The receive profiles are not the first thing to tune from this call. The paired snapshots disagree on root authority, Side B has no standby and no forward recipients, and outbound no-target skips keep increasing during the sampled window. Fixing profile strength cannot repair a side that is not consistently targeting the peer.
  • Secondary follow-up after topology/send-target correctness: selector priority for buffered-not-ready should be checked, because Side B exports buffered-not-ready even though its current playout says jitterHasReadyFrame=true.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QTSzRS...9jMn receiving QP9Jj4...i6rP collapse-recovery yes 13.502 710 2172 0.190 0.185 recovery Profile mostly matches severe collapse, but current playout has jitterBufferedFrames=8 and jitterHasReadyFrame=false, so readiness is also implicated.
B root-forwarder / Linux / QP9Jj4...i6rP receiving QTSzRS...9jMn buffered-not-ready yes 6.484 1608 518 0.019 0.016 recovery Profile does not match the current readiness snapshot: jitterHasReadyFrame=true; metrics fit near-empty repair collapse better than buffered-not-ready.

Side A

Expected profile from symptom:

  • collapse-recovery, with a possible buffered-not-ready secondary because current playout has buffered frames but no ready frame.

Actual exported profile:

  • collapse-recovery

Did classification match?

  • Partly/yes.

Notes:

  • avgPcmBufferedMs=13.502, jitterBufferDepthFramesMean=0.684, avgPlayoutDeltaMs=-114.588, playoutUnderTargetFraction=0.190, playoutRateFractionBelow097=0.185, and concealmentTicks=2172 fit a real collapse symptom.
  • The readiness snapshot is still suspicious: jitterBufferedFrames=8 while jitterHasReadyFrame=false.
  • This side alone would support collapse-profile strength/readiness investigation, but the paired topology mismatch makes authority/send-target correctness the first target.

Side B

Expected profile from symptom:

  • repair-collapse or collapse-recovery.

Actual exported profile:

  • buffered-not-ready

Did classification match?

  • No/partly.

If no:

  • avgPcmBufferedMs=6.484, jitterBufferDepthFramesMean=0.328, avgPlayoutDeltaMs=-148.967, missingFrames=1608, and concealmentTicks=518 are too damaged for a pure buffered-not-ready label.
  • Current playout says jitterBufferedFrames=15 and jitterHasReadyFrame=true, so the exported profile is stale or winning for the wrong reason.
  • However, do not tune selector first from this side because the same export also reports topologyStandbyForwarder=null, forwardRecipientCount=0, flat outboundSendAttempts=7593, and outboundNoTargetSkips rising from 3855 to 4407.

Trend Read

Side A:

  • Flat-bad/degrading recovery collapse.
  • Reasons seen:
    • avgPcmBufferedMs falls from 14.336 to 13.502 ms.
    • concealmentTicks rises from 1997 to 2172.
    • playoutUnderTargetFraction rises from 0.186 to 0.190.
    • playoutRateFractionBelow097 rises from 0.181 to 0.185.
    • outboundNoTargetSkips is already high at 1423, though outbound sends still increase.

Side B:

  • Flat severe near-empty recovery with send-target failure signs.
  • Reasons seen:
    • avgPcmBufferedMs stays pinned around 6.3 to 6.5 ms.
    • missingFrames rises from 1493 to 1608.
    • concealmentTicks rises from 513 to 518.
    • outboundSendAttempts stays flat at 7593 across the whole sampled trend.
    • outboundNoTargetSkips rises from 3855 to 4407.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-07T18:57Z group-812 B / Linux root clean-low-latency yes no selector / false-clean repair pressure Covered by latest selector work; not the current post-change failure shape.
2026-05-07T19:25Z group-937 A / Linux root clean-low-latency yes no selector / false-clean repair pressure Covered by latest selector work; not the current post-change failure shape.
2026-05-07T19:48Z group-937 A / Linux root steady-weak-listener yes partly/no selector / repair-heavy escalation Still a valid selector refinement, but superseded by the 20:30Z topology/send-target failure.
2026-05-07T19:48Z group-937 B / Linux standby silent-lean yes no selector / repair-collapse escalation Still a valid selector refinement, but superseded by the 20:30Z topology/send-target failure.
2026-05-07T20:30Z group-937 A / Linux root epoch 3 collapse-recovery yes partly/yes authority/topology plus receive collapse Inspect topology convergence and readiness after root transition before profile strength.
2026-05-07T20:30Z group-937 B / Linux root epoch 4 buffered-not-ready yes no/partly authority/topology and send-target selection Fix root/standby convergence and outbound target selection; outboundNoTargetSkips is the strongest next signal.

Next Fix Target

Current patched target:

  • Another subsystem.
  • Primary fix: authority/topology convergence and outbound target selection after root/standby transition. The key evidence is the paired split-brain snapshot: both sides claim root-forwarder, they disagree on topologyRootForwarder, Side B has topologyStandbyForwarder=null, Side B has forwardRecipientCount=0, and Side B's outboundNoTargetSkips grows while outboundSendAttempts stays flat.
  • Secondary after that: selector priority around buffered-not-ready versus repair collapse, because Side B was currently ready but still labeled buffered-not-ready.
  • Do not tune baseline next. Do not tune profile strength first. The horrible symptom aligns better with topology/send-target failure plus severe receive collapse than with a too-weak receive profile.

Call: 2026-05-07 21:23Z / group 937

Room:

  • gcall-qortal-937

Files:

  • Side A: /home/qortal/Downloads/phil-kenny-one-on-one-111.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-07T21-23-20-156Z.json

User symptom:

  • New call following the latest changes. No separate subjective symptom text was included with the export, so user-bad is inferred from the severe receive metrics and recovery profiles.

High-level verdict:

  • Bad.
  • The previous authority/topology split is not reproduced here: both exports agree on epoch 3, root QTSzRS...9jMn, standby QP9Jj4...i6rP, and both sides have forward recipients. The remaining failure shape is receive-policy dominated: one side is correctly in collapse-recovery, while the other is still classified as silent-lean despite meaningful missing/concealment damage.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt=0, pendingDecryptDepth=0, and pending-decrypt high water is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure=0 and packetsDroppedDecoderThrow=0 on both sides.
  • Key/media establishment: both sides have room keys, inbound packets, decoded frames, active playouts, playback nodes, scheduler nodes, and live policy profiles.
  • Startup hidden playout nodes: both sides currently have jitterHasReadyFrame=true with active playback and scheduler nodes.
  • Queue/backpressure: no bridge drain wait, no queue-pressure drops, no stale drops, no link-unready drops, and no packet send failures. Queue high waters are bounded (48/8 on Side A, 2/14 on Side B).
  • Authority/topology convergence: unlike the 20:30Z call, both sides agree on root/standby at epoch 3. Side B has outboundNoTargetSkips=0; Side A has historical outboundNoTargetSkips=815, but it is flat across the sampled window while sends continue succeeding.

Primary next target:

  • Profile strength, with a secondary selector cleanup.
  • Side B says collapse-recovery classification is now correct, but the listener still lives around 7 ms buffered with heavy missing/concealment and sustained recovery mode. That points at collapse/recovery target boost, floor, and hold strength before baseline changes.
  • Side A says the selector should still escalate high-damage near-empty silent-lean into a collapse-class profile when missing/concealment counters are no longer mild. This is secondary because the paired call already proves the collapse profile itself is active on the worse side and still not sufficient.
  • Do not return to baseline first. Do not prioritize authority/send-target first from this sample.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QTSzRS...9jMn receiving QP9Jj4...i6rP silent-lean yes 3.991 931 473 0.025 0.014 recovery Near-empty and very negative delta fit silent-lean, but the damage counters are too high for the low-damage blind-spot shape.
B standby-forwarder / Linux / QP9Jj4...i6rP receiving QTSzRS...9jMn collapse-recovery yes 7.163 2628 1962 0.051 0.048 recovery Classification matches severe near-empty collapse, but quality remains bad under recovery protection.

Side A

Expected profile from symptom:

  • repair-collapse or collapse-recovery, with silent-lean only if damage counters are mild.

Actual exported profile:

  • silent-lean

Did classification match?

  • Partly/no.

If no:

  • avgPcmBufferedMs=3.991, jitterBufferDepthFramesMean=0.203, and avgPlayoutDeltaMs=-178.908 fit the near-empty silent-lean family.
  • However, missingFrames=931, concealmentTicks=473, and recovery mode mean this is no longer just a quiet low-damage lean blind spot.
  • Selector priority should promote near-empty ready paths out of silent-lean once repair damage is sustained.

Side B

Expected profile from symptom:

  • collapse-recovery.

Actual exported profile:

  • collapse-recovery.

Did classification match?

  • Yes.

Notes:

  • avgPcmBufferedMs=7.163, jitterBufferDepthFramesMean=0.363, avgPlayoutDeltaMs=-149.232, missingFrames=2628, concealmentTicks=1962, playoutUnderTargetFraction=0.051, and playoutRateFractionBelow097=0.048 fit severe receive collapse.
  • Because classification matched but quality still appears bad, tune collapse/recovery strength before changing baseline policy.

Trend Read

Side A:

  • Flat near-empty recovery with slow damage growth.
  • Reasons seen:
    • avgPcmBufferedMs stays pinned around 4.0 ms.
    • missingFrames rises from 918 to 931.
    • concealmentTicks rises from 468 to 473.
    • outboundNoTargetSkips remains flat at 815 while outbound successes increase, so this is not the 20:30Z no-target failure shape.

Side B:

  • Flat severe collapse under recovery.
  • Reasons seen:
    • avgPcmBufferedMs stays around 7.15 to 7.16 ms.
    • missingFrames rises from 2619 to 2628.
    • concealmentTicks rises from 1930 to 1962.
    • outboundNoTargetSkips remains 0 and outbound sends continue succeeding.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-07T18:57Z group-812 B / Linux root clean-low-latency yes no selector / false-clean repair pressure Covered by latest selector work; not the current post-change failure shape.
2026-05-07T19:25Z group-937 A / Linux root clean-low-latency yes no selector / false-clean repair pressure Covered by latest selector work; not the current post-change failure shape.
2026-05-07T19:48Z group-937 A / Linux root steady-weak-listener yes partly/no selector / repair-heavy escalation Still a valid selector refinement, but no longer the strongest target after the 21:23Z call.
2026-05-07T19:48Z group-937 B / Linux standby silent-lean yes no selector / repair-collapse escalation Still valid as the secondary selector cleanup for high-damage lean paths.
2026-05-07T20:30Z group-937 A / Linux root epoch 3 collapse-recovery yes partly/yes authority/topology plus receive collapse Topology/send-target was the best target for that call, but the 21:23Z pair does not reproduce the split.
2026-05-07T20:30Z group-937 B / Linux root epoch 4 buffered-not-ready yes no/partly authority/topology and send-target selection Superseded as primary by the converged 21:23Z call; keep as a regression watch.
2026-05-07T21:23Z group-937 A / Linux root epoch 3 silent-lean yes partly/no selector / high-damage lean escalation Secondary: promote near-empty ready silent-lean into collapse when missing/concealment damage is sustained.
2026-05-07T21:23Z group-937 B / Linux standby epoch 3 collapse-recovery yes yes receive profile strength / collapse recovery Primary: strengthen collapse/recovery target, floor, and hold behavior.

Next Fix Target

Current patched target:

  • Profile strength.
  • Primary fix: strengthen collapse-recovery behavior. The new call has converged topology, clean decrypt/decode/queue counters, active ready playouts, and a correctly classified collapse side that still remains near-empty with heavy repair damage.
  • Secondary fix: selector escalation from silent-lean to collapse-class profiles when near-empty ready paths have sustained missing/concealment counters. This should be done after or alongside collapse strength only if the change is tightly scoped.
  • Keep baseline unchanged. The evidence is not that normal low-latency baseline is bad; both sides are already in recovery-class behavior. Keep authority/send-target as a regression watch, but it is not the next fix target from this call.

Call: 2026-05-07 21:50Z / group 937

Room:

  • gcall-qortal-937

Files:

  • Side A: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-07T21-50-46-095Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-07T21-50-42-339Z.json

User symptom:

  • New call following the latest changes. User reported the first ~2 minutes were bad, then the call became better.

High-level verdict:

  • Mixed / improving, but not clean.
  • The paired exports agree on topology: root QeJW96...j5W9, standby QP9Jj4...i6rP, epoch 3, both with forward recipients and no no-target growth. The final sampled window is structurally healthy but still receive-policy dominated. Side A looks like residual weak-listener recovery; Side B is the miss: it reports clean-low-latency while its receive metrics still look near-empty and heavily repaired.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt=0, pendingDecryptDepth=0, and pending-decrypt high water is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure=0 and packetsDroppedDecoderThrow=0 on both sides.
  • Key/media establishment: both sides have room keys, inbound packets, decoded frames, active playouts, playback nodes, scheduler nodes, and live policy profiles.
  • Startup hidden playout nodes: both current playouts have jitterHasReadyFrame=true and active playback/scheduler nodes.
  • Queue/backpressure: no bridge drain wait, no queue-pressure drops, no stale drops, no link-unready drops, and no packet send failures. Queue high waters are bounded (7/5 on Side A, 2/8 on Side B), though decoded-queue old-age high water shows historical bursts (1685 ms on Side A, 684 ms on Side B).
  • Authority/topology/send-target: both sides agree on root/standby at epoch 3; outbound sends continue increasing; outboundNoTargetSkips=0 throughout the sampled window on both sides.

Primary next target:

  • Selector.
  • Side B is a current false-clean classification: clean-low-latency does not match avgPcmBufferedMs=5.636, jitterBufferDepthFramesMean=0.287, avgPlayoutDeltaMs=-147.227, missingFrames=3314, concealmentTicks=6499, playoutUnderTargetFraction=0.042, and playoutRateFractionBelow097=0.040.
  • Because the bad first minutes later improved, do not tune baseline broadly. The next fix should ensure ready near-empty/high-damage recovery paths cannot be surfaced as clean-low-latency; they should remain in repair-collapse/collapse-recovery or at least steady-weak-listener until reserve and damage actually clear.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QeJW96...j5W9 receiving QP9Jj4...i6rP steady-weak-listener partly/early 23.969 3396 220 0.008 0.006 recovery Classification is plausible for the later better phase: reserve is still shallow/moderate and missing grows slowly, but concealment and under-target pressure are low.
B standby-forwarder / Linux / QP9Jj4...i6rP receiving QeJW96...j5W9 clean-low-latency yes/early, partly current 5.636 3314 6499 0.042 0.040 recovery Classification is wrong: live profile says clean, but the path is near-empty with heavy repair damage and still in recovery.

Side A

Expected profile from symptom:

  • steady-weak-listener or possibly repair-heavy-connected during the early bad phase; steady-weak-listener is reasonable for the later improved phase.

Actual exported profile:

  • steady-weak-listener

Did classification match?

  • Partly/yes.

Notes:

  • The final sampled window is not clean, but it is much better than the previous collapse shape: avgPcmBufferedMs=23.969, jitterBufferDepthFramesMean=1.215, concealmentTicks=220, playoutUnderTargetFraction=0.008, and playoutRateFractionBelow097=0.006.
  • missingFrames is still high cumulatively and rises from 3360 to 3396 across the final ~11 seconds, so this is still weak/residual recovery rather than clean-low-latency.

Side B

Expected profile from symptom:

  • repair-collapse or collapse-recovery; steady-weak-listener would be the weakest acceptable fallback only after reserve rebuilds.

Actual exported profile:

  • clean-low-latency

Did classification match?

  • No.

If no:

  • avgPcmBufferedMs=5.636, jitterBufferDepthFramesMean=0.287, and avgPlayoutDeltaMs=-147.227 are near-empty collapse signals.
  • missingFrames=3314, concealmentTicks=6499, playoutUnderTargetFraction=0.042, and playoutRateFractionBelow097=0.040 are not compatible with a clean profile.
  • Tune selector/clear logic so a ready but near-empty high-damage recovery path cannot clear to clean-low-latency until reserve and repair pressure have actually recovered.

Trend Read

Side A:

  • Flat weak recovery in the sampled end window.
  • Reasons seen:
    • avgPcmBufferedMs stays around 23.97 ms.
    • concealmentTicks stays flat at 220.
    • missingFrames rises slowly from 3360 to 3396.
    • outboundNoTargetSkips remains 0.

Side B:

  • Flat near-empty recovery despite clean profile.
  • Reasons seen:
    • avgPcmBufferedMs stays pinned around 5.64 ms.
    • missingFrames rises from 3280 to 3314.
    • concealmentTicks rises from 6411 to 6499.
    • playoutUnderTargetFraction and playoutRateFractionBelow097 remain elevated at 0.042 and 0.040.
    • outboundNoTargetSkips remains 0.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-07T18:57Z group-812 B / Linux root clean-low-latency yes no selector / false-clean repair pressure Covered by earlier selector work; keep as historical false-clean baseline.
2026-05-07T19:25Z group-937 A / Linux root clean-low-latency yes no selector / false-clean repair pressure Covered by earlier selector work; keep as historical false-clean baseline.
2026-05-07T19:48Z group-937 A / Linux root steady-weak-listener yes partly/no selector / repair-heavy escalation Still a valid secondary selector refinement.
2026-05-07T19:48Z group-937 B / Linux standby silent-lean yes no selector / repair-collapse escalation Covered by the high-damage lean escalation target.
2026-05-07T20:30Z group-937 A / Linux root epoch 3 collapse-recovery yes partly/yes authority/topology plus receive collapse Keep as regression watch; not reproduced in later converged calls.
2026-05-07T20:30Z group-937 B / Linux root epoch 4 buffered-not-ready yes no/partly authority/topology and send-target selection Keep as regression watch; later calls have converged topology and no no-target growth.
2026-05-07T21:23Z group-937 A / Linux root epoch 3 silent-lean yes partly/no selector / high-damage lean escalation Addressed by promoting high-damage near-empty ready paths out of silent-lean.
2026-05-07T21:23Z group-937 B / Linux standby epoch 3 collapse-recovery yes yes receive profile strength / collapse recovery Addressed by strengthening collapse target/floor/hold; verify with later exports.
2026-05-07T21:50Z group-937 A / Linux root epoch 3 steady-weak-listener partly/early partly/yes receive / residual weak recovery Watch; no immediate profile-strength change from this side.
2026-05-07T21:50Z group-937 B / Linux standby epoch 3 clean-low-latency yes/early, partly current no selector / false-clean near-empty repair collapse Primary: prevent clean-low-latency while ready near-empty damage and recovery pressure remain active.

Next Fix Target

Current patched target:

  • Selector.
  • Primary fix: tighten clean-low-latency clear/entry so it cannot win for ready near-empty listeners with strong negative delta, ongoing recovery mode, and sustained missing/concealment pressure. The 21:50Z standby export is the clearest signal: the call subjectively improved, but the profile exported as clean while the buffer and damage metrics still describe repair collapse.
  • Secondary: keep the recent collapse-strength patch and high-damage silent-lean escalation; this call does not argue for a broader baseline increase because one side improved to a plausible steady-weak-listener shape and the infrastructure/path counters are clean.
  • Do not prioritize authority/topology, key/decode, startup, or global baseline from this pair.

Call: 2026-05-08 10:48Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-08T10-48-20-638Z.json
  • Side B: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-08T10-48-23-113Z.json

User symptom:

  • New call following the latest changes. No separate subjective symptom text was included with the export, so user-bad is inferred from the receive metrics, recovery mode, and profile churn.

High-level verdict:

  • Mixed / still not clean.
  • The previous topology and no-target failures are not present: both exports agree on room gcall-qortal-812, root QP9Jj4...i6rP, standby QaU2XU...Jh91, and epoch 3; both sides have active ready playouts, decoded packets, room keys, forward recipients, and no outbound no-target growth. The remaining shape is receive-policy instability: the Linux root is mostly weak/recovery but briefly clears to low-latency while still under target, and the Mac standby lives in lean profiles with recovery still active.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt=0, pendingDecryptDepth=0, and pending-decrypt high water is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure=0 and packetsDroppedDecoderThrow=0 on both sides.
  • Key/media establishment: both sides have room keys, inbound packets, decoded frames, active playback nodes, active scheduler nodes, and live receive-policy profiles.
  • Startup hidden playout nodes: current playouts are active and ready on both sides; Side A has jitterHasReadyFrame=true, and Side B exports jitterHasReadyFrame=true with only one recent not-ready trend sample.
  • Queue/backpressure: no bridge drain wait, queue-pressure drops, stale drops, link-unready drops, or packet send failures. Queue high waters are bounded (7/2 on Side A, 2/44 on Side B).
  • Authority/topology/send-target: both sides agree on root/standby at epoch 3; outbound sends keep succeeding; outboundNoTargetSkips=0 throughout the sampled window on both sides.

Primary next target:

  • Selector.
  • More specifically, profile stability / clean-clear gating. Side A oscillates between steady-weak-listener, repair-heavy-connected, persistent-lean, buffered-not-ready, and even clean-low-latency while playoutUnderTargetFraction=0.115, playoutRateFractionBelow097=0.075, recovery keeps re-entering, and missing frames continue growing. Side B is dominated by lean profiles with a very shallow buffer (11.542 ms) and recovery mode still active.
  • Do not tune baseline next. This is not evidence that ordinary low-latency baseline is too small; the receive engine is already detecting weak/lean/recovery conditions most of the time. Do not return to authority/topology or key/decode from this pair.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 steady-weak-listener partly/inferred 35.493 689 131 0.115 0.075 recovery Dominant profile is plausible for weak recovery, but recent trends show premature low-latency clears and rapid profile oscillation while under-target pressure remains high.
B standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP persistent-lean partly/inferred 11.542 535 47 0.011 0.007 recovery Lean classification is mostly plausible: buffer is shallow, delta is strongly negative, and recovery remains active; damage is moderate rather than collapse-heavy.

Side A

Expected profile from symptom:

  • steady-weak-listener or repair-heavy-connected, with no clean-low-latency until under-target and recovery pressure clear.

Actual exported profile:

  • Dominant sampled profile: steady-weak-listener.
  • Current exported profile: persistent-lean.
  • Recent trends also include buffered-not-ready, repair-heavy-connected, and one clean-low-latency sample.

Did classification match?

  • Partly.

If no:

  • The dominant profile is directionally right: avgPcmBufferedMs=35.493, missingFrames=689, concealmentTicks=131, and recovery mode fit weak/repaired audio rather than a clean path.
  • The miss is selector stability and clear logic. A side with playoutUnderTargetFraction=0.115, playoutRateFractionBelow097=0.075, repeated entered-recovery, and growing missing frames should not briefly clear to clean-low-latency, and it should not flip between weak/repair/lean profiles every few dozen milliseconds.

Side B

Expected profile from symptom:

  • persistent-lean or silent-lean; possibly repair-collapse only during short near-empty damage bursts.

Actual exported profile:

  • Dominant sampled profile: persistent-lean.
  • Current exported profile: silent-lean.

Did classification match?

  • Mostly/partly.

Notes:

  • avgPcmBufferedMs=11.542, jitterBufferDepthFramesMean=0.584, avgPlayoutDeltaMs=-119.279, and recovery mode fit lean-listener behavior.
  • missingFrames=535 is no longer a completely quiet blind-spot shape, but concealmentTicks=47, playoutUnderTargetFraction=0.011, and playoutRateFractionBelow097=0.007 are milder than the earlier collapse samples. This does not justify a new profile or a broad baseline change.

Trend Read

Side A:

  • Oscillating weak recovery.
  • Reasons seen:
    • Profile samples include clean-low-latency, collapse-recovery, steady-weak-listener, repair-heavy-connected, repair-collapse, persistent-lean, and buffered-not-ready.
    • Recent window flips from buffered-not-ready to steady-weak-listener, briefly to clean-low-latency, then back through repair-heavy-connected / steady-weak-listener.
    • missingFrames rises from 599 to 689 in the final sampled window, with entered-recovery appearing twice.
    • outboundNoTargetSkips remains 0, so this is not a send-target failure.

Side B:

  • Gradual/flat lean recovery with a late not-ready blip.
  • Reasons seen:
    • avgPcmBufferedMs stays around 11.35 to 11.58 ms.
    • missingFrames rises from 492 to 535; concealmentTicks is nearly flat from 46 to 47.
    • Profile stays mostly persistent-lean, then flips to silent-lean near the end.
    • One recent trend has jitterHasReadyFrame=false, but the export currently has ready playout and no startup/path failure.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-07T18:57Z group-812 B / Linux root clean-low-latency yes no selector / false-clean repair pressure Covered by earlier selector work; keep as historical false-clean baseline.
2026-05-07T19:25Z group-937 A / Linux root clean-low-latency yes no selector / false-clean repair pressure Covered by earlier selector work; keep as historical false-clean baseline.
2026-05-07T19:48Z group-937 A / Linux root steady-weak-listener yes partly/no selector / repair-heavy escalation Still a valid secondary selector refinement.
2026-05-07T19:48Z group-937 B / Linux standby silent-lean yes no selector / repair-collapse escalation Covered by the high-damage lean escalation target.
2026-05-07T20:30Z group-937 A / Linux root epoch 3 collapse-recovery yes partly/yes authority/topology plus receive collapse Keep as regression watch; not reproduced in later converged calls.
2026-05-07T20:30Z group-937 B / Linux root epoch 4 buffered-not-ready yes no/partly authority/topology and send-target selection Keep as regression watch; later calls have converged topology and no no-target growth.
2026-05-07T21:23Z group-937 A / Linux root epoch 3 silent-lean yes partly/no selector / high-damage lean escalation Addressed by promoting high-damage near-empty ready paths out of silent-lean.
2026-05-07T21:23Z group-937 B / Linux standby epoch 3 collapse-recovery yes yes receive profile strength / collapse recovery Addressed by strengthening collapse target/floor/hold; verify with later exports.
2026-05-07T21:50Z group-937 A / Linux root epoch 3 steady-weak-listener partly/early partly/yes receive / residual weak recovery Watch; no immediate profile-strength change from this side.
2026-05-07T21:50Z group-937 B / Linux standby epoch 3 clean-low-latency yes/early, partly current no selector / false-clean near-empty repair collapse Primary: prevent clean-low-latency while ready near-empty damage and recovery pressure remain active.
2026-05-08T10:48Z group-812 A / Linux root epoch 3 steady-weak-listener partly/inferred partly selector / profile oscillation and premature clean clear Primary: add hysteresis/clear gating so weak or repair-heavy recovery cannot briefly clear to clean while under-target/rate pressure remains high.
2026-05-08T10:48Z group-812 B / Mac standby epoch 3 persistent-lean partly/inferred mostly/partly receive / lean recovery Watch; no baseline or new-profile change from this side.

Next Fix Target

Current patched target:

  • Selector.
  • Primary fix: stabilize receive-profile selection and clean-clear gating. The latest pair no longer shows dominant false-clean collapse, topology split, key/decode failure, or startup failure. It shows the selector still bouncing between profiles and occasionally allowing clean-low-latency during active under-target/recovery pressure.
  • Target the clear/hold logic around steady-weak-listener, repair-heavy-connected, persistent-lean, and clean-low-latency: once recovery is active and under-target/rate pressure remains elevated, require a sustained quiet window before clearing to clean, and avoid per-tick oscillation between weak/repair/lean profiles.
  • Keep profile strength and baseline unchanged from this call. Side B's lean classification mostly matches its metrics, and Side A's problem is not that one profile is too weak; it is that the selector does not stay in the appropriate recovery class long enough.

Call: 2026-05-08 12:06Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-08T12-06-52-922Z.json
  • Side B: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-08T12-06-55-383Z.json

User symptom:

  • New call following the latest changes. No separate subjective symptom text was included with the export, so user-bad is inferred from receive metrics, recovery mode, and profile churn.

High-level verdict:

  • Mixed / still weak, with better classification than earlier false-clean calls.
  • Both exports agree on room gcall-qortal-812, root QP9Jj4...i6rP, standby QaU2XU...Jh91, and epoch 1. There is no key/decode/startup/send-target failure. The Linux root still shows selector oscillation and one brief clean clear, but the Mac standby is now classified into lean/recovery profiles while remaining almost empty for the whole sampled window.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt=0, pendingDecryptDepth=0, and pending-decrypt high water is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure=0 and packetsDroppedDecoderThrow=0 on both sides.
  • Key/media establishment: both sides have room keys, inbound packets, decoded frames, active playback nodes, active scheduler nodes, and live receive-policy profiles.
  • Startup hidden playout nodes: current playouts are active and ready on both sides; jitterHasReadyFrame=true in the current playouts.
  • Queue/backpressure: no bridge drain wait, no queue-pressure drops, no stale drops, no link-unready drops, and no packet send failures. Queue high waters are bounded.
  • Authority/topology/send-target: both sides agree on root/standby at epoch 1; outbound sends keep succeeding; outboundNoTargetSkips=0 throughout both sampled windows.

Primary next target:

  • Profile strength, focused on persistent-lean / lean recovery behavior.
  • Side B is the clearest new evidence: classification is mostly correct, but persistent-lean dominates 47 of 59 samples while avgPcmBufferedMs only reaches 2.243 ms, avgPlayoutDeltaMs=-182.757, recovery mode remains active, and missing frames rise steadily to 160. The profile applied strong target/floor values (lastAppliedTargetMs=204, lastAppliedFloorMs=192), but the listener still did not build usable PCM reserve.
  • Selector stability is still a secondary issue on Side A because it briefly clears to clean-low-latency while under-target/rate pressure and missing-frame growth continue. This new pair does not point to baseline, key/decode, startup, authority, or a new profile.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 steady-weak-listener partly/inferred 33.524 302 54 0.135 0.053 recovery Directionally plausible weak/repaired classification, but the selector still oscillates and briefly clears to clean while pressure remains active.
B standby-forwarder / Mac / QaU2XU...Jh91 receiving QP9Jj4...i6rP persistent-lean yes/inferred 2.243 160 0 0.002 0.000 recovery Classification matches a lean listener, but the profile is not strong enough or not effective enough to rebuild reserve.

Side A

Expected profile from symptom:

  • steady-weak-listener, repair-heavy-connected, or short repair-collapse during the worst windows; no sustained clean-low-latency until under-target/rate pressure clears.

Actual exported profile:

  • Dominant sampled profile: steady-weak-listener.
  • Current exported profile: steady-weak-listener.
  • Recent trends also include clean-low-latency, repair-collapse, and repair-heavy-connected.

Did classification match?

  • Partly.

If no:

  • The dominant profile is directionally right: avgPcmBufferedMs=33.524, missingFrames=302, concealmentTicks=54, playoutUnderTargetFraction=0.135, playoutRateFractionBelow097=0.053, and recovery mode fit weak/repaired audio rather than a clean path.
  • The miss is still selector stability. At 1778242004446, the side reports clean-low-latency while playoutUnderTargetFraction=0.135, playoutRateFractionBelow097=0.058, and missingFramesDelta=10; one second later it re-enters recovery and then repair profiles.

Side B

Expected profile from symptom:

  • persistent-lean or silent-lean; repair-collapse is acceptable only for short missing-frame bursts.

Actual exported profile:

  • Dominant sampled profile: persistent-lean.
  • Current exported profile: persistent-lean.
  • Recent summary also includes short silent-lean and repair-collapse periods.

Did classification match?

  • Mostly/yes.

Notes:

  • avgPcmBufferedMs=2.243, jitterBufferDepthFramesMean=0.114, avgPlayoutDeltaMs=-182.757, and recovery mode are exactly lean-listener signals.
  • This is no longer a false-clean classification. The problem is that the correct lean profile stays active but does not produce enough reserve; missingFrames rises by about 3 per second in the final trend samples even though concealmentTicks=0.
  • The very fast transitions between persistent-lean, silent-lean, steady-weak-listener, and occasional repair-collapse are worth watching, but the dominant symptom is profile effectiveness rather than selector recognition.

Trend Read

Side A:

  • Oscillating weak recovery with a premature low-latency clear.
  • Reasons seen:
    • Final window includes steady-weak-listener, clean-low-latency, repair-collapse, and repair-heavy-connected.
    • missingFrames rises from 240 to 302 in the final ~11 seconds.
    • playoutUnderTargetFraction remains around 0.135 and playoutRateFractionBelow097 around 0.053.
    • entered-recovery appears immediately after the clean/low-latency blip.

Side B:

  • Flat persistent lean.
  • Reasons seen:
    • avgPcmBufferedMs stays around 2.18 to 2.24 ms through the final sampled window.
    • missingFrames rises from 126 to 160 in the final ~11 seconds.
    • concealmentTicks stays at 0, so this is lean/missing-frame pressure rather than repair-heavy concealment.
    • persistent-lean dominates the export, with recovery mode active for 58 of 59 samples.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-07T18:57Z group-812 B / Linux root clean-low-latency yes no selector / false-clean repair pressure Covered by earlier selector work; keep as historical false-clean baseline.
2026-05-07T19:25Z group-937 A / Linux root clean-low-latency yes no selector / false-clean repair pressure Covered by earlier selector work; keep as historical false-clean baseline.
2026-05-07T19:48Z group-937 A / Linux root steady-weak-listener yes partly/no selector / repair-heavy escalation Still a valid secondary selector refinement.
2026-05-07T19:48Z group-937 B / Linux standby silent-lean yes no selector / repair-collapse escalation Covered by the high-damage lean escalation target.
2026-05-07T20:30Z group-937 A / Linux root epoch 3 collapse-recovery yes partly/yes authority/topology plus receive collapse Keep as regression watch; not reproduced in later converged calls.
2026-05-07T20:30Z group-937 B / Linux root epoch 4 buffered-not-ready yes no/partly authority/topology and send-target selection Keep as regression watch; later calls have converged topology and no no-target growth.
2026-05-07T21:23Z group-937 A / Linux root epoch 3 silent-lean yes partly/no selector / high-damage lean escalation Addressed by promoting high-damage near-empty ready paths out of silent-lean.
2026-05-07T21:23Z group-937 B / Linux standby epoch 3 collapse-recovery yes yes receive profile strength / collapse recovery Addressed by strengthening collapse target/floor/hold; verify with later exports.
2026-05-07T21:50Z group-937 A / Linux root epoch 3 steady-weak-listener partly/early partly/yes receive / residual weak recovery Watch; no immediate profile-strength change from this side.
2026-05-07T21:50Z group-937 B / Linux standby epoch 3 clean-low-latency yes/early, partly current no selector / false-clean near-empty repair collapse Primary: prevent clean-low-latency while ready near-empty damage and recovery pressure remain active.
2026-05-08T10:48Z group-812 A / Linux root epoch 3 steady-weak-listener partly/inferred partly selector / profile oscillation and premature clean clear Primary: add hysteresis/clear gating so weak or repair-heavy recovery cannot briefly clear to clean while under-target/rate pressure remains high.
2026-05-08T10:48Z group-812 B / Mac standby epoch 3 persistent-lean partly/inferred mostly/partly receive / lean recovery Watch; no baseline or new-profile change from this side.
2026-05-08T12:06Z group-812 A / Linux root epoch 1 steady-weak-listener partly/inferred partly selector / profile oscillation and premature clean clear Secondary: keep clean-clear gating and profile hysteresis work, but do not make this the primary target from this pair.
2026-05-08T12:06Z group-812 B / Mac standby epoch 1 persistent-lean yes/inferred mostly/yes receive profile strength / persistent lean Primary: strengthen or fix effective reserve-building for persistent-lean / lean recovery; classification is no longer the main miss.

Next Fix Target

Current patched target:

  • Profile strength, specifically persistent-lean / lean recovery effectiveness.
  • Primary fix: make a correctly classified lean listener actually accumulate usable reserve. This pair shows the Mac standby stuck near empty (avgPcmBufferedMs=2.243, avgPlayoutDeltaMs=-182.757) while persistent-lean dominates and recovery mode is active almost the whole export. That argues for stronger lean target/floor/hold behavior or a bug in how lean targets translate into downstream PCM reserve.
  • Secondary fix: keep tightening selector hysteresis/clean-clear gating. The Linux root still briefly clears to clean-low-latency while under-target and missing-frame pressure remain active, but the dominant new failure is not a false-clean side.
  • Keep baseline unchanged. This is not evidence that ordinary low-latency baseline is too small; both sides are in recovery/weak/lean logic most of the time.
  • Do not prioritize key/decode, startup, authority/topology, send-target, or a new profile from this pair.

Call: 2026-05-08 21:17Z / group 937

Room:

  • gcall-qortal-937

Files:

  • Side A: /home/qortal/Downloads/phil-kenny-one-on-one-113.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-08T21-17-05-597Z.json

User symptom:

  • Call was good at times, but choppy at other times.

High-level verdict:

  • Mixed / intermittently choppy, but structurally cleaner than the previous broken-link sample.
  • Both exports agree on room gcall-qortal-937, call session 04ea73fc-6b3c-40b2-8d0b-e5492139a0bc, topology epoch 4, root QTSzRS...9jMn, and standby QP9Jj4...i6rP. Both sides are on established Reticulum link transport at export. The call had good stretches, but recurring missing-frame and concealment bursts caused audible chop; the remaining failure is receive-policy behavior after those bursts.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt=0, pendingDecryptDepth=0, and pending-decrypt high water is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure=0 and packetsDroppedDecoderThrow=0 on both sides.
  • Link collapse: both sides export reticulumAudioOutboundTransportLast=link, reticulumAudioInboundTransportLast=link, linkEstablished=true, and packetSendFailures=0.
  • Queue/backpressure: no bridge drain wait, no queue-pressure drops, no link-unready drops, and small binary high waters (2 on both sides). Root bridge high water reaches 14, but without drain wait or drops.
  • Startup hidden playout: both sides have active playback/scheduler nodes, shared rings, active jitter, and current jitterHasReadyFrame=true.
  • Authority/topology: both sides agree on epoch 4, root/standby, room key state, and participant count.
  • Baseline: neither side is spending meaningful time in clean-low-latency; both are already in recovery/weak/lean/collapse logic.

Primary next target:

  • Selector, specifically damage-hold / escalation hysteresis between steady-weak-listener, silent-lean, repair-collapse, and collapse-recovery.
  • The previous persistent-lean strength target is less supported by this pair: neither side is the near-empty 2 ms reserve shape from the prior Mac sample. Instead, both sides have moderate current reserve (16.353 ms and 12.397 ms) but suffer repeated large missing-frame/concealment bursts while the dominant profile drops back to silent-lean or steady-weak-listener.
  • Do not change the global baseline from this call. Do not add a new profile yet; this still fits existing repair/collapse/lean classes, but the selector is not latching the damage class consistently after bursts.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QTSzRS...9jMn receiving QP9Jj4...i6rP silent-lean yes/inferred 16.353 1833 454 0.035 0.029 recovery Current profile is silent-lean, but the window includes heavy collapse/repair evidence and large late missing-frame bursts. Classification is only partly correct.
B standby-forwarder / Linux / QP9Jj4...i6rP receiving QTSzRS...9jMn steady-weak-listener yes/inferred 12.397 2840 344 0.030 0.024 recovery Current profile is repair-collapse, but dominant window profile is steady-weak-listener; that under-holds the damage class after repeated spikes.

Side A

Expected profile from symptom:

  • repair-collapse or collapse-recovery during concealment runs; repair-heavy-connected or steady-weak-listener only after a sustained quiet window. silent-lean fits some current low-damage/lean windows, but not the whole sampled symptom.

Actual exported profile:

  • Dominant sampled profile: silent-lean (87 samples).
  • Other significant samples: steady-weak-listener (61), collapse-recovery (56), buffered-not-ready (11), repair-collapse (9).
  • Current exported profile: silent-lean.

Did classification match?

  • Partly/no.

Notes:

  • The side is no longer false-clean, which is good.
  • But missingFrames=1833, concealmentTicks=454, and a late burst from 1112 to 1762 missing frames over about three seconds are too damaged to let silent-lean dominate without a stronger damage hold.
  • Final ready state is healthy enough to avoid startup classification: jitterBufferedFrames=22, jitterHasReadyFrame=true, playback and scheduler active.

Side B

Expected profile from symptom:

  • repair-collapse during the worst missing-frame spikes, with a held repair/collapse class until the damage quiets. steady-weak-listener is reasonable only for the quieter intervals.

Actual exported profile:

  • Dominant sampled profile: steady-weak-listener (110 samples).
  • Other significant samples: collapse-recovery (51), repair-heavy-connected (9), repair-collapse (8).
  • Current exported profile: repair-collapse.

Did classification match?

  • Partly.

Notes:

  • Current classification is right: live state is repair-collapse, with bufferedMsEma=1.390, deltaMsEma=-183.610, and repair/collapse holds active.
  • Dominant classification is too weak for the whole call: the side reaches missingFrames=2840, concealmentTicks=344, and has a major final-window spike of 385 missing frames followed by 249, 29, and 49.
  • This argues for selector/hold behavior, not a new profile: the existing repair/collapse labels are appearing, but not winning consistently enough across burst aftermath.

Trend Read

Side A:

  • Oscillating damage recovery with late burst.
  • Reasons seen:
    • The window moves through collapse-recovery, silent-lean, and steady-weak-listener.
    • Concealment climbs steadily by about 8 ticks per second during a collapse run from 1778274988989 to 1778275001112.
    • Immediately afterward, missing frames jump 126, then 294, then 230 while profiles are silent-lean / steady-weak-listener.
    • Final seconds look quieter but still add small missing-frame deltas while current profile remains silent-lean.

Side B:

  • Oscillating weak/collapse recovery with repeated missing-frame bursts.
  • Reasons seen:
    • steady-weak-listener dominates, but collapse-recovery repeatedly appears around concealment runs.
    • The largest late spike is 385 missing frames, followed by 249, then smaller bursts.
    • Current profile ends at repair-collapse, which matches the live damaged state, but it arrived late relative to the dominant sampled behavior.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-07T18:57Z group-812 B / Linux root clean-low-latency yes no selector / false-clean repair pressure Covered by earlier selector work; keep as historical false-clean baseline.
2026-05-07T19:25Z group-937 A / Linux root clean-low-latency yes no selector / false-clean repair pressure Covered by earlier selector work; keep as historical false-clean baseline.
2026-05-07T19:48Z group-937 A / Linux root steady-weak-listener yes partly/no selector / repair-heavy escalation Still a valid secondary selector refinement.
2026-05-07T19:48Z group-937 B / Linux standby silent-lean yes no selector / repair-collapse escalation Covered by the high-damage lean escalation target.
2026-05-07T20:30Z group-937 A / Linux root epoch 3 collapse-recovery yes partly/yes authority/topology plus receive collapse Keep as regression watch; not reproduced in later converged calls.
2026-05-07T20:30Z group-937 B / Linux root epoch 4 buffered-not-ready yes no/partly authority/topology and send-target selection Keep as regression watch; later calls have converged topology and no no-target growth.
2026-05-07T21:23Z group-937 A / Linux root epoch 3 silent-lean yes partly/no selector / high-damage lean escalation Addressed by promoting high-damage near-empty ready paths out of silent-lean.
2026-05-07T21:23Z group-937 B / Linux standby epoch 3 collapse-recovery yes yes receive profile strength / collapse recovery Addressed by strengthening collapse target/floor/hold; verify with later exports.
2026-05-07T21:50Z group-937 A / Linux root epoch 3 steady-weak-listener partly/early partly/yes receive / residual weak recovery Watch; no immediate profile-strength change from this side.
2026-05-07T21:50Z group-937 B / Linux standby epoch 3 clean-low-latency yes/early, partly current no selector / false-clean near-empty repair collapse Primary: prevent clean-low-latency while ready near-empty damage and recovery pressure remain active.
2026-05-08T10:48Z group-812 A / Linux root epoch 3 steady-weak-listener partly/inferred partly selector / profile oscillation and premature clean clear Primary: add hysteresis/clear gating so weak or repair-heavy recovery cannot briefly clear to clean while under-target/rate pressure remains high.
2026-05-08T10:48Z group-812 B / Mac standby epoch 3 persistent-lean partly/inferred mostly/partly receive / lean recovery Watch; no baseline or new-profile change from this side.
2026-05-08T12:06Z group-812 A / Linux root epoch 1 steady-weak-listener partly/inferred partly selector / profile oscillation and premature clean clear Secondary: keep clean-clear gating and profile hysteresis work, but do not make this the primary target from this pair.
2026-05-08T12:06Z group-812 B / Mac standby epoch 1 persistent-lean yes/inferred mostly/yes receive profile strength / persistent lean Prior primary target; this new call weakens it as the next single fix because the latest failure is not near-empty persistent lean.
2026-05-08T21:17Z group-937 A / Linux root epoch 4 silent-lean yes/inferred partly/no selector / damage hold after collapse burst Primary: keep repair/collapse damage latched after concealment and large missing-frame bursts; do not let silent-lean dominate until quiet.
2026-05-08T21:17Z group-937 B / Linux standby epoch 4 steady-weak-listener yes/inferred partly selector / repair-collapse escalation hold Primary: hold repair-collapse or collapse-recovery through burst aftermath instead of falling back to steady-weak-listener too quickly.

Next Fix Target

Current patched target:

  • Selector.
  • Primary fix: add damage hysteresis so recent large missingFramesDelta bursts keep the side in repair-collapse or repair-heavy-connected for a sustained quiet window before allowing steady-weak-listener or silent-lean. Keep relying on the existing concealment/collapse gates for concealment-only runs.
  • This is not the old false-clean problem: clean-low-latency is essentially gone from this pair. It is the neighboring-profile problem: the engine recognizes damage briefly, then lets weaker lean/steady profiles win too soon.
  • Keep profile strength as secondary. If the selector holds repair/collapse correctly and the call still sounds bad with those profiles dominant, then tune target/floor/hold strength next.
  • Keep baseline unchanged and do not prioritize key/decode/startup/authority/link transport from this pair.

Call: 2026-05-08 22:10Z / group 937

Room:

  • gcall-qortal-937

Files:

  • Side A: /home/qortal/Downloads/phil-kenny-one-on-one-114.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-08T22-09-59-546Z.json

User symptom:

  • New post-change call for validation. No explicit subjective symptom was included with the export; classify as residual badness if profiles and window deltas still show choppy/repaired audio.

High-level verdict:

  • Mixed / still policy-damaged, but cleaner than the previous burst-heavy export.
  • Both exports agree on room gcall-qortal-937, call session 805e2ff1-6b01-4ec1-9d96-b8919b2005d6, topology epoch 10, root QTSzRS...9jMn, and standby QP9Jj4...i6rP. There is no false-clean profile and no correctness/startup failure, but both sides remain in recovery for all 300 recent samples while missing frames continue to accumulate.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt=0, pendingDecryptDepth=0, and pending-decrypt high water is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure=0 and packetsDroppedDecoderThrow=0 on both sides.
  • Link collapse: both sides export link transport for inbound and outbound audio, with reticulumAudioPacketSendFailures=0.
  • Queue/backpressure: reticulumAudioBridgeWaitingForDrain=false, no queue-pressure drops, no stale drops, no link-unready drops, and binary queue high water is only 2 on both sides. Side A bridge high water reaches 15, but without drain wait or drops.
  • Startup hidden playout: both sides have active playback/scheduler nodes, shared rings, active jitter, and current jitterHasReadyFrame=true.
  • Authority/topology: both sides agree on epoch 10, root/standby, room key state, participant count, and call session.
  • Baseline: neither side is classified as clean-low-latency; both are already in recovery/lean/repair logic.

Primary next target:

  • Selector, specifically lean/repair damage classification and hold behavior.
  • This call reinforces the previous selector target rather than shifting to baseline or generic profile strength. Side A ends in repair-collapse and has many repair/collapse samples, but silent-lean is still the dominant window profile. Side B is more clearly under-classified: silent-lean dominates 224 of 300 samples despite missingFrames=3940, concealmentTicks=220, totalMissingFramesDelta=1187, and several recent missing-frame bursts.
  • The correct profiles are present, so this is not a new-profile case. The issue is that silent-lean and persistent-lean still win too often between damage bursts, especially when concealment is low but missing-frame damage keeps rising.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QTSzRS...9jMn receiving QP9Jj4...i6rP silent-lean yes/inferred 9.274 2340 267 0.013 0.005 recovery Current profile is repair-collapse; dominant window profile is still too lean for sustained repair damage.
B standby-forwarder / Linux / QP9Jj4...i6rP receiving QTSzRS...9jMn silent-lean yes/inferred 13.345 3940 220 0.006 0.004 recovery silent-lean dominates even though missing-frame damage remains high and recent bursts continue.

Side A

Expected profile from symptom:

  • repair-collapse or collapse-recovery during shallow/damaged windows, with repair-heavy-connected acceptable when buffered but still repaired. silent-lean should only dominate after a sustained quiet window.

Actual exported profile:

  • Dominant sampled profile: silent-lean (103 samples).
  • Other significant samples: repair-collapse (64), persistent-lean (60), steady-weak-listener (48), collapse-recovery (17), repair-heavy-connected (7).
  • Current exported profile: repair-collapse.

Did classification match?

  • Partly.

Notes:

  • Current classification is right: live state is repair-collapse, with bufferedMsEma=4.621, deltaMsEma=-180.379, lastAppliedTargetMs=240, and repair/collapse holds still active.
  • The dominant profile is still too weak for the whole window. The side has missingFrames=2340, concealmentTicks=267, totalMissingFramesDelta=987, and totalConcealmentTicksDelta=85.
  • Final trend is less explosive than the prior call, but it is not clean: missing frames continue to climb by small deltas almost every second, with a final missingFramesDelta=10, while recovery remains active.

Side B

Expected profile from symptom:

  • repair-collapse during missing-frame bursts, or persistent-lean only as a secondary lean state once damage is quiet. silent-lean should not dominate a window with this much accumulated and ongoing missing-frame damage.

Actual exported profile:

  • Dominant sampled profile: silent-lean (224 samples).
  • Other samples: repair-collapse (61), persistent-lean (13), collapse-recovery (2).
  • Current exported profile: silent-lean.

Did classification match?

  • No/partly.

Notes:

  • The side is not false-clean, but silent-lean is too soft for missingFrames=3940, concealmentTicks=220, and totalMissingFramesDelta=1187.
  • Several bad one-second windows are still classified below the damage class: missingFramesDelta=32 under silent-lean, 54 under persistent-lean, then later 21 and 27 under repair-collapse.
  • Current state has lastAppliedTargetMs=204 and lastAppliedFloorMs=192, which is weaker than Side A's repair-collapse target/floor even though Side B's accumulated missing-frame damage is larger.

Trend Read

Side A:

  • Oscillating lean/repair recovery, now with smaller late deltas.
  • Reasons seen:
    • recoverySamples=300; no clean-low-latency samples.
    • Profiles rotate through silent-lean, persistent-lean, steady-weak-listener, repair-collapse, and collapse-recovery.
    • Three sampled concealment spikes remain (concealmentTicksDelta=7, 9, 8), while final seconds mostly add small missing-frame deltas.
    • Current state ends correctly in repair-collapse, but the whole sampled window still lets weaker lean profiles dominate.

Side B:

  • Flat-ish but still damaged, with intermittent missing-frame bursts.
  • Reasons seen:
    • silent-lean dominates 224 of 300 samples while totalMissingFramesDelta=1187.
    • Significant bursts include missingFramesDelta=32 under silent-lean, 54 under persistent-lean, and later 21/27 under repair-collapse.
    • Final window settles into smaller 3-4 missing-frame deltas, but never leaves recovery and remains on silent-lean.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-07T18:57Z group-812 B / Linux root clean-low-latency yes no selector / false-clean repair pressure Covered by earlier selector work; keep as historical false-clean baseline.
2026-05-07T19:25Z group-937 A / Linux root clean-low-latency yes no selector / false-clean repair pressure Covered by earlier selector work; keep as historical false-clean baseline.
2026-05-07T19:48Z group-937 A / Linux root steady-weak-listener yes partly/no selector / repair-heavy escalation Still a valid secondary selector refinement.
2026-05-07T19:48Z group-937 B / Linux standby silent-lean yes no selector / repair-collapse escalation Covered by the high-damage lean escalation target.
2026-05-07T20:30Z group-937 A / Linux root epoch 3 collapse-recovery yes partly/yes authority/topology plus receive collapse Keep as regression watch; not reproduced in later converged calls.
2026-05-07T20:30Z group-937 B / Linux root epoch 4 buffered-not-ready yes no/partly authority/topology and send-target selection Keep as regression watch; later calls have converged topology and no no-target growth.
2026-05-07T21:23Z group-937 A / Linux root epoch 3 silent-lean yes partly/no selector / high-damage lean escalation Addressed by promoting high-damage near-empty ready paths out of silent-lean.
2026-05-07T21:23Z group-937 B / Linux standby epoch 3 collapse-recovery yes yes receive profile strength / collapse recovery Addressed by strengthening collapse target/floor/hold; verify with later exports.
2026-05-07T21:50Z group-937 A / Linux root epoch 3 steady-weak-listener partly/early partly/yes receive / residual weak recovery Watch; no immediate profile-strength change from this side.
2026-05-07T21:50Z group-937 B / Linux standby epoch 3 clean-low-latency yes/early, partly current no selector / false-clean near-empty repair collapse Primary: prevent clean-low-latency while ready near-empty damage and recovery pressure remain active.
2026-05-08T10:48Z group-812 A / Linux root epoch 3 steady-weak-listener partly/inferred partly selector / profile oscillation and premature clean clear Primary: add hysteresis/clear gating so weak or repair-heavy recovery cannot briefly clear to clean while under-target/rate pressure remains high.
2026-05-08T10:48Z group-812 B / Mac standby epoch 3 persistent-lean partly/inferred mostly/partly receive / lean recovery Watch; no baseline or new-profile change from this side.
2026-05-08T12:06Z group-812 A / Linux root epoch 1 steady-weak-listener partly/inferred partly selector / profile oscillation and premature clean clear Secondary: keep clean-clear gating and profile hysteresis work, but do not make this the primary target from this pair.
2026-05-08T12:06Z group-812 B / Mac standby epoch 1 persistent-lean yes/inferred mostly/yes receive profile strength / persistent lean Prior primary target; this new call weakens it as the next single fix because the latest failure is not near-empty persistent lean.
2026-05-08T21:17Z group-937 A / Linux root epoch 4 silent-lean yes/inferred partly/no selector / damage hold after collapse burst Primary: keep repair/collapse damage latched after concealment and large missing-frame bursts; do not let silent-lean dominate until quiet.
2026-05-08T21:17Z group-937 B / Linux standby epoch 4 steady-weak-listener yes/inferred partly selector / repair-collapse escalation hold Primary: hold repair-collapse or collapse-recovery through burst aftermath instead of falling back to steady-weak-listener too quickly.
2026-05-08T22:10Z group-937 A / Linux root epoch 10 silent-lean yes/inferred partly selector / lean-vs-repair oscillation Keep the selector target: hold repair-collapse/collapse-recovery until missing-frame and concealment deltas are quiet for a sustained window.
2026-05-08T22:10Z group-937 B / Linux standby epoch 10 silent-lean yes/inferred no/partly selector / missing-frame damage under-classified as silent lean Primary: promote/hold repair-collapse when large recent missing-frame deltas occur, even with low current concealment and modest under-target fractions.

Next Fix Target

Current patched target:

  • Selector.
  • Primary fix: strengthen the damage selector and hold gates between silent-lean / persistent-lean and repair-collapse / collapse-recovery. Recent large missingFramesDelta bursts should latch a repair/collapse class until both missing-frame and concealment deltas stay quiet for a sustained window.
  • This call is not evidence for a baseline change: no side is spending time in clean-low-latency, and both sides already use recovery mode.
  • This call is not primarily profile strength either. Side A's current repair-collapse target/floor is strong (240/224) and active; the remaining miss is that weaker lean profiles still dominate the sampled window. Tune profile strength only after repair/collapse classification stays dominant during damaged windows.
  • Do not prioritize key/decode/startup/authority/link transport, and do not add a new profile from this pair.

Call: 2026-05-08 23:55Z / group 937

Room:

  • gcall-qortal-937

Files:

  • Side A: /home/qortal/Downloads/phil-kenny-one-on-one-115.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-08T23-55-02-779Z.json

User symptom:

  • New post-change call for validation. No explicit subjective symptom was included; infer residual badness from the diagnostic damage and startup/session signals.

High-level verdict:

  • Bad / mixed, with a new correctness-startup signal on top of remaining receive-policy damage.
  • Both exports agree on room gcall-qortal-937, topology epoch 2, root QTSzRS...9jMn, standby QP9Jj4...i6rP, room key presence, and participant count. They do not agree on call session: Side A exports 7cb2512a-b5fa-4509-98dd-e24a862290ed, while Side B exports cdd764cb-a011-4fe9-a441-6d4b42394d99. Side A also records totalNoTargetSkipsDelta=601 early in the sampled window before any receive playout exists.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt=0, pendingDecryptDepth=0, and pending-decrypt high water is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure=0 and packetsDroppedDecoderThrow=0 on both sides.
  • Link transport once active: both sides export link inbound/outbound transport and reticulumAudioPacketSendFailures=0.
  • Queue/backpressure: no bridge drain wait, no queue-pressure drops, no stale drops, and no link-unready drops. Side A bridge high water reaches 24, but binary high water is 1 and there are no drops.
  • Room authority/topology: both sides agree on root/standby and epoch 2.
  • Baseline: this is not a clean-low-latency tuning problem; both sides spend nearly all active sampled time in recovery or repair/lean profiles.

Primary next target:

  • Another subsystem: session/send-target startup correctness.
  • The new pair has two red flags outside receive-profile tuning: mismatched call session IDs across the same room/topology and a root-side startup run of outboundNoTargetSkipsDelta=601 while no receive playouts exist. Per the review rules, this should be fixed or explained before further profile strength or selector tuning.
  • Secondary target remains selector damage-hold. Side B is still under-classified for much of the bad window: steady-weak-listener dominates despite missingFrames=2786, concealmentTicks=324, and repeated missingFramesDelta spikes up to 139.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QTSzRS...9jMn receiving QP9Jj4...i6rP steady-weak-listener yes/inferred 16.218 621 167 0.026 0.016 recovery Early outboundNoTargetSkipsDelta=601; active receive later oscillates across weak/lean/repair/collapse. Current profile is silent-lean.
B standby-forwarder / Linux / QP9Jj4...i6rP receiving QTSzRS...9jMn steady-weak-listener yes/inferred 5.125 2786 324 0.015 0.013 recovery Current profile is collapse-recovery, but dominant window profile is too weak for repeated large missing-frame bursts and near-empty reserve.

Side A

Expected profile from symptom:

  • During active receive damage: repair-collapse, repair-heavy-connected, or collapse-recovery for bursts; steady-weak-listener only for quieter recovery intervals. During the opening no-target window, no receive profile can explain the send failure.

Actual exported profile:

  • Dominant sampled profile: steady-weak-listener (45 samples).
  • Other significant samples: silent-lean (33), persistent-lean (29), collapse-recovery (25), repair-collapse (14), repair-heavy-connected (6), buffered-not-ready (4).
  • Current exported profile: silent-lean.

Did classification match?

  • Partly for receive symptoms; no for the opening no-target/session symptom.

Notes:

  • Side A's active receive damage is lighter than Side B's but still not clean: missingFrames=621, concealmentTicks=167, avgPlayoutDeltaMs=-168.759, and recovery is active.
  • The first sampled no-target period is not a receive-profile issue. It has outboundNoTargetSkipsDelta of 52, 51, 50, etc. while receivePlayouts=[], then receive profiles appear only after that startup window.
  • Later classification is mixed: some repair/collapse classifications appear at burst points, but the profile still oscillates quickly back into lean/weak classes.

Side B

Expected profile from symptom:

  • collapse-recovery while jitterHasReadyFrame=false with continuing concealment, and repair-collapse or repair-heavy-connected during large missing-frame bursts once ready returns. steady-weak-listener should only cover quieter intervals.

Actual exported profile:

  • Dominant sampled profile: steady-weak-listener (64 samples).
  • Other significant samples: collapse-recovery (45), persistent-lean (17), repair-heavy-connected (5), silent-lean (3), repair-collapse (1).
  • Current exported profile: collapse-recovery.

Did classification match?

  • Partly/no.

Notes:

  • Current classification is right: live state is collapse-recovery, with bufferedMsEma=0.002, deltaMsEma=-184.998, lastJitterHasReadyFrame=false, target/floor 304/280, and severe/repair/buffered holds active.
  • Dominant classification is too weak for the sampled call: steady-weak-listener wins 64 samples while the side reaches missingFrames=2786, concealmentTicks=324, avgPcmBufferedMs=5.125, and repeated large missing-frame bursts (116, 89, 104, 139, 95, 92).
  • This still supports selector damage-hold as a secondary issue, but the call-session mismatch and root no-target startup should be handled first.

Trend Read

Side A:

  • Discrete startup no-target window followed by oscillating receive recovery.
  • Reasons seen:
    • From 1778284339146 through 1778284350825, Side A accumulates outboundNoTargetSkipsDelta=601 while receivePlayouts=[].
    • After receive starts, it enters recovery and cycles through repair-collapse, repair-heavy-connected, collapse-recovery, persistent-lean, silent-lean, and steady-weak-listener.
    • Later final-window damage is lower-grade but persistent: small missing-frame deltas continue while avgPcmBufferedMs sits around 16 ms.

Side B:

  • Flat-bad oscillation between ready missing-frame bursts and not-ready concealment/collapse.
  • Reasons seen:
    • Large missing-frame deltas repeatedly occur under steady-weak-listener, including 116, 89, 104, 139, 95, and 92.
    • Concealment runs occur under collapse-recovery while jitterHasReadyFrame=false, often at 6-8 ticks per second.
    • The side ends in collapse-recovery with jitterHasReadyFrame=false, which matches the current live collapse.

Batch Scoreboard

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-07T18:57Z group-812 B / Linux root clean-low-latency yes no selector / false-clean repair pressure Covered by earlier selector work; keep as historical false-clean baseline.
2026-05-07T19:25Z group-937 A / Linux root clean-low-latency yes no selector / false-clean repair pressure Covered by earlier selector work; keep as historical false-clean baseline.
2026-05-07T19:48Z group-937 A / Linux root steady-weak-listener yes partly/no selector / repair-heavy escalation Still a valid secondary selector refinement.
2026-05-07T19:48Z group-937 B / Linux standby silent-lean yes no selector / repair-collapse escalation Covered by the high-damage lean escalation target.
2026-05-07T20:30Z group-937 A / Linux root epoch 3 collapse-recovery yes partly/yes authority/topology plus receive collapse Keep as regression watch; not reproduced in later converged calls.
2026-05-07T20:30Z group-937 B / Linux root epoch 4 buffered-not-ready yes no/partly authority/topology and send-target selection Keep as regression watch; later calls have converged topology and no no-target growth.
2026-05-07T21:23Z group-937 A / Linux root epoch 3 silent-lean yes partly/no selector / high-damage lean escalation Addressed by promoting high-damage near-empty ready paths out of silent-lean.
2026-05-07T21:23Z group-937 B / Linux standby epoch 3 collapse-recovery yes yes receive profile strength / collapse recovery Addressed by strengthening collapse target/floor/hold; verify with later exports.
2026-05-07T21:50Z group-937 A / Linux root epoch 3 steady-weak-listener partly/early partly/yes receive / residual weak recovery Watch; no immediate profile-strength change from this side.
2026-05-07T21:50Z group-937 B / Linux standby epoch 3 clean-low-latency yes/early, partly current no selector / false-clean near-empty repair collapse Primary: prevent clean-low-latency while ready near-empty damage and recovery pressure remain active.
2026-05-08T10:48Z group-812 A / Linux root epoch 3 steady-weak-listener partly/inferred partly selector / profile oscillation and premature clean clear Primary: add hysteresis/clear gating so weak or repair-heavy recovery cannot briefly clear to clean while under-target/rate pressure remains high.
2026-05-08T10:48Z group-812 B / Mac standby epoch 3 persistent-lean partly/inferred mostly/partly receive / lean recovery Watch; no baseline or new-profile change from this side.
2026-05-08T12:06Z group-812 A / Linux root epoch 1 steady-weak-listener partly/inferred partly selector / profile oscillation and premature clean clear Secondary: keep clean-clear gating and profile hysteresis work, but do not make this the primary target from this pair.
2026-05-08T12:06Z group-812 B / Mac standby epoch 1 persistent-lean yes/inferred mostly/yes receive profile strength / persistent lean Prior primary target; this new call weakens it as the next single fix because the latest failure is not near-empty persistent lean.
2026-05-08T21:17Z group-937 A / Linux root epoch 4 silent-lean yes/inferred partly/no selector / damage hold after collapse burst Primary: keep repair/collapse damage latched after concealment and large missing-frame bursts; do not let silent-lean dominate until quiet.
2026-05-08T21:17Z group-937 B / Linux standby epoch 4 steady-weak-listener yes/inferred partly selector / repair-collapse escalation hold Primary: hold repair-collapse or collapse-recovery through burst aftermath instead of falling back to steady-weak-listener too quickly.
2026-05-08T22:10Z group-937 A / Linux root epoch 10 silent-lean yes/inferred partly selector / lean-vs-repair oscillation Keep the selector target: hold repair-collapse/collapse-recovery until missing-frame and concealment deltas are quiet for a sustained window.
2026-05-08T22:10Z group-937 B / Linux standby epoch 10 silent-lean yes/inferred no/partly selector / missing-frame damage under-classified as silent lean Primary: promote/hold repair-collapse when large recent missing-frame deltas occur, even with low current concealment and modest under-target fractions.
2026-05-08T23:55Z group-937 A / Linux root epoch 2 steady-weak-listener yes/inferred partly/no session/send-target startup plus receive oscillation Primary: investigate call-session mismatch and root no-target skips before more receive tuning.
2026-05-08T23:55Z group-937 B / Linux standby epoch 2 steady-weak-listener yes/inferred partly/no selector / under-held damage, plus session mismatch Secondary after state fix: hold collapse-recovery/repair classes through ready/not-ready damage cycles.

Next Fix Target

Current patched target:

  • Another subsystem: session/send-target startup correctness.
  • Primary fix: explain and eliminate the same-room call-session mismatch and the root-side startup no-target run. This pair has different callSessionId values on the two sides and totalNoTargetSkipsDelta=601 on Side A before receive playouts exist. That is outside receive profile tuning and should be handled first.
  • Secondary fix: selector damage-hold still needs attention after the state/session issue is cleared. Side B repeatedly reports large missing-frame bursts under steady-weak-listener; the current end state is correctly collapse-recovery, but the dominant profile is too weak for the call.
  • Keep baseline unchanged and do not add a new receive profile from this pair.

Call: 2026-05-09 19:30Z / group 937

Room:

  • gcall-qortal-937

Files:

  • Side A: /home/qortal/Downloads/phil-kenny-one-on-one-116.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-09T19-30-19-007Z.json

User symptom:

  • New post-change call. Subjectively good for roughly the first 1-2 minutes, then progressively worse.

High-level verdict:

  • Bad, but more narrowly policy-dominated than the previous pair.
  • The retained 300-sample trend window starts after the likely good opening. Inside that window both sides are already in recovery and keep accumulating repair damage. The prior call-session mismatch is gone: both sides agree on room gcall-qortal-937, topology epoch 2, root QTSzRS...9jMn, standby QP9Jj4...i6rP, and call session 5c236dbf-31a0-4256-9194-92bd825527b2.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt=0, pendingDecryptDepth=0, and pending-decrypt high water is 0 on both sides.
  • Decode: packetsDroppedDecodeFailure=0 and packetsDroppedDecoderThrow=0 on both sides.
  • Link collapse: both sides use link transport for inbound and outbound audio, with reticulumAudioPacketSendFailures=0.
  • Queue/backpressure: reticulumAudioBridgeWaitingForDrain=false, no queue-pressure drops, no stale drops, no link-unready drops, and binary queue high water is only 2 on both sides. Side A bridge high water reaches 17, but without drain wait or drops.
  • Startup/send-target: unlike the previous pair, totalNoTargetSkipsDelta=0 on both sides during the sampled window. Side A has historical cumulative no-target skips, but none are growing in this review window.
  • Authority/topology/session: both sides agree on epoch 2, root/standby, room key state, participant count, media session generation 1, and call session.

Primary next target:

  • Selector.
  • The previous session/send-target target should move to regression watch for this pair. The current failure is receive-policy classification and damage hold: Side B spends 218/300 samples in silent-lean despite missingFrames=4277, concealmentTicks=386, avgPcmBufferedMs=5.243, and repeated large missing-frame bursts. Side A is less collapsed but still lets clean-low-latency appear 29/300 samples while damage keeps accumulating.
  • This is not a baseline fix yet. Baseline is not dominating the bad side, and both sides are already in recovery mode. It is also not primarily profile strength: the strong collapse-recovery target/floor exists and is correct when selected, but the selector keeps falling back to silent-lean, steady-weak-listener, or even clean-low-latency between bursts.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QTSzRS...9jMn receiving QP9Jj4...i6rP steady-weak-listener yes 37.219 2457 193 0.114 0.031 recovery Current profile is steady-weak-listener; window includes repair-collapse and repair-heavy-connected, but also 29 false-clean samples while missing frames continue.
B standby-forwarder / Linux / QP9Jj4...i6rP receiving QTSzRS...9jMn silent-lean yes 5.243 4277 386 0.005 0.004 recovery Current profile is correctly collapse-recovery, but dominant window profile is far too weak for near-empty reserve plus repeated missing-frame and concealment bursts.

Side A

Expected profile from symptom:

  • repair-heavy-connected or repair-collapse during ready missing-frame bursts, and collapse-recovery during not-ready concealment runs. steady-weak-listener is acceptable only for quieter recovery intervals. clean-low-latency should not appear while recent repair damage is still active.

Actual exported profile:

  • Dominant sampled profile: steady-weak-listener (131 samples).
  • Other significant samples: repair-collapse (71), repair-heavy-connected (50), clean-low-latency (29), collapse-recovery (15), persistent-lean (3), buffered-not-ready (1).
  • Current exported profile: steady-weak-listener.

Did classification match?

  • Partly/no.

Notes:

  • Side A has enough buffered reserve on paper (avgPcmBufferedMs=37.219) that it does not look like the near-empty Side B collapse, but it still accumulates totalMissingFramesDelta=2108 and totalConcealmentTicksDelta=81 in the sampled window.
  • The strongest mismatch is the reappearance of clean-low-latency while damage is still ongoing: examples include missingFramesDelta=14, 11, 8, later 8, 16, and then 70 under clean-low-latency.
  • Current live state is weaker than the damage history suggests: bufferedMsEma=50.430, deltaMsEma=-132.084, missingFrameEma=0.172, target/floor 172/172, and only postRecovery hold remains.

Side B

Expected profile from symptom:

  • repair-collapse or collapse-recovery should dominate after the call becomes bad. silent-lean can explain shallow reserve with low current concealment, but it should not dominate a window with thousands of missing frames, hundreds of concealment ticks, and repeated large missing-frame bursts.

Actual exported profile:

  • Dominant sampled profile: silent-lean (218 samples).
  • Other significant samples: collapse-recovery (36), repair-collapse (34), persistent-lean (7), buffered-not-ready (5).
  • Current exported profile: collapse-recovery.

Did classification match?

  • No for the sampled bad window; yes for the final current state.

Notes:

  • Current state is correctly severe: collapse-recovery, bufferedMsEma=0.00009, deltaMsEma=-185.000, lastJitterHasReadyFrame=false, target/floor 304/280, with severe/repair/buffered/lean holds all active.
  • The dominant sampled profile is wrong for the symptom and metrics. Side B reaches missingFrames=4277, concealmentTicks=386, totalMissingFramesDelta=3228, and totalConcealmentTicksDelta=311 while silent-lean owns most samples.
  • Large bursts still happen under weak classes, including missingFramesDelta=175, 125, 98, 88, 86, 80, 49, and many smaller ongoing deltas under silent-lean.

Trend Read

Side A:

  • Oscillating repair recovery with false-clean dips.
  • Reasons seen:
    • recoverySamples=230, so this is not a fully baseline call.
    • Repeated repair/collapse stretches are followed by steady-weak-listener or clean-low-latency before damage is quiet.
    • Late burst sequence includes collapse-recovery concealment, then missingFramesDelta=98, then missingFramesDelta=70 under clean-low-latency.

Side B:

  • Progressive/flat-bad after the retained window begins, with near-empty reserve and repeated burst recovery.
  • Reasons seen:
    • recoverySamples=300; no clean-low-latency samples.
    • silent-lean dominates 218/300 samples despite near-empty avgPcmBufferedMs around 5.2-5.7 ms.
    • Repeated not-ready concealment runs under collapse-recovery are followed by large ready bursts that often fall back to silent-lean.

Batch Scoreboard Update

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-09T19:30Z group-937 A / Linux root epoch 2 steady-weak-listener yes partly/no selector / false-clean and weak clear during repair damage Primary: prevent clean-low-latency and weak-listener fallback until recent missing-frame/concealment bursts are quiet for a sustained window.
2026-05-09T19:30Z group-937 B / Linux standby epoch 2 silent-lean yes no/current partly yes selector / high-damage silent-lean under-classification Primary: promote or hold repair-collapse/collapse-recovery after large missing-frame bursts and not-ready concealment, even when current under-target/rate fractions look modest.

Next Fix Target

Current patched target:

  • Selector.
  • Primary fix: strengthen the damage latch between silent-lean / steady-weak-listener / clean-low-latency and the repair/collapse profiles. Recent large missingFramesDelta or repeated not-ready concealment should keep a source in repair-collapse or collapse-recovery until both missing-frame and concealment deltas are quiet for a sustained clear window.
  • Keep session/send-target startup as regression watch only. This pair no longer reproduces the mismatched session or growing no-target skip symptom.
  • Keep baseline unchanged. Do not add a new profile from this call; the existing repair/collapse profiles match the bad window when selected, but selection and clear timing are still wrong.

Call: 2026-05-09 19:45Z / group 812 / 3 participants

Room:

  • gcall-qortal-812

Files:

  • Receiver A: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-09T19-45-19-515Z.json
  • Receiver B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-09T19-45-10-385Z.json
  • Receiver C: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-09T19-45-24-187Z.json

User symptom:

  • New 3+ participant call. No separate subjective per-listener symptom was included; infer badness from each receiver's window damage and multi-source receive profiles.

High-level verdict:

  • Bad / mixed, policy-dominated.
  • All three exports agree on room gcall-qortal-812, topology epoch 3, root QMe6E7...6VFZ, standby QeJW96...j5W9, participant count 3, media session generation 1, and call session 61e0a042-3a76-4825-a5ae-dfb6bb41e3d4. The previous session mismatch and no-target startup failure are not reproduced.
  • The new 3+ profile family is too coarse: each receiver applies the same multi-clean-low-latency / multi-protected-recovery class to both remote sources, then clears both sources together even while missing-frame damage continues.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt=0, pendingDecryptDepth=0, and pending-decrypt high water is 0 on all three exports.
  • Decode: packetsDroppedDecodeFailure=0 and packetsDroppedDecoderThrow=0 on all three exports.
  • Link transport: all exports use link transport for inbound and outbound audio, with reticulumAudioPacketSendFailures=0.
  • Queue/backpressure: reticulumAudioBridgeWaitingForDrain=false, no queue-pressure drops, no stale drops, and no link-unready drops. Queue high-water values are modest (3/2, 15/3, 3/4 for bridge/binary).
  • Startup/send-target: totalNoTargetSkipsDelta=0 on all three retained windows. Root has historical cumulative outboundNoTargetSkips=218, but it is not growing in this review window.
  • Authority/session: all three agree on epoch, root/standby, participant count, room key presence, media session generation, and call session.

Primary next target:

  • Selector / multi-source profile granularity and clear hysteresis.
  • Do not tune the global baseline from this call. The main failure is that multi-clean-low-latency becomes dominant while the receivers still accumulate large missing-frame deltas. Do not treat this as single-source profile strength either: the new multi profiles are hiding source-specific damage by clearing both sources as a group.
  • The next fix should make 3+ receive classification source-sensitive: near-empty or not-ready damaged sources need a protected/repair class even if another source is buffered, and multi-clean-low-latency should not clear while recent missing-frame or concealment bursts remain active for any source.
Receiver Role Remote Sources Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QMe6E7...6VFZ QP9Jj4...i6rP, QeJW96...j5W9 multi-clean-low-latency yes/inferred 60.926 6456 553 0.134 0.075 low-latency Both sources split 154 clean / 146 protected samples; final clean clear happens despite late missing-frame deltas 35 and 43.
B standby-forwarder / Linux / QeJW96...j5W9 QMe6E7...6VFZ, QP9Jj4...i6rP multi-clean-low-latency yes/inferred 11.290 6060 383 0.021 0.011 low-latency Both sources split 153 clean / 147 protected samples; QP9Jj4 is not-ready in 51/300 samples, but clears with the healthier root source.
C participant / Linux / QP9Jj4...i6rP QMe6E7...6VFZ, QeJW96...j5W9 multi-clean-low-latency yes/inferred 5.200 4288 296 0.003 0.002 low-latency Both sources are clean for 285/300 samples despite near-empty aggregate reserve and large bursts, including missingFramesDelta=524.

Receiver A / Root QMe6E7...6VFZ

Expected profile from symptom:

  • Mixed per-source classification: multi-protected-recovery or a source-specific repair/collapse class for the damaged source, with multi-clean-low-latency only after recent missing-frame and not-ready/concealment bursts are quiet.

Actual exported profile:

  • QP9Jj4...i6rP: multi-clean-low-latency (154 samples), multi-protected-recovery (146 samples).
  • QeJW96...j5W9: multi-clean-low-latency (154 samples), multi-protected-recovery (146 samples).
  • Current live profile: multi-clean-low-latency for both sources.

Did classification match?

  • Partly/no.

Notes:

  • This receiver has plenty of aggregate reserve (avgPcmBufferedMs=60.926) but still has bad playout pressure (playoutUnderTargetFraction=0.134, playoutRateFractionBelow097=0.075) and high damage (totalMissingFramesDelta=4250, totalConcealmentTicksDelta=252).
  • The final trend rows show multi-clean-low-latency clearing while missingFramesDelta is still 35 then 43.
  • One source has a live repair hold (QP9Jj4...i6rP has lastAppliedTargetMs=196, lastAppliedFloorMs=196, repairCollapse=973 ms remaining), but the exported profile is still multi-clean-low-latency.

Receiver B / Standby QeJW96...j5W9

Expected profile from symptom:

  • Mixed per-source classification: multi-protected-recovery for not-ready or near-empty damaged sources, with clean allowed only for genuinely quiet ready sources.

Actual exported profile:

  • QMe6E7...6VFZ: multi-clean-low-latency (153 samples), multi-protected-recovery (147 samples).
  • QP9Jj4...i6rP: multi-clean-low-latency (153 samples), multi-protected-recovery (147 samples).
  • Current live profile: multi-clean-low-latency for both sources.

Did classification match?

  • Partly/no.

Notes:

  • This receiver is the clearest source-specific mismatch: QP9Jj4...i6rP is not-ready in 51/300 trend samples, while QMe6E7...6VFZ is not-ready only once.
  • Despite that asymmetry, both sources receive identical profile counts and clear together.
  • The aggregate window is still bad: totalMissingFramesDelta=4146, totalConcealmentTicksDelta=260, and top missing-frame bursts include 107, 94, 83, 72, and 67.

Receiver C / Participant QP9Jj4...i6rP

Expected profile from symptom:

  • multi-protected-recovery or source-specific repair/collapse should dominate because the receiver is near-empty for the whole retained window and still accumulating missing frames.

Actual exported profile:

  • QMe6E7...6VFZ: multi-clean-low-latency (285 samples), multi-protected-recovery (15 samples).
  • QeJW96...j5W9: multi-clean-low-latency (285 samples), multi-protected-recovery (15 samples).
  • Current live profile: multi-clean-low-latency for both sources.

Did classification match?

  • No.

Notes:

  • This side has avgPcmBufferedMs=5.200, jitterBufferDepthFramesMean=0.135, avgPlayoutDeltaMs=-176.299, missingFrames=4288, and concealmentTicks=296.
  • The window includes a discrete severe burst: top missingFramesDelta values are 524, 142, and 29; top concealment deltas are 17, 17, 16, 16, and 16.
  • multi-clean-low-latency dominating 285/300 samples is not compatible with near-empty reserve plus a 524 missing-frame spike.

Trend Read

Receiver A:

  • Oscillating grouped multi-profile with late false-clean clear.
  • Reasons seen:
    • entered-recovery appears 36 times.
    • both sources alternate together between multi-clean-low-latency and multi-protected-recovery.
    • late damage continues under clean: final rows include missingFramesDelta=35 and 43 after clearing back to multi-clean-low-latency.

Receiver B:

  • Oscillating grouped multi-profile with source asymmetry hidden by the profile.
  • Reasons seen:
    • entered-recovery appears 40 times.
    • QP9Jj4...i6rP is not-ready in 51/300 samples, but both sources have identical profile counts.
    • late clean rows still accumulate missingFramesDelta=31, then smaller 6, 4, 11, 12, 10, 10, and 14 deltas.

Receiver C:

  • Mostly false-clean near-empty receive, with a discrete severe burst.
  • Reasons seen:
    • only 15/300 protected samples despite near-empty aggregate reserve.
    • top missing-frame deltas include 524 and 142.
    • both sources remain multi-clean-low-latency through the final rows while missing frames continue rising by 3-9 frames per second.

Batch Scoreboard Update

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-09T19:45Z group-812 A / Linux root epoch 3 / 3-way multi-clean-low-latency yes/inferred partly/no selector / grouped multi clear during repair damage Make multi clean-clear source-sensitive and block clean while recent missing-frame/concealment bursts remain active on any source.
2026-05-09T19:45Z group-812 B / Linux standby epoch 3 / 3-way multi-clean-low-latency yes/inferred partly/no selector / source asymmetry hidden by multi profile Separate per-source readiness/damage classification; QP9Jj4 not-ready samples should not clear with the healthier source.
2026-05-09T19:45Z group-812 C / Linux participant epoch 3 / 3-way multi-clean-low-latency yes/inferred no selector / false-clean near-empty multi receive Promote/hold protected recovery for near-empty multi receive after large missing-frame bursts; this is the strongest regression target.

Next Fix Target

Current patched target:

  • Selector.
  • Primary fix: introduce stronger source-sensitive multi-party receive classification and clean-clear hysteresis. multi-clean-low-latency must not dominate when one source is near-empty/not-ready or when recent missing-frame/concealment bursts are still active.
  • Keep session/send-target startup as regression watch only. This 3-way call has consistent session/topology and no growing no-target skips.
  • Keep baseline unchanged and do not add a new profile yet. The existing multi classes are probably enough as names, but their selector/clear logic is currently too coarse for mixed-source 3+ calls.

Call: 2026-05-09 20:28Z / group 937

Room:

  • gcall-qortal-937

Files:

  • Side A: /home/qortal/Downloads/phil-kenny-one-on-one-117.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-09T20-28-24-337Z.json

User symptom:

  • New post-change two-person group call. No separate subjective quality note was included with the exports; infer badness from the retained-window damage and recovery profiles.

High-level verdict:

  • Bad / mixed, with both receive-policy and startup/send-target evidence.
  • Both final exports agree on room gcall-qortal-937, topology epoch 2, root QTSzRS...9jMn, standby QP9Jj4...i6rP, participant count 2, media session generation 1, and final call session a47821bf-f52c-4e84-92cf-cb22d6ef7b41.
  • Unlike the previous clean two-person review, Side A again has growing outbound no-target skips during the retained window: totalNoTargetSkipsDelta=1421. Side B also bootstrapped from a one-participant cached session 9b4ccfff-6006-497b-8873-043b0996f14c before settling on the final session.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt=0, pending-decrypt depth/high-water 0, and totalPendingDecryptDelta=0 on both sides.
  • Decode: packetsDroppedDecodeFailure=0 and packetsDroppedDecoderThrow=0 on both sides.
  • Link transport: both sides use link transport for inbound and outbound audio, with reticulumAudioPacketSendFailures=0.
  • Authority steady state: final topology/session/root/standby state matches on both sides.
  • Baseline: neither side is living in ordinary clean-low-latency; both sides are in recovery for almost the whole sampled bad window.

Primary next target:

  • Another subsystem first: startup/send-target correctness, then selector/profile-strength follow-up.
  • The revived root-side no-target run is outside receive profile tuning and should be fixed before using this pair as clean evidence for receive-only tuning. Side A reports 1421 no-target skips during the retained window while Side B has repeated early zero-inbound-media-recovery-requested events before packets arrive.
  • After that is cleared, this same pair still supports receive tuning: Side B is under-classified as persistent-lean/silent-lean while accumulating large missing-frame bursts, and Side A remains audibly bad by metrics even under collapse-recovery/repair-collapse, which may require stronger collapse profile target/floor behavior.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QTSzRS...9jMn receiving QP9Jj4...i6rP collapse-recovery yes/inferred 4.367 1211 4580 0.057 0.055 recovery Strong profiles dominate (138 collapse, 86 repair-collapse), but the side still has severe concealment and 1421 outbound no-target skips early in the retained window.
B standby-forwarder / Linux / QP9Jj4...i6rP receiving QTSzRS...9jMn persistent-lean yes/inferred 5.909 1758 132 0.006 0.004 recovery Dominant profile is too weak for repeated missing-frame bursts; final/current state is correctly collapse-recovery.

Side A

Expected profile from symptom:

  • collapse-recovery or repair-collapse, because the listener is near-empty (avgPcmBufferedMs=4.367, avgPlayoutDeltaMs=-177.350) and has severe concealment (concealmentTicks=4580).

Actual exported profile:

  • Dominant sampled profile: collapse-recovery (138 samples).
  • Other significant samples: repair-collapse (86), silent-lean (13), repair-heavy-connected (4), persistent-lean (4), steady-weak-listener (2), buffered-not-ready (1).
  • Current exported profile: collapse-recovery.

Did classification match?

  • Mostly yes for receive classification, but the call still fails.

Notes:

  • This is not the same under-classification shape as the 19:30Z Side B case. Side A spends most profile-tagged samples in strong collapse/repair classes, and those classes carry most damage (collapse-recovery: 2381 concealment delta; repair-collapse: 1667 concealment delta).
  • The mismatch is more profile strength or non-receive-path than selector: the strong class is selected, but the buffer stays near empty and concealment remains high.
  • The first 29 trend samples have no receive profile and account for 1421 outbound no-target skips. That startup/send-target signal must be separated from receive profile judgment.

Side B

Expected profile from symptom:

  • repair-collapse or collapse-recovery after the missing-frame bursts begin. persistent-lean can explain low reserve only if current damage is mild, which is not true for this window.

Actual exported profile:

  • Dominant sampled profile: persistent-lean (99 samples).
  • Other significant samples: silent-lean (53), repair-collapse (22), collapse-recovery (17), steady-weak-listener (3), buffered-not-ready (3).
  • Current exported profile: collapse-recovery.

Did classification match?

  • No for the sampled bad window; yes for the final current state.

Notes:

  • Side B reaches missingFrames=1758 with totalMissingFramesDelta=1758, while persistent-lean owns 686 missing-frame delta and silent-lean owns another 317.
  • Large bursts include missingFramesDelta=261, 175, 68, 65, 48, 36, 35, 34, and 33.
  • The low under-target/rate fractions are misleading here. They do not justify weak profile dominance when reserve is near empty and missing frames are accumulating.

Trend Read

Side A:

  • Mixed startup gap followed by flat-bad collapse recovery.
  • Reasons seen:
    • totalNoTargetSkipsDelta=1421 occurs before receive profiles exist in the retained window.
    • After receive begins, the side is mostly in collapse-recovery/repair-collapse.
    • Damage continues under strong profiles, especially concealment spikes up to 86, 73, 67, 66, and 62.

Side B:

  • Startup/zero-inbound recovery, then persistent under-classified missing-frame damage.
  • Reasons seen:
    • Early events include repeated zero-inbound-media-recovery-requested with packetsReceived=0.
    • persistent-lean/silent-lean dominate 152/198 samples despite near-empty reserve.
    • Current live state finally reaches collapse-recovery with severe, repair, buffered, lean, and recent-damage holds active.

Batch Scoreboard Update

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-09T20:28Z group-937 A / Linux root epoch 2 collapse-recovery yes/inferred mostly yes startup/send-target plus possible profile strength Primary: fix renewed root-side no-target startup/send-target path; then test whether collapse-recovery/repair-collapse need stronger target/floor when correctly selected but still near-empty.
2026-05-09T20:28Z group-937 B / Linux standby epoch 2 persistent-lean yes/inferred no/current yes selector / lean under-classification after missing-frame bursts After startup is clean, promote/hold repair-collapse/collapse-recovery after large missing-frame bursts even when under-target/rate fractions remain low.

Next Fix Target

Current patched target:

  • Another subsystem: startup/send-target correctness.
  • Primary fix: eliminate the revived root-side outbound no-target run and the standby-side early zero-inbound warm recovery. This pair is not clean receive-only evidence while Side A grows totalNoTargetSkipsDelta=1421 in the retained window.
  • Secondary fix: selector damage-hold remains valid after startup is clean. Side B repeats the prior under-classification pattern, with persistent-lean/silent-lean dominant while missing frames accumulate.
  • Tertiary fix: profile strength for collapse-recovery/repair-collapse may need review, but only after the no-target/startup path is quiet. Side A selected the severe profiles correctly and still stayed near-empty with heavy concealment.
  • Keep baseline unchanged and do not add a new profile from this call.

Call: 2026-05-09 20:41Z / group 812

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-09T20-41-07-067Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-09T20-41-02-373Z.json
  • Side C: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-09T20-40-55-844Z.json

User symptom:

  • New post-change 3+ group call. No separate subjective per-listener symptom was included; infer user-bad status from retained-window damage and receive profiles.

High-level verdict:

  • Bad, but improved classification shape versus the previous false-clean multi-source batch.
  • All three exports agree on room gcall-qortal-812, topology epoch 3, root QeJW96...j5W9, standby QP9Jj4...i6rP, participant count 3, room key presence, and media session generation 1.
  • The strongest remaining failure is not startup/key/queue correctness. The participant side is correctly pinned in multi-protected-recovery for both sources for all 300/300 trend samples, but still accumulates 9665 concealment ticks and 2484 missing-frame delta in the retained window.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt=0, pendingDecryptDepth=0, and retained-window pending decrypt delta is 0 on all three exports.
  • Decode: packetsDroppedDecodeFailure=0 and packetsDroppedDecoderThrow=0 on all three exports.
  • Queue/backpressure: no queue-pressure drops, stale drops, link-unready drops, or bridge drain wait on any side.
  • Startup/send-target: retained-window totalNoTargetSkipsDelta=0 on all three exports.
  • Authority/session: topology, root/standby, room key, and media generation are consistent across the batch.

Primary next target:

  • Profile strength / application for multi-protected-recovery.
  • The selector is no longer the sole failure. The worst side's classification matches the damage profile, but the applied protection is not strong enough to stop ongoing concealment. Also inspect why some live multi-protected-recovery states report lastAppliedTargetMs=null, lastAppliedFloorMs=null, and lastAppliedTargetBoostMs=0; that looks like a protection-application gap, not a baseline issue.
  • Secondary target: selector clear hysteresis for mixed-source sides. Root and standby still show one source protected for the whole retained window while the other source spends most samples in multi-clean-low-latency; that may be valid per-source asymmetry, but clean should not survive recent not-ready/missing-frame bursts.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A participant / Linux / QMe6E7...6VFZ multi-protected-recovery yes/inferred 7.654 3206 12215 0.097 0.095 recovery Both remotes are protected for 300/300 samples; classification matches, but concealment continues at roughly 32-40 ticks/sec late in the window.
B root-forwarder / Linux / QeJW96...j5W9 mixed: QMe6E7 protected, QP9Jj4 clean-dominant yes/inferred 93.255 5349 498 0.113 0.066 recovery QMe6E7 is protected 300/300; QP9Jj4 is clean 227/300, protected 68/300, recovery 5/300, with 38 not-ready samples.
C standby-forwarder / Linux / QP9Jj4...i6rP mixed: QeJW96 protected, QMe6E7 clean-dominant yes/inferred 5.872 5234 428 0.003 0.002 low-latency QeJW96 is protected 300/300; QMe6E7 is clean 292/300. Aggregate reserve is near-empty, but the protected source appears to be the likely damaged leg.

Side A / Participant QMe6E7...6VFZ

Expected profile from symptom:

  • multi-protected-recovery for both sources. This side is shallow-buffered, under target, rate-chasing, and heavily concealed.

Actual exported profile:

  • QeJW96...j5W9: multi-protected-recovery (300 samples).
  • QP9Jj4...i6rP: multi-protected-recovery (300 samples).

Did classification match?

  • Yes.

Notes:

  • This is the strongest evidence in the batch. The selector did the right thing for the whole retained window, but the side is still bad: totalConcealmentTicksDelta=9665, totalMissingFramesDelta=2484, avgPcmBufferedMs=7.654, and avgPlayoutDeltaMs=-130.486.
  • Live state shows QeJW96 receiving target/floor/boost (192/176/+72, extra hold 8), while QP9Jj4 is also labeled protected but has no applied target/floor/boost. That per-source mismatch should be inspected before changing baseline.

Side B / Root QeJW96...j5W9

Expected profile from symptom:

  • Mixed source-sensitive classification: protected for the damaged/slow leg, clean only for a genuinely stable source.

Actual exported profile:

  • QMe6E7...6VFZ: multi-protected-recovery (300 samples).
  • QP9Jj4...i6rP: multi-clean-low-latency (227), multi-protected-recovery (68), multi-recovery (5).
  • Current live profile: multi-protected-recovery for both sources.

Did classification match?

  • Partly.

Notes:

  • Aggregate damage is still material: totalMissingFramesDelta=3191, totalConcealmentTicksDelta=120, playoutUnderTargetFraction=0.113, and playoutRateFractionBelow097=0.066.
  • QP9Jj4 has 38 not-ready samples and top missing-frame deltas of 103, 92, 68, and 59; clean-dominant classification for that source is suspicious unless those bursts all belong to the other source.
  • The live state has both sources protected at export time, but both show no applied target/floor/boost. That points back to protected-profile application/strength rather than baseline.

Side C / Standby QP9Jj4...i6rP

Expected profile from symptom:

  • At least one source should stay protected because the receiver is near-empty and still accumulating missing frames. Clean is plausible only for the source with healthy per-source reserve.

Actual exported profile:

  • QeJW96...j5W9: multi-protected-recovery (300 samples).
  • QMe6E7...6VFZ: multi-clean-low-latency (292), multi-protected-recovery (7), multi-recovery (1).

Did classification match?

  • Mostly/partly.

Notes:

  • The protected QeJW96 leg looks correctly classified and has active applied protection at export (240/224/+120, extra hold 11).
  • The side still has near-empty aggregate reserve (avgPcmBufferedMs=5.872) and totalMissingFramesDelta=2578, including a single 669 frame burst.
  • QMe6E7 clean-dominant may be valid if it is genuinely the buffered leg (bufferedMsEma=109.775), but the large aggregate burst means per-source attribution should be verified before relaxing selector rules.

Trend Read

Side A:

  • Flat-bad protected recovery.
  • Reasons seen:
    • multi-protected-recovery for both remotes in all 300 samples.
    • no decrypt/decode/startup deltas.
    • late concealment continues steadily with top deltas 40, 40, 40, 40, 40, 39, 39, 38.

Side B:

  • Mixed-source recovery with late protection but suspicious clean dominance on one leg.
  • Reasons seen:
    • entered-recovery appears 20 times.
    • QP9Jj4 has 38 not-ready samples.
    • top missing-frame deltas are 103, 92, 68, 59, 43, 43, 35, 35.

Side C:

  • Source-specific protected leg plus mostly clean second leg; one severe discrete missing-frame burst.
  • Reasons seen:
    • QeJW96 protected for all 300 samples.
    • QMe6E7 clean for 292/300 samples.
    • top missing-frame delta is 669, followed by much smaller 32, 17, 13, 12, 12, 11, 11.

Batch Scoreboard Update

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-09T20:41Z group-812 A / Linux participant epoch 3 multi-protected-recovery yes/inferred yes receive profile strength/application Strengthen or fix application of multi-protected-recovery; investigate protected states with no applied target/floor/boost.
2026-05-09T20:41Z group-812 B / Linux root epoch 3 mixed protected/clean yes/inferred partly profile application plus selector hysteresis Keep source-sensitive classification, but block/shorten clean when recent not-ready or missing-frame bursts remain active; inspect missing applied boosts under protected live state.
2026-05-09T20:41Z group-812 C / Linux standby epoch 3 mixed protected/clean yes/inferred mostly/partly profile strength with per-source attribution check Treat QeJW96 protected classification as correct; verify the 669 missing-frame burst source before changing clean selector for QMe6E7.

Next Fix Target

Current patched target:

  • Profile strength / protection application, specifically multi-protected-recovery.
  • Primary fix: make protected multi-source policy actually provide enough target/floor/hold on every protected source, and audit cases where the exported profile is multi-protected-recovery but lastAppliedTargetMs, lastAppliedFloorMs, and lastAppliedTargetBoostMs are null/0.
  • Secondary fix: selector clear hysteresis for mixed-source legs after not-ready or missing-frame bursts. This is secondary because the worst side in this batch is already correctly protected.
  • Keep baseline unchanged and do not add a new profile from this call.

Call: 2026-05-09 21:43Z / group 937 follow-up two-person

Room:

  • gcall-qortal-937

Files:

  • Side A: /home/qortal/Downloads/phil-kenny-one-on-one-118.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-09T21-43-16-440Z.json

User symptom:

  • New post-change two-person group call. No separate subjective per-side quality note was included; infer badness from retained-window damage and recovery state.

High-level verdict:

  • Bad, receive-policy dominated.
  • Both exports agree on room gcall-qortal-937, topology epoch 2, root QTSzRS...9jMn, standby QP9Jj4...i6rP, participant count 2, room key presence, and media session generation 1.
  • This is cleaner than the prior 20:28Z two-person export for subsystem triage: retained-window totalNoTargetSkipsDelta=0 on both sides, no decrypt/decode drops, and no queue/backpressure signal.
  • Both sides still spend the entire retained window in recovery and accumulate large missing-frame deltas (2619 on Side A, 3835 on Side B). The dominant profiles are too weak for that symptom shape.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt=0, pendingDecryptDepth=0, pending-decrypt high-water 0, and retained-window pending-decrypt delta 0 on both sides.
  • Decode: packetsDroppedDecodeFailure=0 and packetsDroppedDecoderThrow=0 on both sides.
  • Startup/send-target in the retained window: totalNoTargetSkipsDelta=0 on both sides.
  • Queue/backpressure: bridge waiting-for-drain is false; bridge queued-frame high-water is 11 on Side A and 3 on Side B.
  • Failover/authority: no promotion/demotion counts, settled matching root/standby/topology/session state.

Primary next target:

  • Selector, specifically single-source damage escalation and hold hysteresis.
  • Baseline is not the next target: both sides are already in recovery for all 300/300 retained samples.
  • Profile strength is secondary. The collapse/repair profiles are selected for bursts, but the selector lets steady-weak-listener, persistent-lean, and silent-lean dominate while missing frames continue. Fix classification/holding before raising the baseline.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QTSzRS...9jMn receiving QP9Jj4...i6rP persistent-lean yes/inferred 28.490 3668 467 0.033 0.021 recovery Dominant retained profile is persistent-lean (166/300) despite totalMissingFramesDelta=2619; late live state is only steady-weak-listener.
B standby-forwarder / Linux / QP9Jj4...i6rP receiving QTSzRS...9jMn steady-weak-listener yes/inferred 5.921 5603 518 0.007 0.005 recovery Dominant retained profile is steady-weak-listener (103/300) while reserve is near empty and totalMissingFramesDelta=3835; late live state is silent-lean.

Side A

Expected profile from symptom:

  • repair-collapse or collapse-recovery during and after missing-frame bursts. persistent-lean can explain sustained low reserve only if damage is mild, which is not true here.

Actual exported profile:

  • Dominant sampled profile: persistent-lean (166 samples).
  • Other sampled profiles: steady-weak-listener (44), collapse-recovery (43), repair-collapse (27), repair-heavy-connected (14), buffered-not-ready (4), silent-lean (2).
  • Current exported profile: steady-weak-listener.

Did classification match?

  • No.

Notes:

  • Side A accumulates 2619 missing frames and 322 concealment ticks during the retained window. The largest missing-frame bursts are 369, 231, 219, and 212.
  • The burst samples do enter repair profiles, but the side quickly falls back to weak/lean profiles while recovery remains active.
  • collapse-recovery owns most concealment (268 ticks) and looks appropriate when concealment is active. The main miss is insufficient damage hold after missing-frame spikes.
  • Live state shows lastAppliedTargetMs=172, lastAppliedFloorMs=172, and boost +48, which is light for a side still carrying thousands of missing frames.

Side B

Expected profile from symptom:

  • repair-collapse or collapse-recovery. This side is near-empty (avgPcmBufferedMs=5.921, jitter depth mean 0.300) and has the worse missing-frame count.

Actual exported profile:

  • Dominant sampled profile: steady-weak-listener (103 samples).
  • Other sampled profiles: silent-lean (56), collapse-recovery (56), repair-collapse (48), persistent-lean (25), buffered-not-ready (6), repair-heavy-connected (6).
  • Current exported profile: silent-lean.

Did classification match?

  • No.

Notes:

  • Side B accumulates 3835 missing frames and 381 concealment ticks during the retained window. The largest missing-frame bursts are 376, 251, 238, and 127.
  • steady-weak-listener owns 1277 missing-frame delta, more than any stronger class. That is the clearest selector mismatch in this pair.
  • Under-target and slow-rate fractions are low (0.007 and 0.005), so the selector is still relying too much on those calm rate signals while missing frames and near-empty reserve say the listener is bad.
  • Live state is silent-lean with target/floor/boost 204/192/+84; this is stronger than Side A but still not the correct damage class for ongoing missing-frame failure.

Trend Read

Side A:

  • Oscillating between weak/lean and repair/collapse, with discrete missing-frame bursts.
  • Reasons seen:
    • one explicit missing-frames-spike.
    • top missing-frame deltas: 369, 231, 219, 212, 111, 76, 75, 70.
    • 37 retained samples report jitterHasReadyFrame=false.
    • no retained-window decrypt/decode/no-target deltas.

Side B:

  • Flat weak reserve with repeated discrete missing-frame bursts; stronger classes do not hold long enough.
  • Reasons seen:
    • one explicit missing-frames-spike.
    • top missing-frame deltas: 376, 251, 238, 127, 114, 101, 88, 81.
    • 69 retained samples report jitterHasReadyFrame=false.
    • no retained-window decrypt/decode/no-target deltas.

Batch Scoreboard Update

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-09T21:43Z group-937 A / Linux root epoch 2 persistent-lean yes/inferred no selector / damage hold Promote and hold repair-collapse/collapse-recovery after large missing-frame bursts; do not let persistent-lean or steady-weak-listener dominate while recovery damage is still accumulating.
2026-05-09T21:43Z group-937 B / Linux standby epoch 2 steady-weak-listener yes/inferred no selector / damage hold Escalate near-empty single-source listeners with repeated missing-frame bursts even when under-target and rate fractions are low; hold the stronger class through recovery.

Next Fix Target

Current patched target:

  • Selector.
  • Primary fix: single-source missing-frame/recent-damage escalation should latch repair-collapse or collapse-recovery longer, especially when avgPcmBufferedMs is near-empty or jitterHasReadyFrame=false recurs.
  • Secondary fix: profile strength for repair-collapse/collapse-recovery can be revisited after classification stays correct; Side A's applied 172/172/+48 is likely too light if that remains the live policy after selector fixes.
  • Keep baseline unchanged. Do not add a new profile from this call.

Call: 2026-05-09 21:25Z / group 812 good 3-person follow-up

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-09T21-25-22-493Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-09T21-24-53-757Z.json
  • Side C: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-09T21-24-46-348Z.json

User symptom:

  • New post-change 3+ group call. User reported the call was good.

High-level verdict:

  • Good, with noisy retained-window receive diagnostics.
  • All three exports agree on room gcall-qortal-812, topology epoch 3, root QeJW96...j5W9, standby QP9Jj4...i6rP, participant count 3, room key presence, and media session generation 1.
  • This is not a correctness/startup failure. It is a tuning signal: the call sounded good while one side stayed fully protected and the other two sides spent most samples low-latency with continuing missing-frame deltas.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt=0, pendingDecryptDepth=0, and retained-window pending-decrypt delta 0 on all three exports.
  • Decode: packetsDroppedDecodeFailure=0 and packetsDroppedDecoderThrow=0 on all three exports.
  • Queue/backpressure: no queue-pressure drops, stale drops, link-unready drops, or bridge drain wait on any side.
  • Startup/send-target: retained-window totalNoTargetSkipsDelta=0 on all three exports.
  • Authority/session: topology, root/standby, room key, and media generation are consistent across the batch.

Primary next target:

  • Selector, specifically multi-source protected/clean exit stability and damage attribution.
  • Do not strengthen multi-protected-recovery from this batch: the subjective result was good, and the fully protected participant already applied 240/224/+120 with extra hold 8 on both sources.
  • Do not change baseline: root and standby were mostly low-latency and still sounded good. The interesting problem is classification/diagnostic alignment, not global target size.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QeJW96...j5W9 mixed, clean-dominant no 79.940 4481 132 0.058 0.014 low-latency Retained window has 1964 missing-frame delta but only 1 concealment tick; QP9Jj4 clean 189/300, protected 111/300; QMe6E7 clean 259/300, protected 41/300.
B participant / Linux / QMe6E7...6VFZ multi-protected-recovery no 10.558 3545 18016 0.115 0.114 recovery Both sources protected 300/300; retained window still has 9567 concealment ticks, but user symptom was good. Protection may be doing useful work, but diagnostics read harsher than the reported experience.
C standby-forwarder / Linux / QP9Jj4...i6rP mixed, one protected leg no 19.037 5053 74 0.012 0.003 low-latency QeJW96 protected 300/300; QMe6E7 clean 230/300, protected 70/300; retained window has 2481 missing-frame delta with only 5 concealment ticks.

Side A / Root QeJW96...j5W9

Expected profile from symptom:

  • Mostly multi-clean-low-latency, with brief protected recovery only around real weak-leg events.

Actual exported profile:

  • QP9Jj4...i6rP: multi-clean-low-latency (189), multi-protected-recovery (111).
  • QMe6E7...6VFZ: multi-clean-low-latency (259), multi-protected-recovery (41).
  • Current live profile: QP9Jj4 clean, QMe6E7 protected.

Did classification match?

  • Mostly, but noisy.

Notes:

  • Good symptom matches clean-dominant classification and low concealment.
  • The retained 1964 missing-frame delta did not become an audible bad call, so missing frames alone should not force stronger protection here.
  • The QP9Jj4 leg flips rapidly between clean and protected near export time, often with preProcessBufferedFrames bouncing between 0 and 8-10. That points to selector exit/entry stability rather than profile strength.

Side B / Participant QMe6E7...6VFZ

Expected profile from symptom:

  • Good-user symptom would normally suggest clean or brief recovery, but the metrics support protection because reserve is shallow and concealment remains active.

Actual exported profile:

  • QeJW96...j5W9: multi-protected-recovery (300).
  • QP9Jj4...i6rP: multi-protected-recovery (300).

Did classification match?

  • Partly.

Notes:

  • Metrics justify protection: avgPcmBufferedMs=10.558, jitterBufferDepthFramesMean=0.268, totalConcealmentTicksDelta=9567, under-target 0.115, and rate-below-0.97 0.114.
  • Symptom does not justify calling this a failed profile. The previous concern that protected recovery was too weak is not supported by this good-call report.
  • Both sources applied strong protection at export (240/224/+120, extra hold 8), so this is a case where strong protection may be preserving acceptable audio despite harsh retained-window counters.

Side C / Standby QP9Jj4...i6rP

Expected profile from symptom:

  • One protected source can be valid if source-specific reserve is weak; the healthy leg should remain clean.

Actual exported profile:

  • QeJW96...j5W9: multi-protected-recovery (300).
  • QMe6E7...6VFZ: multi-clean-low-latency (230), multi-protected-recovery (70).

Did classification match?

  • Mostly.

Notes:

  • The protected QeJW96 leg has low source reserve (bufferedMsEma=5.806) and applied protection (192/176/+72, extra hold 6), while QMe6E7 has healthy source reserve (bufferedMsEma=133.139) and clean classification.
  • This is the best evidence that per-source multi classification is directionally useful.
  • The retained 2481 missing-frame delta with only 5 concealment ticks suggests missing-frame severity should be interpreted with concealment/user symptom, not as an automatic escalation input.

Trend Read

Side A:

  • Mostly low-latency, with selector oscillation on one source.
  • Reasons seen:
    • only 7/300 retained samples in recovery mode.
    • top missing-frame delta is 30, with low concealment.
    • late QP9Jj4 transitions flip clean/protected repeatedly within milliseconds.

Side B:

  • Flat protected recovery.
  • Reasons seen:
    • recovery mode for 300/300 samples.
    • both sources protected for 300/300 samples.
    • concealment ticks continue steadily around 31-33 on top samples, yet the call was reported good.

Side C:

  • Source-specific protected leg plus clean healthy leg.
  • Reasons seen:
    • QeJW96 protected for 300/300 samples.
    • QMe6E7 clean for 230/300 samples.
    • recovery mode only 36/300 samples, with low concealment.

Batch Scoreboard Update

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-09T21:25Z group-812 good A / Linux root epoch 3 mixed clean-dominant no mostly selector stability Smooth multi-source clean/protected flipping; avoid using missing frames alone as proof of user-bad quality when concealment is near zero.
2026-05-09T21:25Z group-812 good B / Linux participant epoch 3 multi-protected-recovery no partly selector/profile interpretation Keep strong protection available, but do not strengthen it from this call; investigate whether retained concealment counters overstate audible damage during successful protected recovery.
2026-05-09T21:25Z group-812 good C / Linux standby epoch 3 mixed protected/clean no mostly selector attribution Preserve per-source asymmetry; verify missing-frame attribution before tightening clean exit rules.

Next Fix Target

Current patched target:

  • Selector.
  • Primary fix: multi-source selector stability and attribution. The root side shows rapid clean/protected flipping, while the standby side shows a plausible protected/clean split. Tune entry/exit hysteresis around preProcessBufferedFrames, source reserve, and recent missing-frame deltas so good calls do not look like failed protected recovery.
  • Secondary fix: diagnostics/profile interpretation for protected recovery. A fully protected participant can still be a good call; scoreboard logic should treat user symptom plus concealment audibility, not just high retained counters.
  • Leave baseline unchanged. Do not add a new profile from this call.

Call: 2026-05-10 22:44Z / group 937 2-person follow-up

Room:

  • gcall-qortal-937

Files:

  • Side A: /home/qortal/Downloads/phil-kenny-one-on-one-119.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-10T22-44-40-652Z.json

User symptom:

  • New two-person group call after the latest changes. Subjective quality was not stated, so user-bad is inferred from the retained-window receive metrics and recovery profiles.

High-level verdict:

  • Bad, receive-policy dominated.
  • Both exports agree on room gcall-qortal-937, topology epoch 2, root QTSzRS...9jMn, standby QP9Jj4...i6rP, participant count 2, room key presence, and media session generation 1.
  • Side A is a real severe receive failure: near-empty reserve, heavy concealment, and live repair-collapse.
  • Side B is still under-classified for the symptom shape: low reserve and repeated missing-frame deltas spend most retained samples in steady-weak-listener / persistent-lean.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt=0, pendingDecryptDepth=0, and retained-window pending-decrypt delta 0 on both sides.
  • Decode: packetsDroppedDecodeFailure=0 and packetsDroppedDecoderThrow=0 on both sides.
  • Queue/backpressure: bridge waiting-for-drain is false; bridge queued-frame high-water is 24 on Side A and 2 on Side B, with no queue-pressure drops.
  • Failover/authority: no promotion/demotion counts, settled matching root/standby/topology/session state.
  • Baseline: both sides are already almost entirely in recovery (112/134 retained samples on Side A, 60/61 on Side B), so a global baseline increase is not the next lever.

Primary next target:

  • Selector.
  • Specifically, single-source damage/readiness hysteresis. Side B still lets weak/lean profiles dominate while missing frames continue, and Side A still oscillates between severe profiles and silent-lean even with near-zero reserve and high concealment.
  • Profile strength is secondary: Side A's live repair-collapse classification is correct but still sounds bad on paper, so revisit repair-collapse target/floor only after the selector stops dropping damaged sources into lean/weak classes.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QTSzRS...9jMn receiving QP9Jj4...i6rP mixed, silent-lean / collapse-recovery yes/inferred 1.170 635 1587 0.043 0.040 recovery Live profile is repair-collapse, but retained samples still spend 48/134 in silent-lean; reserve is effectively empty and concealment is severe.
B standby-forwarder / Linux / QP9Jj4...i6rP receiving QTSzRS...9jMn steady-weak-listener / persistent-lean yes/inferred 7.061 745 55 0.013 0.009 recovery Low concealment, but near-empty reserve and 745 missing frames should not be dominated by weak/lean profiles.

Side A

Expected profile from symptom:

  • repair-collapse or collapse-recovery.

Actual exported profile:

  • Current exported profile: repair-collapse.
  • Retained samples: silent-lean (48), collapse-recovery (43), repair-collapse (18), buffered-not-ready (4), steady-weak-listener (3), plus 18 early samples before receive profile export.

Did classification match?

  • Partly.

Notes:

  • The live profile matches the severe symptom: avgPcmBufferedMs=1.170, jitterBufferDepthFramesMean=0.060, avgPlayoutDeltaMs=-183.531, and concealmentTicks=1587.
  • The retained window still spends too much time in silent-lean despite 635 missing frames and 1587 concealment ticks.
  • collapse-recovery owns most retained concealment delta (1091), while repair-collapse owns 243 missing-frame delta and 310 concealment delta.
  • There is an early outbound target gap (totalNoTargetSkipsDelta=60) before profiles appear, but the late bad state has active playout, active scheduler/playback nodes, and no decrypt/decode failures.

Side B

Expected profile from symptom:

  • repair-collapse or collapse-recovery during missing-frame bursts; at minimum silent-lean should dominate over steady-weak-listener when reserve is this shallow.

Actual exported profile:

  • Current exported profile: silent-lean.
  • Retained samples: steady-weak-listener (20), persistent-lean (19), collapse-recovery (11), silent-lean (4), repair-collapse (4), repair-heavy-connected (1), buffered-not-ready (1).

Did classification match?

  • No/partly.

If no:

  • steady-weak-listener and persistent-lean own 681 of the 745 retained missing-frame delta while reserve stays shallow (avgPcmBufferedMs=7.061, jitter depth mean 0.358).
  • Low concealment (55) explains why this is not a classic concealment-heavy collapse, but it does not justify weak/lean dominance through repeated missing-frame bursts.
  • Retune selector entry/hold before changing baseline or adding a new profile.

Trend Read

Side A:

  • Flat-bad after startup, with severe concealment and selector oscillation.
  • Reasons seen:
    • entered-recovery once near the start of the retained bad window.
    • jitterHasReadyFrame=false in 74/134 retained samples.
    • top missing-frame deltas include 38, 37, 33, 33, 29, and 27.
    • top concealment deltas include 49, 48, 46, 45, 45, and 43.
    • no retained-window decrypt/decode deltas.

Side B:

  • Low-reserve missing-frame failure with weak/lean under-classification.
  • Reasons seen:
    • entered-recovery once at the start of the retained window.
    • jitterHasReadyFrame=false in 18/61 retained samples.
    • top missing-frame deltas include 64, 62, 49, 39, 35, 33, and 32.
    • concealment remains low; top concealment deltas are only 6.
    • no retained-window decrypt/decode/no-target deltas.

Batch Scoreboard Update

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-10T22:44Z group-937 A / Linux root epoch 2 mixed severe/lean, live repair-collapse yes/inferred partly selector, then profile strength Hold severe classification through near-empty/high-concealment windows; after that, verify whether repair-collapse target/floor is strong enough.
2026-05-10T22:44Z group-937 B / Linux standby epoch 2 steady-weak-listener / persistent-lean yes/inferred no/partly selector / damage hold Escalate repeated missing-frame bursts with shallow reserve even when concealment, under-target, and slow-rate fractions are calm.

Next Fix Target

Current patched target:

  • Selector.
  • Primary fix: single-source damage/readiness hysteresis. Treat near-empty reserve plus repeated missing-frame deltas or frequent jitterHasReadyFrame=false as a reason to hold repair-collapse / collapse-recovery, not fall back to steady-weak-listener, persistent-lean, or silent-lean.
  • Secondary fix: profile strength for repair-collapse if Side A remains near-empty after classification holds steady.
  • Leave baseline unchanged. Do not add a new profile from this call.

Call: 2026-05-10 23:51Z / group 937 2-person follow-up

Room:

  • gcall-qortal-937

Files:

  • Side A: /home/qortal/Downloads/phil-kenny-one-on-one-120.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-10T23-51-02-953Z.json

User symptom:

  • New two-person group call after the latest changes. Extra report: the root had a harder time hearing the other person.

High-level verdict:

  • Bad on the root side, receive-policy dominated.
  • Both exports agree on room gcall-qortal-937, topology epoch 2, root QTSzRS...9jMn, standby QP9Jj4...i6rP, participant count 2, room key presence, and media session generation 1.
  • The reported-bad root side is now correctly classified into severe receive profiles for most retained samples, but the profile protection is still not strong enough to rebuild usable reserve.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt=0, pendingDecryptDepth=0, and retained-window pending-decrypt delta 0 on both sides.
  • Decode: packetsDroppedDecodeFailure=0 and packetsDroppedDecoderThrow=0 on both sides.
  • Queue/backpressure: bridge waiting-for-drain is false; bridge queued-frame high-water is 22 on Side A and 2 on Side B, with no queue-pressure drops.
  • Failover/authority: no promotion/demotion counts, settled matching root/standby/topology/session state.
  • Startup/send-target: Side A has retained totalNoTargetSkipsDelta=58, but the late window has outboundNoTargetSkipsDelta=0, active playout, active scheduler/playback nodes, and continuing receive collapse. This is not the primary next fix.
  • Baseline: both sides are already in recovery almost the whole retained window (94/131 on Side A, 61/62 on Side B), so a global baseline increase is not the next lever.

Primary next target:

  • Profile strength.
  • Specifically strengthen severe single-source protection for repair-collapse / collapse-recovery: the reported-bad root spends 84/95 classified retained samples in those two severe profiles, live state is repair-collapse, and protection already applies 240/224/+120 with extra hold 11, yet average PCM reserve is only 2.098ms with 1052 concealment ticks.
  • Selector is now secondary: reduce rapid severe-profile churn, but do not treat this as the main failure because the root is no longer primarily stuck in weak/lean profiles.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QTSzRS...9jMn receiving QP9Jj4...i6rP repair-collapse / collapse-recovery yes 2.098 315 1052 0.050 0.046 recovery Reported-bad side. Live profile is repair-collapse; retained profile deltas put 112 missing / 243 concealment in repair-collapse and 118 missing / 709 concealment in collapse-recovery.
B standby-forwarder / Linux / QP9Jj4...i6rP receiving QTSzRS...9jMn silent-lean / persistent-lean no/not reported 8.253 479 28 0.009 0.004 recovery Symptom was asymmetric toward the root. Side B has low concealment but repeated missing-frame bursts; this looks like a lean/missing-frame path, not the user-reported hard-hearing side.

Side A

Expected profile from symptom:

  • repair-collapse or collapse-recovery.

Actual exported profile:

  • Current exported profile: repair-collapse.
  • Retained samples: repair-collapse (43), collapse-recovery (41), silent-lean (7), buffered-not-ready (2), persistent-lean (2), plus 36 early samples before receive profile export.

Did classification match?

  • Yes.

Notes:

  • The reported symptom matches the severe receive classification: avgPcmBufferedMs=2.098, jitterBufferDepthFramesMean=0.107, avgPlayoutDeltaMs=-182.469, missingFrames=315, and concealmentTicks=1052.
  • This is the first follow-up where the root-side problem is not primarily under-classification into weak/lean profiles. Severe profiles dominate the classified retained window.
  • The failure is still active late in the export: the last retained sample has missingFramesDelta=16, concealmentTicksDelta=27, avgPcmBufferedMs=2.098, and collapse-recovery.
  • There is rapid repair-collapse / collapse-recovery switching near export time, but both are severe paths. That churn is secondary to the fact that the severe target/floor is not producing usable reserve.

Side B

Expected profile from symptom:

  • If the standby had no hearing complaint, mostly clean or brief lean recovery would be expected. If unreported weak audio existed, silent-lean / persistent-lean fits better than repair-heavy collapse because concealment is low.

Actual exported profile:

  • Current exported profile: silent-lean.
  • Retained samples: silent-lean (27), persistent-lean (17), repair-collapse (13), collapse-recovery (3), buffered-not-ready (1), plus 1 early sample before receive profile export.

Did classification match?

  • Partly / unknown against user symptom.

If no:

  • The reported asymmetry was root-hearing-other, not standby-hearing-root. Side B's lean classification may be real metrics pressure, but it is not the reported symptom.
  • silent-lean and persistent-lean own 411 of 479 retained missing-frame delta while concealment stays low (28 total), so this remains a selector/damage-hold signal for missing-frame bursts if the standby later reports bad audio.
  • Do not use Side B to justify strengthening repair-collapse; use Side A for that.

Trend Read

Side A:

  • Flat-bad severe recovery after startup.
  • Reasons seen:
    • recovery mode for 94/131 retained samples.
    • severe profiles for 84/95 classified retained samples.
    • top missing-frame deltas include 26, 25, 20, 16, and 12.
    • top concealment deltas include 36, 35, 35, 31, 30, and 28.
    • no retained-window decrypt/decode deltas.

Side B:

  • Lean missing-frame pressure, low concealment, not the reported-bad side.
  • Reasons seen:
    • recovery mode for 61/62 retained samples.
    • silent-lean / persistent-lean for 44/61 classified retained samples.
    • top missing-frame deltas include 74, 44, 43, 28, 23, and 22.
    • concealment remains low; top concealment deltas are 4, 3, and 2.
    • no retained-window decrypt/decode/no-target deltas.

Batch Scoreboard Update

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-10T23:51Z group-937 A / Linux root epoch 2 repair-collapse / collapse-recovery yes yes profile strength Strengthen severe single-source repair-collapse / collapse-recovery target, floor, accumulation, or hold behavior; classification now matches the root's bad-hearing symptom.
2026-05-10T23:51Z group-937 B / Linux standby epoch 2 silent-lean / persistent-lean no/not reported partly/unknown selector / lean interpretation Keep as secondary evidence for missing-frame-plus-lean handling; do not make it the primary fix unless standby-side bad audio is reported.

Next Fix Target

Current patched target:

  • Profile strength.
  • Primary fix: severe single-source receive profile strength for repair-collapse / collapse-recovery. The root-side classification now matches the symptom, but the current 240ms target, 224ms floor, +120ms boost, and extra hold 11 still leave the listener near empty with heavy concealment.
  • Secondary fix: severe-profile selector stability. Smooth the rapid repair-collapse / collapse-recovery churn, but keep the side in a severe protection path until reserve actually rebuilds.
  • Leave baseline unchanged. Do not add a new profile from this call.

Call: 2026-05-11 00:35Z / group 937 2-person follow-up

Room:

  • gcall-qortal-937

Files:

  • Side A: /home/qortal/Downloads/phil-kenny-one-on-one-121.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-11T00-35-43-714Z.json

User symptom:

  • New two-person group call after the latest changes. Audio was horrible and incomprehensible overall; on root it was spotty, and on standby it was incomprehensible.

High-level verdict:

  • Bad/catastrophic, receive-policy dominated.
  • Both exports agree on room gcall-qortal-937, topology epoch 1, root QTSzRS...9jMn, standby QP9Jj4...i6rP, participant count 2, room key presence, and media session generation 1.
  • The root side remains a true severe collapse: classification mostly matches, but protection is still not enough to rebuild reserve.
  • The standby side is the stronger failure signal for the next patch: the reported-incomprehensible side is live steady-weak-listener, with large missing-frame damage previously carried by clean-low-latency and weak profiles.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt=0, pendingDecryptDepth=0, and retained-window pending-decrypt delta 0 on both sides.
  • Decode: packetsDroppedDecodeFailure=0 and packetsDroppedDecoderThrow=0 on both sides.
  • Queue/backpressure: bridge waiting-for-drain is false; bridge queued-frame high-water is 24 on Side A and 1 on Side B, with no queue-pressure drops.
  • Failover/authority: no promotion/demotion counts, settled matching root/standby/topology/session state.
  • Startup/send-target: retained totalNoTargetSkipsDelta=0 on both sides, playback/scheduler nodes are active, and both sides have live playouts.
  • Baseline: both sides spend most retained samples in recovery (141/147 on Side A, 71/91 on Side B), so a global baseline increase is not the next lever.

Primary next target:

  • Selector.
  • Specifically, single-source selector exit/hold around missing-frame bursts, under-target pressure, and slow-rate pressure when reserve looks superficially healthy. The standby side was reported incomprehensible, but live classification is only steady-weak-listener, and retained clean-low-latency owns 2430 missing-frame delta.
  • Profile strength remains secondary for the root side: Side A is correctly severe and still bad, but the worse standby symptom does not match the live profile, so selector correctness should be fixed before another broad severe-profile strength increase.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QTSzRS...9jMn receiving QP9Jj4...i6rP repair-collapse / collapse-recovery yes, spotty 0.952 1071 2335 0.050 0.049 recovery Live profile is collapse-recovery; retained severe profiles own 124/146 classified samples and most concealment. Classification matches, but reserve remains effectively empty.
B standby-forwarder / Linux / QP9Jj4...i6rP receiving QTSzRS...9jMn mixed, live steady-weak-listener yes, incomprehensible 59.953 4991 251 0.239 0.222 recovery Retained count is mixed with collapse-recovery highest, but clean-low-latency and steady-weak-listener own 4178 missing-frame delta. Live weak classification does not match the symptom.

Side A

Expected profile from symptom:

  • repair-collapse or collapse-recovery.

Actual exported profile:

  • Current exported profile: collapse-recovery.
  • Retained samples: repair-collapse (66), collapse-recovery (58), silent-lean (16), buffered-not-ready (5), repair-heavy-connected (1), plus 1 early sample before receive profile export.

Did classification match?

  • Yes for classification; no for outcome.

Notes:

  • The root-side symptom was spotty, and the metrics are severe: avgPcmBufferedMs=0.952, jitterBufferDepthFramesMean=0.048, avgPlayoutDeltaMs=-181.082, missingFrames=1071, and concealmentTicks=2335.
  • Severe profiles own most retained damage: collapse-recovery has 296 missing / 1553 concealment delta, and repair-collapse has 286 missing / 627 concealment delta.
  • This repeats the previous finding that severe-profile strength is still insufficient for the root path, but it is not the only or primary signal in this paired call.

Side B

Expected profile from symptom:

  • collapse-recovery or repair-collapse; at minimum a sustained repair-heavy/recovery profile should dominate while the side is incomprehensible.

Actual exported profile:

  • Current exported profile: steady-weak-listener.
  • Retained samples: collapse-recovery (33), clean-low-latency (16), steady-weak-listener (14), repair-collapse (8), buffered-not-ready (7), repair-heavy-connected (1), plus 12 early samples before receive profile export.

Did classification match?

  • No/partly.

If no:

  • The exported live profile is too weak for the reported symptom and the retained damage pattern.
  • clean-low-latency owns 2430 missing-frame delta, and steady-weak-listener owns another 1748, while the side reports incomprehensible audio.
  • Reserve looks higher on paper (avgPcmBufferedMs=59.953, live bufferedMsEma=120.276), but playoutUnderTargetFraction=0.239, playoutRateFractionBelow097=0.222, avgPlayoutDeltaMs=-120.907, jitterNotReadyFraction=0.239, and repeated large missing-frame bursts say this should not clear back to clean/weak handling.
  • Retune selector entry/exit and damage hold before changing baseline or adding a new profile.

Trend Read

Side A:

  • Flat-bad severe recovery, with rapid severe-profile churn near export time.
  • Reasons seen:
    • recovery mode for 141/147 retained samples.
    • severe profiles for 124/146 classified retained samples.
    • top missing-frame deltas include 154, 95, 72, 69, 50, and 44.
    • top concealment deltas include 98, 92, 75, 67, 63, and 54.
    • no retained-window decrypt/decode/no-target deltas.

Side B:

  • Mixed selector failure: healthy-looking reserve, but heavy missing-frame bursts and sustained under-target/slow-rate pressure.
  • Reasons seen:
    • recovery mode for 71/91 retained samples.
    • clean-low-latency alone carries 2430 missing-frame delta; steady-weak-listener carries 1748.
    • top missing-frame deltas include 604, 269, 252, 237, 236, and 218.
    • concealment is comparatively low (251 total), but under-target and slow-rate fractions are high and the user symptom is incomprehensible.
    • no retained-window decrypt/decode/no-target deltas.

Batch Scoreboard Update

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-11T00:35Z group-937 A / Linux root epoch 1 repair-collapse / collapse-recovery yes, spotty yes profile strength, secondary Keep severe profile strengthening on the list, but do not make this the only patch because the paired standby side is worse and misclassified.
2026-05-11T00:35Z group-937 B / Linux standby epoch 1 mixed, live steady-weak-listener yes, incomprehensible no/partly selector / damage hold Prevent clean/weak profiles from carrying large missing-frame bursts under high under-target and slow-rate pressure; hold severe or repair-heavy recovery until pressure clears.

Next Fix Target

Current patched target:

  • Selector.
  • Primary fix: single-source selector damage hold and exit hysteresis. A side with repeated large missing-frame deltas plus high playoutUnderTargetFraction / playoutRateFractionBelow097 should not spend damaging windows in clean-low-latency or settle live at steady-weak-listener, even if avgPcmBufferedMs / reserve EMA looks healthy.
  • Secondary fix: severe-profile strength for repair-collapse / collapse-recovery on the root side, because correct severe classification still leaves root near empty.
  • Leave baseline unchanged. Do not add a new profile from this call.

Call: 2026-05-11 12:33Z / group 812 post-sender-hardening check

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-11T12-33-26-638Z.json
  • Side B: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-11T12-33-30-076Z.json

User symptom:

  • New two-person group call after the sender backlog/stale-output/reset changes. User asked whether the previous issue was fixed.

High-level verdict:

  • Mixed but materially improved.
  • Both exports agree on room gcall-qortal-812, connected state, two active senders, active WASM-FEC receive path, active shared PCM ring, active jitter/playback/scheduler nodes, and matching root/standby roles.
  • The previous catastrophic sender issue is fixed in this call: both sides have droppedEncoderBackpressureFrames=0, droppedStaleEncodedFrames=0, encoderResetCount=0, encoderQueueSize=0, and normal sender main-thread-to-encoder timing. Root improved from the previous bad call's avg=40.068ms / max=426.91ms to avg=0.686ms / max=15.24ms; standby is avg=0.633ms / max=6.98ms.
  • Remaining issue is receive-policy churn, not sender backlog. Standby receiving root is now clean enough by the prior symptom bars; root receiving standby still has moderate missing-frame/repair churn.

Not the problem:

  • Sender/WebCodecs backlog: both sides have zero backpressure drops, stale drops, and encoder resets.
  • Decrypt: packetsDroppedPendingDecrypt=0, retained-window pending-decrypt delta 0 on both sides.
  • Decode: packetsDroppedDecodeFailure=0, retained-window decode-failure delta 0 on both sides.
  • Queue/backpressure: both outbound paths show send successes equal attempts, no send failures, bridge waiting-for-drain false, no queue-pressure drops, no stale drops, no decoded queue drops, and no packet path timeouts.
  • Startup/playout: both sides have active playout, active scheduler/playback nodes, jitterHasReadyFrame=true, and no no-target deltas.
  • Renderer stalls: standby has no renderer stalls or long tasks. Root has one early renderer stall and one long task from before/at monitor startup, but sender timing stayed healthy and the stall is not the active failure shape.
  • Baseline: both sides spend most retained samples in recovery and already apply profile floors/boosts; global baseline is not the next lever.

Primary next target:

  • Selector / hysteresis.
  • Specifically, smooth single-source receive profile exit/hold and reduce profile churn after recovery. The catastrophic standby-hearing-root failure is gone, but both sides still show profiles oscillating between lean, weak, repair-heavy, and collapse modes after missing-frame bursts.
  • Do not tune sender next from this call. Do not increase baseline. Profile strength is secondary only if a future report says a correctly classified repair-collapse / collapse-recovery side still sounds bad.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 mixed: steady-weak-listener, clean-low-latency, collapse-recovery, repair-collapse; live repair-heavy-connected no catastrophic symptom reported; residual receive churn 25.454 1471 190 0.048 0.030 recovery Sender path healthy. Receive damage is moderate and much improved versus prior root collapse, but clean-low-latency still owns 372 missing-frame delta and weak/repair profiles churn.
B standby-forwarder / macOS / QaU2XU...Jh91 receiving QP9Jj4...i6rP persistent-lean / silent-lean; live repair-collapse no; prior standby-incomprehensible symptom appears fixed 11.216 685 55 0.005 0.003 recovery This is the important before/after improvement. Standby under-target and slow-rate fractions are now near clean-call levels; no sender backlog, decrypt, decode, or queue issues. Profile is conservative/lean-heavy despite low current pressure.

Side A

Expected profile from symptom:

  • If no user-bad symptom: mostly clean-low-latency with brief steady-weak-listener / repair-heavy-connected during bursts.
  • If residual spotty audio was noticed: repair-heavy-connected or brief repair-collapse fits better than full collapse.

Actual exported profile:

  • Current exported profile: repair-heavy-connected.
  • Retained profile counts: steady-weak-listener (50), clean-low-latency (44), collapse-recovery (33), repair-collapse (22), repair-heavy-connected (15), buffered-not-ready (1), plus 20 early no-profile samples.

Did classification match?

  • Partly.

Notes:

  • The sender-side classification is clean: captured and encoded frames match (8376/8376), with no backpressure/stale/reset counters.
  • Receive classification still exits/enters too often. repair-collapse owns the largest retained missing-frame delta (565), but clean-low-latency still owns 372 missing-frame delta and steady-weak-listener owns 343.
  • Late live state looks like a recovery tail rather than active collapse: bufferedMsEma=181.741, lastAppliedTargetMs=196, lastAppliedFloorMs=196, underTargetEma=0.074, missingFrameEma=0.030, and repairHeavy hold remaining about 9.9s.
  • This argues for selector/hysteresis refinement, not another global profile-strength increase.

Side B

Expected profile from symptom:

  • Since the previous standby-incomprehensible symptom appears fixed, expected profile would be mostly clean-low-latency or brief lean recovery.

Actual exported profile:

  • Current exported profile: repair-collapse.
  • Retained profile counts: persistent-lean (77), silent-lean (49), repair-collapse (27), collapse-recovery (7), plus 1 early no-profile sample.

Did classification match?

  • Partly / too conservative.

If no:

  • Current user-level outcome looks far better than the exported severe/lean labels imply: playoutUnderTargetFraction=0.005, playoutRateFractionBelow097=0.003, concealmentTicks=55, no renderer stalls, and no sender backlog.
  • The live repair-collapse state is mostly driven by shallow/lean geometry (bufferedMsEma=3.312, deltaMsEma=-181.688, preProcessBufferedFrames=0) and missing-frame EMA, not active under-target or concealment pressure.
  • This should not drive profile-strength tuning. It is a selector/exit-hysteresis question: keep protection available for shallow reserve, but avoid making a good-sounding standby look catastrophically classified once current pressure is calm.

Trend Read

Side A:

  • Improved sender, residual receive oscillation.
  • Reasons seen:
    • recovery mode for 135/185 retained samples.
    • profile counts are spread across weak, clean, repair-heavy, repair-collapse, and collapse-recovery rather than one stable severe class.
    • retained missing-frame deltas: repair-collapse=565, clean-low-latency=372, steady-weak-listener=343, repair-heavy-connected=111, collapse-recovery=80.
    • concealment is much lower than the previous root-collapse call (190 total versus 2335), but collapse-recovery still owns most concealment (152).
    • no retained-window decrypt/decode/no-target deltas.

Side B:

  • Fixed prior standby catastrophic symptom; conservative lean/recovery classification remains.
  • Reasons seen:
    • recovery mode for 160/161 retained samples.
    • retained missing-frame deltas are mostly persistent-lean=457, with low concealment (55) and very low under-target/slow-rate fractions.
    • largest missing deltas were 108 and 102 in persistent-lean, but late windows settle to small deltas (2-4) with jitterHasReadyFrame=true.
    • no renderer stalls, decrypt/decode drops, no-target deltas, or bridge pressure.

Batch Scoreboard Update

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-11T12:33Z group-812 A / Linux root epoch unknown mixed; live repair-heavy-connected no catastrophic symptom reported; residual churn partly selector / recovery hysteresis Keep sender fix; tune receive selector exit/hold so clean/weak profiles do not own missing-frame bursts and recovery tails do not churn.
2026-05-11T12:33Z group-812 B / macOS standby epoch unknown persistent-lean / silent-lean; live repair-collapse no; prior incomprehensible standby symptom fixed partly / too conservative selector / lean-clear hysteresis Do not strengthen severe profiles from this side; refine lean/collapse clear conditions so calm low-under-target windows do not look catastrophically classified.

Next Fix Target

Current patched target:

  • Selector / hysteresis.
  • Primary fix: single-source receive profile stability after recovery. Keep the new sender backlog protection as successful, then tune receive selector entry/exit so:
    • clean-low-latency and steady-weak-listener do not own meaningful missing-frame bursts on Side A.
    • persistent-lean / silent-lean / repair-collapse clear more coherently on Side B when under-target, slow-rate, concealment, decrypt, decode, sender, and queue signals are calm.
  • Profile strength is not the next target from this call. Baseline is not the next target. No new profile is justified.

Call: 2026-05-11 13:38Z / group 812 3-person multi-source follow-up

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-11T13-38-40-156Z.json
  • Side B: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-11T13-42-52-482Z.json
  • Side C: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-11T13-38-34-883Z.json

User symptom:

  • New 3-person group call after the multi-source changes. Root was not able to hear the third participant, but standby was able to hear the third participant.

High-level verdict:

  • Mixed/bad, with one source-specific multi-source playout-readiness failure.
  • All three exports agree on room gcall-qortal-812, topology epoch 2, root QNardT...ZAWL, standby QP9Jj4...i6rP, participant count 3, room key presence, and media session generation 1.
  • The root-side failure matches the diagnostics directly: root has a playout for third participant QMe6E7...6VFZ, but jitterHasReadyFrame=false for that source in all 102/102 retained multi-source samples. Standby has the same third participant ready in 300/300 retained samples.
  • This is not primarily a profile-strength or baseline miss. The failed root source is already in multi-protected-recovery with protected target/floor/boost applied, but it never becomes ready.

Not the problem:

  • Decrypt: packetsDroppedPendingDecrypt=0, pending-decrypt deltas 0, and pendingDecryptDepth=0 on all three exports.
  • Decode: packetsDroppedDecodeFailure=0, decoder throws 0, and decode-failure deltas 0 on all three exports.
  • Queue/backpressure: bridge waiting-for-drain is false, no queue-pressure drops, no stale drops, no link-unready drops, no packet send failures; bridge high-water is low (4, 2, 2).
  • Failover/authority: no promotion/demotion counts, all sides agree on root/standby/topology/session state.
  • Sender: all sides have outbound sends succeeding and outboundNoTargetSkipsDelta=0; sender worklet-to-encoder timing is normal.
  • Baseline: the bad source is already above baseline policy in multi-protected-recovery, so a global baseline increase is not the next lever.

Primary next target:

  • Another subsystem: multi-source per-source playout readiness / source activation path.
  • Specifically inspect why root receiving QMe6E7...6VFZ can have an active playout, active decoder/ring/scheduler, jitterBufferedFrames=12, lastAppliedTargetMs=240, and lastAppliedFloorMs=224, but still export jitterHasReadyFrame=false for the whole retained multi-source window.
  • Do not tune selector first: root classified the unheard source as multi-protected-recovery, which is the expected strong profile for a source that is not audibly ready.
  • Do not tune profile strength first: stronger targets will not fix a source that never flips ready despite buffered frames.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QNardT...ZAWL receiving standby QP9Jj4...i6rP multi-protected-recovery; earlier single-source churn no symptom for standby leg 75.129 1664 99 0.092 0.037 low-latency Standby leg is ready in 300/300 samples; prior single-source clean/weak churn remains but does not explain the reported third-participant silence.
A root-forwarder / Linux / QNardT...ZAWL receiving participant QMe6E7...6VFZ multi-protected-recovery yes, root could not hear this participant 75.129 1664 99 0.092 0.037 low-latency Failed leg. Source exists, output count is 2, protected profile is active, but jitterHasReadyFrame=false for 102/102 retained samples.
B standby-forwarder / Linux / QP9Jj4...i6rP receiving root QNardT...ZAWL multi-protected-recovery not reported bad 13.044 3660 85 0.003 0.001 low-latency Conservative protected classification for root, but playout is ready in 294/300 retained samples and no user symptom points here.
B standby-forwarder / Linux / QP9Jj4...i6rP receiving participant QMe6E7...6VFZ multi-clean-low-latency no, standby could hear this participant 13.044 3660 85 0.003 0.001 low-latency This is the control leg. Same third participant is ready in 300/300 retained samples and classified clean.
C participant / Linux / QMe6E7...6VFZ receiving root QNardT...ZAWL multi-protected-recovery unknown; metrics bad 8.997 527 2066 0.077 0.075 recovery Participant hears root with ready playout after startup, but has heavy concealment and shallow reserve. Classification matches metric severity.
C participant / Linux / QMe6E7...6VFZ receiving standby QP9Jj4...i6rP multi-protected-recovery unknown; metrics bad 8.997 527 2066 0.077 0.075 recovery Participant hears standby with ready playout after startup, but the side is generally in protected recovery.

Side A

Expected profile from symptom:

  • For root receiving third participant: multi-protected-recovery or a startup/playout-not-ready class. Since the source is present but inaudible, protected recovery is reasonable, but readiness must become true.

Actual exported profile:

  • Standby source QP9Jj4...i6rP: live multi-protected-recovery.
  • Third participant source QMe6E7...6VFZ: live multi-protected-recovery.
  • Retained profile counts after the third participant joined: standby source multi-protected-recovery (102); third participant source multi-protected-recovery (101) plus one multi-clean-low-latency sample.

Did classification match?

  • Yes for the bad source, but the subsystem outcome failed.

Notes:

  • The third-participant source was not ignored: root has sourceAddrs=["QP9Jj4...i6rP","QMe6E7...6VFZ"], outputNodeCount=2, decoder count 2, playback node count 2, jitter buffer count 2, and active WASM-FEC/shared-ring playouts for both sources.
  • The failing source never became ready in the retained multi-source window: jitterHasReadyFrame=false in 102/102 samples, including the export-time playout with jitterBufferedFrames=12.
  • That shape fits the template's startup/playout-ready warning more than receive-policy tuning: buffered frames exist, protected profile is selected, but there is no real ready playout.

Side B

Expected profile from symptom:

  • For standby receiving third participant: multi-clean-low-latency or brief multi recovery, because standby could hear the third participant.

Actual exported profile:

  • Third participant source QMe6E7...6VFZ: live multi-clean-low-latency, retained multi-clean-low-latency for 300/300 samples.
  • Root source QNardT...ZAWL: live multi-protected-recovery, retained multi-protected-recovery for 300/300 samples.

Did classification match?

  • Yes for the third-participant symptom.
  • Partly/too conservative for the root source, but that is not the reported failure.

Notes:

  • Standby is the control evidence that the third participant's outbound audio was available and decodable in the room.
  • Standby receiving the third participant has jitterHasReadyFrame=true for 300/300 retained samples and low current pressure (playoutUnderTargetFraction=0.003, playoutRateFractionBelow097=0.001, concealmentTicks=85 total side-wide).

Side C

Expected profile from symptom:

  • No user symptom was reported for what the third participant heard. From metrics alone, multi-protected-recovery is expected.

Actual exported profile:

  • Root source QNardT...ZAWL: live multi-protected-recovery, retained multi-protected-recovery for 90/92 classified samples after a short silent-lean startup.
  • Standby source QP9Jj4...i6rP: live multi-protected-recovery, retained multi-protected-recovery for 90/90 classified samples.

Did classification match?

  • Yes from metrics; user-level correctness is unknown.

Notes:

  • Participant side is shallow and repair-heavy: avgPcmBufferedMs=8.997, concealmentTicks=2066, playoutUnderTargetFraction=0.077, playoutRateFractionBelow097=0.075.
  • Both playouts are ready in most retained samples (86 ready samples per source after startup), so this is not the same failure shape as root receiving participant.

Trend Read

Side A:

  • Discrete multi-source join event followed by a stuck not-ready source.
  • Reasons seen:
    • topology changes from epoch 1 to epoch 2 when the third participant joins.
    • root's third-participant playout is jitterHasReadyFrame=false in all 102 retained multi-source samples.
    • the same source transitions into multi-protected-recovery almost immediately, so selector did recognize the bad leg.
    • no decrypt, decode, no-target, send-failure, or queue-pressure deltas.

Side B:

  • Stable control side for the reported symptom.
  • Reasons seen:
    • third-participant playout is ready for 300/300 retained samples.
    • third-participant profile is multi-clean-low-latency for 300/300 retained samples.
    • no decrypt, decode, no-target, send-failure, or queue-pressure deltas.

Side C:

  • Startup into protected recovery with heavy repair/concealment.
  • Reasons seen:
    • recovery mode for 92/93 retained samples.
    • both remote sources settle into ready playout after the first few startup samples.
    • high concealment (2066) and shallow reserve justify protected recovery, but this side was not the reported root-hearing-third failure.

Batch Scoreboard Update

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-11T13:38Z group-812 3p A / Linux root receiving standby multi-protected-recovery no symptom for this leg partly conservative receive / residual selector churn Do not target from this symptom; keep observing root/standby protected classification separately.
2026-05-11T13:38Z group-812 3p A / Linux root receiving participant multi-protected-recovery yes, root could not hear third participant yes startup/playout-ready subsystem Fix multi-source per-source readiness/source activation: source is protected and buffered but never ready.
2026-05-11T13:38Z group-812 3p B / Linux standby receiving root multi-protected-recovery not reported bad partly conservative receive selector, secondary Not next target for this symptom; avoid broad profile-strength changes.
2026-05-11T13:38Z group-812 3p B / Linux standby receiving participant multi-clean-low-latency no, standby could hear third participant yes no issue for reported symptom No change. This is the control leg.
2026-05-11T13:38Z group-812 3p C / Linux participant receiving root multi-protected-recovery unknown; metrics bad yes from metrics profile strength / recovery quality, secondary Track separately; not the next fix for root unable to hear participant.
2026-05-11T13:38Z group-812 3p C / Linux participant receiving standby multi-protected-recovery unknown; metrics bad yes from metrics profile strength / recovery quality, secondary Track separately; not the next fix for root unable to hear participant.

Next Fix Target

Current patched target:

  • Another subsystem: multi-source per-source playout readiness / source activation.
  • Primary fix: inspect the receive playout/jitter readiness path for a newly added third source on the root. The failing leg has an active playout and protected profile, but jitterHasReadyFrame=false for the entire retained window while the same source is ready on standby.
  • Secondary fix: keep profile-strength work for participant-side protected recovery quality on the list, but do not apply it as the next patch from this symptom.
  • Selector is not the next target for the reported failure because classification for the unheard source was already strong (multi-protected-recovery). Baseline is not the next target. Do not add a new profile from this call.

Call: 2026-05-12 11:50Z / group 812 2-person latest-code quality check

Room:

  • gcall-qortal-812

Files:

  • Side A: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-12T11-50-43-149Z.json
  • Side B: /home/qortal/Downloads/Telegram Desktop/qortal-gcall-diagnostics-2026-05-12T11-50-45-893Z.json

User symptom:

  • Linux has the latest code. Mac heard Linux very well, but Linux heard Mac choppy.

High-level verdict:

  • Mixed/bad, asymmetric receive quality.
  • Both senders look healthy on the current capture path: 48000 Hz input, 960 sample frames, no encoder drops, no send failures, and link transport active in both directions.
  • Mac receiving Linux is near-clean for the sampled window. Linux receiving Mac is still bad: 628 missing frames, 43 concealment ticks, repeated receive-profile churn, and burst-like inbound timing.

Not the problem:

  • Bootstrap/seeding: not involved in this symptom.
  • Link establishment: both sides are connected over link transport, with successful outbound sends and inbound link samples.
  • Sender/capture: both sides export canonical 48k/960 capture and encode successfully.
  • Decrypt/decode: packetsDroppedPendingDecrypt=0, pendingDecryptDepth=0, and packetsDroppedDecodeFailure=0 on both sides.
  • Queue/backpressure: no queue-pressure drops, stale drops, link-unready drops, packet send failures, or bridge waiting-for-drain pressure in the live window.
  • Startup readiness: both sides have active playout, active scheduler/playback nodes, and jitterHasReadyFrame=true at export time.
  • Global baseline: Mac is good under the same baseline, so baseline is not the first lever.

Primary next target:

  • Another subsystem: receive burst absorption / jitter-buffer overflow diagnostics on the Linux receive path.
  • The profile selector detects damage, but the profile labels are not the source of the damage. Linux gets missing-frame bursts while its jitter buffer is often already near 20-24 frames and ready, which points to sequence gaps created inside receive buffering rather than starvation, sender failure, or decode failure.
  • Add direct jitter push/trim diagnostics and then tune the jitter-buffer capacity/trim behavior if trims confirm the inferred overflow path. Do not tune sender, bootstrap, or baseline from this call.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QP9Jj4...i6rP receiving QaU2XU...Jh91 steady-weak-listener dominant; live silent-lean; repair/collapse churn yes, Linux heard Mac choppy 13.447 628 43 0.013 0.008 recovery Bad side. Decode and link are clean. Missing-frame deltas recur while jitterBufferedFrames is often 20-24, including +70, +26, +21, +19, and +15 bursts.
B standby-forwarder / macOS / QaU2XU...Jh91 receiving QP9Jj4...i6rP clean-low-latency dominant; live repair-heavy-connected no, Mac heard Linux well 85.612 10 0 0.055 0.000 recovery Good side. Mostly clean-low-latency, no concealment, only 10 missing frames total, and no renderer stalls. Late repair-heavy state is conservative relative to the user symptom.

Side A

Expected profile from symptom:

  • A receive-damage profile is expected because Linux heard Mac choppy.
  • The exported bad shape should ideally land in a profile that explains bursty receive damage, not a lean/silent profile that implies mostly reserve geometry.

Actual exported profile:

  • Current exported profile: silent-lean.
  • Retained profile counts: steady-weak-listener (47), buffered-not-ready (11), silent-lean (10), repair-heavy-connected (7), collapse-recovery (7), persistent-lean (1).

Did classification match?

  • Partly.

If no:

  • The selector correctly sees that the side is damaged and keeps the side in recovery, but the labels churn between lean, buffered-not-ready, repair-heavy, and collapse.
  • The actual failure signature is stronger than the live silent-lean label: high missing frames with clean transport/decode and ready jitter buffers.
  • This is not a simple selector-only bug. The selector is reacting to damage that appears to be produced by the receive buffering path.

Side B

Expected profile from symptom:

  • Mostly clean-low-latency, because Mac heard Linux well.

Actual exported profile:

  • Current exported profile: repair-heavy-connected.
  • Retained profile counts: clean-low-latency (56), repair-heavy-connected (8), steady-weak-listener (7), buffered-not-ready (2), silent-lean (1).

Did classification match?

  • Mostly yes for the retained window; live state is conservative.

If no:

  • The late repair-heavy-connected label is too strong for the user symptom and the cumulative metrics, but it is not the reported bad direction.
  • This should not drive a profile-strength increase.

Trend Read

Side A:

  • Oscillating receive damage with burst-like missing-frame jumps.
  • Reasons seen:
    • recovery mode for 77/96 retained samples.
    • total missing-frame delta 628 and concealment delta 43.
    • repeated missing bursts while jitter has frames and is often ready: examples include +70 with jitterBufferedFrames=22, +26 with 9, +19 with 24, +15 with 22, and +21 with 22.
    • no decrypt, decode, send-failure, no-target, link-unready, stale-drop, or queue-pressure deltas.
    • one renderer stall was recorded on Linux, but the active pattern is repeated receive missing bursts, not a single startup stall.

Side B:

  • Stable/good receive direction with conservative late recovery.
  • Reasons seen:
    • total missing-frame delta 10, concealment delta 0.
    • mostly clean-low-latency retained samples.
    • no renderer stalls or long tasks.
    • no decrypt, decode, send-failure, no-target, link-unready, stale-drop, or queue-pressure deltas.

Batch Scoreboard Update

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-12T11:50Z group-812 2p A / Linux root receiving Mac steady-weak-listener; live silent-lean; repair/collapse churn yes partly receive jitter-buffer / burst absorption Add direct jitter push/trim diagnostics, then fix buffer trim/capacity behavior if confirmed. Do not target sender, bootstrap, or baseline.
2026-05-12T11:50Z group-812 2p B / macOS standby receiving Linux clean-low-latency; live repair-heavy-connected no mostly yes; live label conservative no issue for reported symptom / selector secondary No profile-strength change from this side. Track late conservative repair-heavy separately.

Next Fix Target

Current patched target:

  • Another subsystem: receive burst absorption / jitter-buffer overflow visibility.
  • Primary fix: expose jitter-buffer push outcomes in diagnostics, especially accepted, stale, duplicate, trimmed count, high-water depth, and last trim event per source.
  • If trims line up with Linux missing-frame bursts, tune the jitter-buffer cap/trim policy for single-source recovery so bursty inbound delivery does not discard valid frames and then report the discard as missing audio.
  • Selector is secondary because it reacts after the damage. Profile strength is not the next target. Baseline is not the next target. No new profile is justified from this call.

Call: 2026-05-13 21:40Z / group 937 3-person latest-code multi-source check

Room:

  • gcall-qortal-937

Files:

  • Side A: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-13T21-40-11-400Z.json
  • Side B: /home/qortal/Downloads/seth-kenny-phil-14.json
  • Side C: /home/qortal/Downloads/qortal-gcall-diagnostics-2026-05-13T21-39-44-545Z.json

User symptom:

  • New 3+ multi-party group-call check after the recent changes. No side-specific spoken symptom was provided with the exports.
  • Metric symptom: all three sides remain in multi-source protected recovery for both remote sources, with repeated missing-frame/concealment bursts while playouts are usually ready and jitter buffers are at or near trim pressure.

High-level verdict:

  • Bad/mixed, but improved diagnostic clarity.
  • This is not the prior hidden-startup case where a source was buffered but never became ready. In this batch every side has active playouts, active schedulers/playback nodes, and mostly ready samples for both remote sources.
  • The common failure shape is jitter trim pressure in multi-source recovery: large missing-frame bursts line up with per-source jitter buffers at high water and jitterPushTrimmedFrames increasing.

Not the problem:

  • Pending decrypt/key: packetsDroppedPendingDecrypt=0, pending-decrypt deltas 0, and pendingDecryptDepth=0 on all three exports.
  • Current decode path: root has 5 historical decode failures and participant has 40, but totalDecodeFailureDelta=0 in all retained windows, so decode/key mismatch is not the active sampled failure.
  • Sender/no-target: all retained windows have totalNoTargetSkipsDelta=0, outbound sends succeed, and link transport is active.
  • Queue/backpressure: no queue-pressure drops, stale drops, link-unready drops, packet send failures, or bridge drain waits. Decoded queue high-water exists, but no transport-queue drops explain the bursts.
  • Startup readiness: all six remote playouts are ready in most retained samples and ready at export time; this is not a source-activation/not-ready regression.
  • Baseline: every leg is already above baseline in multi-protected-recovery, so a global baseline bump is not the first lever.

Primary next target:

  • Another subsystem: multi-source jitter-buffer push/trim behavior under recovery.
  • The next patch should tune or fix per-source jitter cap/headroom/trim policy and sequence-gap accounting in multi-source recovery. The new trim diagnostics confirm the earlier suspected overflow/trim path: large missing-frame deltas appear when jitter buffers are at 40/40 or have just trimmed.
  • Selector is not the next target because all six legs are classified as multi-protected-recovery. Profile strength is secondary because stronger targets do not help if valid frames are being trimmed at the jitter cap. Baseline is not the next target.
Side Role Dominant Profile User-Bad? avgPcmBufferedMs missingFrames concealmentTicks UnderTarget Rate<0.97 Adaptive Mode Notes
A root-forwarder / Linux / QeJW96...j5W9 receiving participant QP9Jj4...i6rP multi-protected-recovery unknown; metrics bad 55.843 801 205 0.014 0.006 low-latency Ready in 291/300 samples. +147, +97, and +226 missing bursts occur with ready jitter buffers and trim pressure; current playout has 925 trimmed frames.
A root-forwarder / Linux / QeJW96...j5W9 receiving standby QTSzRS...9jMn multi-protected-recovery unknown; metrics bad 55.843 801 205 0.014 0.006 low-latency Ready in 292/300 samples. Large bursts at 21:32:09 and 21:38:39 line up with this leg trimming from high-water.
B standby-forwarder / Linux / QTSzRS...9jMn receiving root QeJW96...j5W9 multi-protected-recovery unknown; metrics bad 94.173 1333 209 0.018 0.012 low-latency Ready in 294/300 samples. One burst briefly shows jitterHasReadyFrame=false, but most retained samples are ready; current trim total is 287.
B standby-forwarder / Linux / QTSzRS...9jMn receiving participant QP9Jj4...i6rP multi-protected-recovery unknown; metrics bad 94.173 1333 209 0.018 0.012 low-latency Ready in 287/300 samples. Heavy trim pressure: current trim total is 1030, with +165, +218, +107, and +393 missing bursts.
C participant / Linux / QP9Jj4...i6rP receiving root QeJW96...j5W9 multi-protected-recovery unknown; metrics bad 12.200 2013 318 0.003 0.002 low-latency Ready in 291/300 samples. Very shallow side-wide reserve, but bursts happen while this source is ready and near cap; current trim total is 812.
C participant / Linux / QP9Jj4...i6rP receiving standby QTSzRS...9jMn multi-protected-recovery unknown; metrics bad 12.200 2013 318 0.003 0.002 low-latency Ready in 283/300 samples. Strongest trim pressure in this export: current trim total is 1226, including +366, +488, +22, and +289 missing bursts.

Side A

Expected profile from symptom:

  • With no side-specific user symptom, the metric symptom expects a multi-source recovery profile rather than clean-low-latency.

Actual exported profile:

  • Participant QP9Jj4...i6rP: multi-protected-recovery for 300/300 retained samples.
  • Standby QTSzRS...9jMn: multi-protected-recovery for 300/300 retained samples.

Did classification match?

  • Yes for the metric symptom.

Notes:

  • The selector is not missing the bad state. The root side is already protected for both sources.
  • The failure is downstream of classification: missing bursts occur while playouts are ready and the jitter buffers are at/near trim pressure.

Side B

Expected profile from symptom:

  • Multi-source protected recovery is expected from the retained-window metric damage.

Actual exported profile:

  • Root QeJW96...j5W9: multi-protected-recovery for 300/300 retained samples.
  • Participant QP9Jj4...i6rP: multi-protected-recovery for 300/300 retained samples.

Did classification match?

  • Yes for the metric symptom.

Notes:

  • This side has high reserve on paper (avgPcmBufferedMs=94.173) but still has 905 missing-frame delta and 148 concealment delta in the retained window.
  • That combination argues against simply raising profile strength; the buffer is not globally empty, yet per-source trims and sequence gaps still create missing audio.

Side C

Expected profile from symptom:

  • Multi-source protected recovery is expected: this is the most damaged side by totals and has shallow side-wide reserve.

Actual exported profile:

  • Root QeJW96...j5W9: multi-protected-recovery for 300/300 retained samples.
  • Standby QTSzRS...9jMn: multi-protected-recovery for 300/300 retained samples.

Did classification match?

  • Yes for the metric symptom.

Notes:

  • Participant-side metrics are worst overall: 1184 missing-frame delta, 193 concealment delta, avgPcmBufferedMs=12.2.
  • Even here, the burst evidence points at jitter trimming: both remote playouts are ready in most samples, and large bursts occur with jitterBufferedFrames around 39-40 plus trim pressure.

Trend Read

Side A:

  • Oscillating/discrete trim-pressure bursts.
  • Reasons seen:
    • retained-window damage: 500 missing-frame delta and 130 concealment delta.
    • large bursts: +147, +97, +226, and +20.
    • all retained profile samples are multi-protected-recovery.
    • both playouts are mostly ready and current jitter cap/high-water is 40.

Side B:

  • Oscillating/discrete trim-pressure bursts.
  • Reasons seen:
    • retained-window damage: 905 missing-frame delta and 148 concealment delta.
    • large bursts: +165, +218, +107, and +393.
    • participant leg is heavily trimmed (1030 current trimmed frames), and root leg also reaches trim-pressure headroom by export time.

Side C:

  • Worst burst damage, shallow reserve, but still not a startup-not-ready shape.
  • Reasons seen:
    • retained-window damage: 1184 missing-frame delta and 193 concealment delta.
    • large bursts: +366, +488, +22, and +289.
    • both source buffers hit high-water 40; trim totals are 812 and 1226.

Batch Scoreboard Update

Call Side Dominant Profile User-Bad? Classification Correct? Main Issue Class Next Action
2026-05-13T21:40Z group-937 3p A / Linux root receiving participant multi-protected-recovery unknown; metrics bad yes jitter push/trim subsystem Tune multi-source jitter cap/headroom/trim behavior; selector/profile strength are not first.
2026-05-13T21:40Z group-937 3p A / Linux root receiving standby multi-protected-recovery unknown; metrics bad yes jitter push/trim subsystem Same multi-source trim target; watch source-specific trim events around missing bursts.
2026-05-13T21:40Z group-937 3p B / Linux standby receiving root multi-protected-recovery unknown; metrics bad yes jitter push/trim subsystem Fix burst handling; one not-ready sample is secondary, not the dominant failure.
2026-05-13T21:40Z group-937 3p B / Linux standby receiving participant multi-protected-recovery unknown; metrics bad yes jitter push/trim subsystem Highest trim pressure on this side; prioritize per-source trim/cap behavior.
2026-05-13T21:40Z group-937 3p C / Linux participant receiving root multi-protected-recovery unknown; metrics bad yes jitter push/trim subsystem Fix trim-induced sequence gaps before changing profile targets.
2026-05-13T21:40Z group-937 3p C / Linux participant receiving standby multi-protected-recovery unknown; metrics bad yes jitter push/trim subsystem Strongest evidence: large bursts with 40/40 buffers and 1226 current trimmed frames.

Next Fix Target

Current patched target:

  • Another subsystem: multi-source jitter-buffer push/trim behavior under recovery.
  • Primary fix: tune per-source jitter cap/headroom/trim policy so recovery-mode burst absorption does not trim valid near-future frames and then surface the gap as missing audio.
  • Secondary fix: check missing-frame accounting against trim events so intentionally trimmed-old frames are not misclassified as unexpected sequence gaps.
  • Selector is not the next target. Profile strength is not the next target until trim behavior is corrected. Baseline is not the next target. No new profile is justified from this batch.
Reference in New Issue View Git Blame Copy Permalink