आपका AI notetaker मीटिंग के बीच में रिकॉर्डिंग क्यों बंद कर देता है

2 जुलाई को GeekBye ने खुद ही एक मीटिंग रिकॉर्डिंग खत्म कर दी। डेटाबेस की row सब कुछ कह देती है: ended_reason = 'idle', अवधि 519 सेकंड, 99 ट्रांसक्रिप्ट एंट्रीज़ — आखिरी एंट्री ऐप के "यहां कोई नहीं है" तय करने से दो सेकंड पहले लिखी गई।

सामने वाला पार्टिसिपेंट अपनी बात समझाने के बीच में था। ट्रांसक्रिप्ट की आखिरी लाइन सचमुच एक अधूरा वाक्य है: "...executes it or turns it on or so—".

यह पहली बार नहीं था। एक शाम पहले एक और सेशन ठीक इसी तरह खत्म हुआ था। दो मीटिंग्स, हमारे अपने ही reliability फीचर के हाथों खत्म। यहां है डायग्नोसिस और वह फिक्स जो GeekBye v2.0.9 में शिप हुआ — साथ में एक दूसरा, इससे भी डरावना बग जो हमने उसी रिलीज़ में ठीक किया।

एक नेक इरादे वाला टाइमर जो सिर्फ आपको सुन सकता था

Idle auto-close एक अच्छी वजह से मौजूद है। लोग रिकॉर्डिंग रातभर चलती छोड़ देते हैं; खुला छूटा मीटिंग टैब हमेशा के लिए ऑडियो टपकाता रहता है। इसलिए GeekBye निष्क्रियता पर नजर रखता है: 60 सेकंड बिना voiced गतिविधि के बीतते ही वह एक छोटा "Still recording?" (क्या रिकॉर्डिंग अभी भी चल रही है?) प्रॉम्प्ट दिखाता है, और 30 सेकंड बाद, जवाब न मिलने पर, सेशन खत्म कर देता है — सब कुछ सेव करके, विनम्रता से।

खोट एक ही शब्द में थी: voiced. Activity की घड़ी सिर्फ लगातार माइक्रोफोन एनर्जी गिनती थी। यह एक सोचा-समझा डिजाइन फैसला था, और बेवकूफी भरा भी नहीं — कच्ची system-audio एनर्जी गिनने से एक muted-लेकिन-शोरगुल वाला टैब किसी मरे हुए सेशन को हमेशा के लिए जिंदा रख सकता था, जो ठीक वही नाकामी है जिसे रोकने के लिए यह फीचर बना है। जिन मीटिंग्स में आप ज्यादातर सुनते हैं, उन्हें meeting-window detection से कवर होना था।

बस, meeting detection हर मीटिंग देख नहीं सकता। ब्राउज़र टैब, असामान्य क्लाइंट, कोई प्रेजेंटेशन जो आप देख रहे हैं — undetected. और एक undetected मीटिंग में जहां आप 90 सेकंड सुनते हैं — जो किसी के अपनी Databricks pipeline समझाने के दौरान बिल्कुल सामान्य बात है — आप idle घड़ी की नजर में एक खाली कमरे से अलग नहीं हैं।

खत्म किए गए सेशन की टाइमलाइन देखिए: हमारे माइक्रोफोन से आखिरी ट्रांसक्रिप्ट अंत से 68 सेकंड पहले आया था। फिर 60 सेकंड दूसरे व्यक्ति की बातचीत (पूरी तरह ट्रांसक्राइब हुई, घड़ी ने नजरअंदाज की), अनदेखा रह गया प्रॉम्प्ट, 30 सेकंड का काउंटडाउन, और किल — उनके आखिरी शब्दों के 2 सेकंड बाद।

फिक्स: ट्रांसक्रिप्ट ही जिंदा होने का सबूत है

सुधार पीछे मुड़कर देखने पर लगभग शर्मिंदा करने वाला है: एक आने वाला ट्रांसक्रिप्ट इस बात का सबसे मजबूत संभव सबूत है कि सेशन idle नहीं है। कौन बोला, इससे फर्क नहीं पड़ता। स्पीच मॉडल ने अभी-अभी शब्द पहचाने हैं — यही तो मीटिंग है।

इसलिए v2.0.9 हर आने वाले ट्रांसक्रिप्ट पर activity की घड़ी को स्टैम्प करता है, चाहे वह किसी भी तरफ से आए। कच्ची system-audio एनर्जी अब भी नहीं गिनी जाती — संगीत, hold tones और HVAC की भनभनाहट अब भी किसी मरे हुए सेशन को अमर नहीं बना सकते, और hard recording cap अब भी हर चीज का backstop है। सिर्फ पहचानी गई speech ही सेशन को जिंदा रखती है, जो बिल्कुल सही सीमा है।

