Warum dein KI-Notetaker mitten im Meeting die Aufnahme stoppt

Am 2. Juli hat GeekBye eine Meeting-Aufnahme von sich aus beendet. Die Datenbankzeile sagt alles: ended_reason = 'idle', Dauer 519 Sekunden, 99 Transkript-Einträge — der letzte geschrieben zwei Sekunden bevor die App entschied, dass niemand da sei.

Der andere Teilnehmer war mitten in einer Erklärung. Die letzte Zeile des Transkripts ist buchstäblich ein Satzfragment: "...executes it or turns it on or so—".

Es war nicht das erste Mal. Am Abend zuvor endete eine andere Session auf dieselbe Weise. Zwei Meetings, gekillt von unserem eigenen Zuverlässigkeits-Feature. Hier ist die Diagnose und der Fix, der in GeekBye v2.0.9 ausgeliefert wurde — plus ein zweiter, gruseligerer Bug, den wir im selben Release behoben haben.

Ein gut gemeinter Timer, der nur dich hören konnte

Das Idle-Auto-Close existiert aus gutem Grund. Leute vergessen Aufnahmen, die über Nacht laufen; ein offen gelassener Meeting-Tab tröpfelt endlos Audio. Also achtet GeekBye auf Inaktivität: Nach 60 Sekunden ohne Sprachaktivität zeigt es eine kleine "Still recording?"-Abfrage („Nimmst du noch auf?"), und 30 Sekunden später, unbeantwortet, beendet es die Session — speichert alles, ganz höflich.

Der Fehler steckte in einem Wort: Sprach-Aktivität. Die Aktivitätsuhr zählte ausschließlich anhaltende Mikrofonenergie. Das war eine bewusste Designentscheidung, und keine dumme — rohe Systemaudio-Energie zu zählen würde einem stummgeschalteten, aber lauten Tab erlauben, eine tote Session unbegrenzt am Leben zu halten: genau der Fehlerfall, den das Feature verhindern soll. Meetings, in denen du hauptsächlich zuhörst, sollten von der Meeting-Fenster-Erkennung abgedeckt werden.

Nur: Die Meeting-Erkennung sieht nicht jedes Meeting. Browser-Tabs, ungewöhnliche Clients, eine Präsentation, die du dir ansiehst — unerkannt. Und in einem unerkannten Meeting, in dem du 90 Sekunden lang zuhörst — etwas völlig Normales, während jemand seine Databricks-Pipeline erklärt — bist du für die Idle-Uhr von einem leeren Raum nicht zu unterscheiden.

Sieh dir die Timeline der gekillten Session an: Das letzte Transkript von unserem Mikrofon kam 68 Sekunden vor dem Ende. Dann 60 Sekunden, in denen die andere Person spricht (perfekt transkribiert, von der Uhr ignoriert), die unbemerkte Abfrage, der 30-Sekunden-Countdown und der Kill — 2 Sekunden nach ihren letzten Worten.

Der Fix: Ein Transkript ist ein Lebenszeichen

Die Korrektur ist im Nachhinein fast peinlich: Ein eingehendes Transkript ist der stärkste mögliche Beweis, dass die Session nicht idle ist. Es ist egal, wer gesprochen hat. Das Sprachmodell hat gerade Worte erkannt — das ist das Meeting.

Also stempelt v2.0.9 die Aktivitätsuhr bei jedem Transkript, das ankommt, egal von welcher Seite. Rohe Systemaudio-Energie zählt weiterhin nicht — Musik, Warteschleifentöne und Klimaanlagen-Brummen können eine tote Session immer noch nicht verewigen, und das harte Aufnahmelimit sichert weiterhin alles ab. Nur erkannte Sprache hält eine Session am Leben — und genau das ist die richtige Grenze.

Ein Detail aus dem Code-Review, das es wert ist, weitergegeben zu werden: Die erste Version des Fixes stempelte die Uhr innerhalb des Sprecher-Attributionspfads — den eine Teilmenge der Transkripte legitim überspringen kann. Das Review erkannte, dass eine zukünftige Änderung den Bug stillschweigend genau für die Transkripte wieder einführen könnte, auf die es ankommt (die des anderen Sprechers). Der Stempel ist jetzt bedingungslos, vor jeder Verzweigung, mit einem Test, der fehlschlägt, wenn ihn jemand verschiebt.

Dasselbe Release hat etwas Gruseligeres behoben

Beim Testen dieser Fixes traf uns ein anderer Bug auf die harte Tour: Ein Crash im Interface-Prozess ließ den gesamten Desktop unklickbar zurück.

GeekByes Overlay ist ein transparentes, immer im Vordergrund liegendes Fenster, das deinen Bildschirm bedeckt. Standardmäßig ist es click-through; das Interface schaltet es auf interaktiv, wenn du ein Panel benutzt. Diese Umschaltungen kommen aus dem Interface-Prozess — als dieser Prozess also crashte, während ein Panel offen war, blieb das unsichtbare Fenster im interaktiven Modus, ohne lebende UI dahinter. Jeder Klick auf deinem Desktop landete auf einer toten, unsichtbaren Fläche. Der einzige Ausweg war, die App zwangsweise zu beenden.

Der Crash-Handler von v2.0.9 stellt Click-Through jetzt sofort wieder her und lädt das Interface neu — mit einem Limit von drei Reloads pro Minute, damit eine Crash-Schleife nicht ewig weiterdrehen kann (jenseits des Limits gibt die App das Neuladen auf, aber dein Desktop bleibt benutzbar, und das ist der Teil, der zählt). Auch hier hat das Code-Review nachgeschärft: Die Wiederherstellung ist gezielt auf das Overlay-Fenster beschränkt, denn Click-Through pauschal auf ein gecrashtes normales Fenster anzuwenden — etwa den Update-Dialog — hätte die umgekehrte Sperre erzeugt.

Du kannst diesen Fix selbst überprüfen, ganz brutal: Öffne ein GeekBye-Panel, erzwinge in der Aktivitätsanzeige das Beenden des Prozesses "GeekBye Helper (Renderer)" und sieh zu, wie die App deinen Desktop innerhalb einer Sekunde zurückholt.

Was uns dieses Bug-Paar gelehrt hat

1. Jeder Proxy für „ist der Nutzer noch da?" versagt irgendwo. Mikrofonenergie versagt bei Zuhörern. Fenstererkennung versagt bei Browsern. Erkannte Transkripte versagen bei... nichts, das wir bisher gefunden hätten, denn sie sind kein Proxy — sie sind das Produkt selbst.
2. Alles, was der Renderer steuert, braucht eine Crash-Story. Wenn ein toter UI-Prozess Zustand auf OS-Ebene hinterlassen kann (Maus-Capture, Always-on-Top, Content Protection), muss der Main-Prozess den Reset besitzen.
3. Der eigene intensivste Nutzer zu sein ist eine Strategie, um Bugs zu finden. Beide Bugs trafen uns in echten Meetings, bevor mehr als eine Handvoll Kunden sie bemerkten. Die ended_reason-Spalte, die wir Monate zuvor für Observability hinzugefügt hatten, machte aus der Diagnose eine Datenbankabfrage statt einer Vermutung.

Beide Fixes gingen innerhalb eines Tages von der Diagnose zu einem ausgelieferten, notarisierten Release, jeder getragen von einem reviewten PR mit Regressionstests. Wenn du auf GeekBye v2 bist, hast du sie seit v2.0.9 per Auto-Update.

Für den Rest der Geschichte dieses Releases siehe den Serien-Nachbarn warum KI-Transkription Fachbegriffe falsch versteht (v2.0.11), das Zuverlässigkeits-Fundament in warum dein KI-Notetaker bei schlechtem WLAN stoppt und wie das Overlay beim Screen-Sharing unsichtbar bleibt, ohne deine Klicks zu stehlen.