Waarom je AI-notulist midden in een meeting stopt met opnemen

Op 2 juli beëindigde GeekBye uit zichzelf een meetingopname. De databaserij zegt alles: ended_reason = 'idle', duur 519 seconden, 99 transcriptregels — de laatste weggeschreven twee seconden voordat de app besloot dat er niemand was.

De andere deelnemer was midden in een uitleg. De laatste regel van het transcript is letterlijk een zinsfragment: "...executes it or turns it on or so—".

Het was niet de eerste keer. De avond ervoor eindigde een andere sessie op precies dezelfde manier. Twee meetings, om zeep geholpen door onze eigen betrouwbaarheidsfeature. Dit is de diagnose en de fix die verscheen in GeekBye v2.0.9 — plus een tweede, engere bug die we in dezelfde release verhielpen.

Een goedbedoelde timer die alleen jou kon horen

De idle-autoclose bestaat met een goede reden. Mensen vergeten opnames die de hele nacht doorlopen; een opengelaten meetingtab blijft eindeloos audio druppelen. Dus GeekBye let op inactiviteit: na 60 seconden zonder stemactiviteit toont het een kleine "Still recording?"-prompt ("Nog aan het opnemen?"), en 30 seconden later, onbeantwoord, beëindigt het de sessie — alles netjes opgeslagen.

De fout zat in één woord: stem. De activiteitsklok telde alleen aanhoudende microfoonenergie. Dat was een bewuste ontwerpkeuze, en geen domme — rauwe systeemaudio-energie meetellen zou een gedempte maar luidruchtige tab een dode sessie eindeloos in leven laten houden, precies de fout die de feature moet voorkomen. Meetings waarin je vooral luistert zouden gedekt worden door meetingvensterdetectie.

Behalve dat meetingdetectie niet elke meeting kan zien. Browsertabs, ongebruikelijke clients, een presentatie waar je naar kijkt — ongedetecteerd. En in een ongedetecteerde meeting waarin je 90 seconden luistert — een volkomen normaal iets om te doen terwijl iemand zijn Databricks-pipeline uitlegt — ben je voor de idle-klok niet te onderscheiden van een lege kamer.

Bekijk de tijdlijn van de gesneuvelde sessie: het laatste transcript van onze microfoon kwam 68 seconden voor het einde. Daarna 60 seconden waarin de ander praatte (perfect getranscribeerd, genegeerd door de klok), de onopgemerkte prompt, het aftellen van 30 seconden, en de kill — 2 seconden na hun laatste woorden.

De fix: een transcript is bewijs van leven

De correctie is achteraf bijna gênant: een binnenkomend transcript is het sterkst mogelijke bewijs dat de sessie niet idle is. Het maakt niet uit wie er sprak. Het spraakmodel herkende zojuist woorden — dat is de meeting.

Dus v2.0.9 stempelt de activiteitsklok bij elk transcript dat binnenkomt, van welke kant dan ook. Rauwe systeemaudio-energie telt nog steeds niet mee — muziek, wachttonen en het gezoem van de airco kunnen een dode sessie nog steeds niet onsterfelijk maken, en de harde opnamelimiet blijft als vangnet overeind. Alleen herkende spraak houdt een sessie in leven, en dat is precies de juiste grens.

Eén detail uit de code review dat het doorgeven waard is: de eerste versie van de fix stempelde de klok binnen het sprekerattributiepad — dat een deel van de transcripts legitiem kan overslaan. Review ving op dat een toekomstige wijziging de bug stilletjes opnieuw kon introduceren voor precies de transcripts die ertoe doen (die van de andere spreker). De stempel staat nu onvoorwaardelijk, vóór elke vertakking, met een test die faalt als iemand hem verplaatst.

Dezelfde release verhielp iets engers

Tijdens het testen van deze fixes liepen we op de harde manier tegen een andere bug aan: een crash in het interfaceproces liet de hele desktop onklikbaar achter.

GeekBye's overlay is een transparant, always-on-top venster dat je scherm bedekt. Het is standaard click-through; de interface schakelt het interactief wanneer je een paneel gebruikt. Die schakelingen komen uit het interfaceproces — dus toen dat proces crashte terwijl een paneel open stond, bleef het onzichtbare venster in interactieve modus staan zonder levende UI erachter. Elke klik op je desktop landde op een dood, onzichtbaar paneel. De enige uitweg was de app geforceerd afsluiten.

De crashhandler van v2.0.9 herstelt nu onmiddellijk de click-through en herlaadt de interface — met een limiet van drie herlaadpogingen per minuut zodat een crash-loop niet eeuwig kan doordraaien (voorbij de limiet geeft de app het herladen op, maar je desktop blijft bruikbaar, en dat is het deel dat telt). Ook deze werd door code review aangescherpt: het herstel is specifiek beperkt tot het overlayvenster, want click-through botweg toepassen op een gecrasht normaal venster — zeg, de updatedialoog — zou precies de omgekeerde lock-out hebben gecreëerd.

Je kunt deze fix zelf verifiëren, op de harde manier: open een GeekBye-paneel, force-kill het proces "GeekBye Helper (Renderer)" in Activiteitenweergave, en zie hoe de app je desktop binnen een seconde teruggeeft.

Wat dit duo bugs ons leerde

1. Elke proxy voor "is de gebruiker er nog?" faalt ergens. Microfoonenergie faalt voor luisteraars. Vensterdetectie faalt voor browsers. Herkende transcripts falen voor... niets dat we tot nu toe vonden, want ze zijn geen proxy — ze zijn het product zelf.
2. Alles wat renderer-gestuurd is heeft een crashverhaal nodig. Als een dood UI-proces state op OS-niveau kan achterlaten (muiscapture, always-on-top, contentbescherming), moet het main-proces eigenaar zijn van de reset.
3. Je eigen zwaarste gebruiker zijn is een strategie om bugs te vinden. Beide bugs raakten ons in echte meetings voordat meer dan een handvol klanten iets merkte. De ended_reason-kolom die we maanden eerder voor observability hadden toegevoegd, maakte van de diagnose een databasequery in plaats van giswerk.

Beide fixes gingen binnen een dag van diagnose naar een uitgeleverde, genotariseerde release, elk gedragen door een gereviewde PR met regressietests. Zit je op GeekBye v2, dan heb je ze sinds v2.0.9 via auto-update.

Voor de rest van het verhaal van deze release, zie de serie-buur waarom AI-transcriptie technische termen verkeerd verstaat (v2.0.11), het betrouwbaarheidsfundament in waarom je AI-notulist stopt op slechte wifi, en hoe de overlay onzichtbaar blijft tijdens schermdelen zonder je klikken te stelen.