Code review से निकली एक बात आगे बढ़ाने लायक है: फिक्स के पहले वर्जन ने घड़ी को speaker-attribution path के अंदर स्टैम्प किया था — जिसे ट्रांसक्रिप्ट्स का एक हिस्सा जायज तौर पर skip कर सकता है। Review ने पकड़ा कि भविष्य का कोई बदलाव इस बग को चुपचाप ठीक उन्हीं ट्रांसक्रिप्ट्स के लिए वापस ला सकता था जो सबसे ज्यादा मायने रखते हैं (दूसरे वक्ता के)। स्टैम्प अब बिना शर्त है, किसी भी branching से पहले, और साथ में एक टेस्ट है जो कोई उसे हिलाए तो fail हो जाता है।

उसी रिलीज़ ने कुछ और डरावना भी ठीक किया

इन फिक्सेस को टेस्ट करते हुए हम एक अलग बग से मुश्किल तरीके से टकराए: interface प्रोसेस में एक crash ने पूरा डेस्कटॉप unclickable छोड़ दिया।

GeekBye का overlay एक पारदर्शी, always-on-top विंडो है जो आपकी स्क्रीन को ढकती है। डिफॉल्ट रूप से यह click-through है; जब आप कोई पैनल इस्तेमाल कर रहे होते हैं तो interface उसे interactive कर देता है। ये toggles interface प्रोसेस से आते हैं — इसलिए जब वह प्रोसेस किसी खुले पैनल के साथ crash हुई, तो अदृश्य विंडो interactive मोड में अटकी रह गई और उसके पीछे कोई जिंदा UI नहीं था। आपके डेस्कटॉप का हर क्लिक एक मरे हुए, अदृश्य शीशे पर जाकर गिरता था। बचने का इकलौता रास्ता था ऐप को force-quit करना।

v2.0.9 का crash handler अब तुरंत click-through बहाल करता है और interface को reload करता है — प्रति मिनट तीन reloads की cap के साथ, ताकि कोई crash-loop हमेशा के लिए घूमता न रहे (cap के पार ऐप reload की कोशिश छोड़ देता है, लेकिन आपका डेस्कटॉप इस्तेमाल के लायक बना रहता है, जो असल में मायने रखने वाली बात है)। इसे भी code review ने और धारदार बनाया: रिकवरी खासतौर पर overlay विंडो तक सीमित है, क्योंकि किसी crashed सामान्य विंडो — मान लीजिए update dialog — पर आंख मूंदकर click-through लगा देना ठीक उल्टा lockout पैदा कर देता।

यह फिक्स आप खुद, बेरहमी से, verify कर सकते हैं: GeekBye का कोई पैनल खोलिए, Activity Monitor में "GeekBye Helper (Renderer)" प्रोसेस को force-kill कीजिए, और देखिए कि ऐप एक सेकंड के भीतर आपका डेस्कटॉप वापस लौटा देता है।

बगों की इस जोड़ी ने हमें क्या सिखाया

1. "क्या यूज़र यहां है?" का हर proxy कहीं न कहीं फेल होता है। माइक एनर्जी सुनने वालों के लिए फेल है। विंडो detection ब्राउज़र के लिए फेल है। पहचाने गए ट्रांसक्रिप्ट फेल हैं... अब तक हमें ऐसी कोई जगह नहीं मिली, क्योंकि वे proxy हैं ही नहीं — वे खुद प्रोडक्ट हैं।
2. जो कुछ भी renderer-driven है, उसके पास एक crash story होनी चाहिए। अगर एक मरी हुई UI प्रोसेस OS-स्तर की state पीछे छोड़ सकती है (mouse capture, always-on-top, content protection), तो reset की मालिक main प्रोसेस को होना चाहिए।
3. खुद अपना सबसे भारी यूज़र होना एक bug-finding रणनीति है। दोनों बग मुट्ठीभर से ज्यादा ग्राहकों की नजर में आने से पहले असली मीटिंग्स में हमसे टकराए। Observability के लिए महीनों पहले जोड़ा गया ended_reason कॉलम ही वह चीज थी जिसने डायग्नोसिस को अंदाजे की जगह एक डेटाबेस क्वेरी बना दिया।

दोनों फिक्स डायग्नोसिस से लेकर एक shipped, notarized रिलीज़ तक एक दिन के भीतर पहुंचे, हर एक regression tests वाले reviewed PR के सहारे। अगर आप GeekBye v2 पर हैं, तो auto-update के जरिए ये आपके पास v2.0.9 से ही हैं।

इस रिलीज़ की बाकी कहानी के लिए देखें सीरीज़ का पड़ोसी लेख AI ट्रांसक्रिप्शन तकनीकी शब्दों को गलत क्यों सुनता है (v2.0.11), विश्वसनीयता की नींव खराब Wi-Fi पर आपका AI notetaker क्यों रुक जाता है में, और यह कि overlay आपके क्लिक चुराए बिना screen sharing के दौरान अदृश्य कैसे रहता है।