Callopname publiceert 50 keer per seconde een nieuwe toestand voor een teller #2760

New issue

Open

opened 2026-11-02 23:47:03 +00:00 by brenno · 1 comment

brenno commented

2026-11-02 23:47:03 +00:00

Owner

Gevonden in de kritische review van 03-11-2026 (prestaties).

Wat er misgaat

Tijdens een callopname publiceert CallRecordingNotifier._onLiveTick (lib/state/call_recording_provider.dart r. 226–229) voor elke mix-tik van 20 ms een nieuwe toestand: capturedChunks + 1. Dat zijn 50 notificaties per seconde, zolang de opname loopt. Elke watcher bouwt dus 50 keer per seconde opnieuw:

CallRecordingBanner (bannerkolom van de shell, boven elke tab), die alleen phase gebruikt;
CallRecordingSection in het callpaneel, met zijn hele kolom aan opt-ins en knoppen.

Het enige wat dit voedt is de regel "Ontvangen brokken: N". Op 50 Hz is die niet te lezen. Hij bewijst alleen dát er audio binnenkomt, en daarvoor volstaat één keer per seconde.

Gevolg

Tijdens een call, juist wanneer de machine ook video decodeert en de mix schrijft, dwingt dit continu frames af. Kost CPU en, op een laptop op de accu, stroom.

Voorstel

De teller blijft intern per tik oplopen, maar state wordt alleen gepubliceerd bij de eerste tik en daarna hooguit één keer per seconde.
De banner kijkt via select alleen naar phase.

Wat overeind moet blijven

De eerste tik is meteen zichtbaar (capturedChunks == 1), want daarop wachten de bestaande toetsen en de "het loopt"-bevestiging.
Fases en foutafhandeling zijn ongewijzigd.

Test

Providertoets: 100 tikken binnen een seconde leveren hooguit twee notificaties op, en de teller bereikt na afloop de juiste waarde. Rood op de huidige code (100 notificaties).

Gevonden in de kritische review van 03-11-2026 (prestaties). ## Wat er misgaat Tijdens een callopname publiceert `CallRecordingNotifier._onLiveTick` (`lib/state/call_recording_provider.dart` r. 226–229) voor **elke** mix-tik van 20 ms een nieuwe toestand: `capturedChunks + 1`. Dat zijn 50 notificaties per seconde, zolang de opname loopt. Elke watcher bouwt dus 50 keer per seconde opnieuw: - `CallRecordingBanner` (bannerkolom van de shell, boven elke tab), die alleen `phase` gebruikt; - `CallRecordingSection` in het callpaneel, met zijn hele kolom aan opt-ins en knoppen. Het enige wat dit voedt is de regel "Ontvangen brokken: N". Op 50 Hz is die niet te lezen. Hij bewijst alleen dát er audio binnenkomt, en daarvoor volstaat één keer per seconde. ## Gevolg Tijdens een call, juist wanneer de machine ook video decodeert en de mix schrijft, dwingt dit continu frames af. Kost CPU en, op een laptop op de accu, stroom. ## Voorstel - De teller blijft intern per tik oplopen, maar `state` wordt alleen gepubliceerd bij de eerste tik en daarna hooguit één keer per seconde. - De banner kijkt via `select` alleen naar `phase`. ## Wat overeind moet blijven - De eerste tik is meteen zichtbaar (`capturedChunks == 1`), want daarop wachten de bestaande toetsen en de "het loopt"-bevestiging. - Fases en foutafhandeling zijn ongewijzigd. ## Test Providertoets: 100 tikken binnen een seconde leveren hooguit twee notificaties op, en de teller bereikt na afloop de juiste waarde. Rood op de huidige code (100 notificaties).

brenno added the

bug

in-progress

labels

2026-11-02 23:47:03 +00:00

brenno commented

2026-11-02 23:47:21 +00:00

Author

Owner

Opgepakt (kritische review 03-11-2026). Tak: perf/call-recording-ticks-2760. Verwachte reikwijdte: lib/state/call_recording_provider.dart, call_recording_controls.dart (banner select), test/meetings/call_recording_test.dart.