Steven
Steven5 मिनट पढ़ें

स्क्रीन रिकॉर्डिंग गलत मॉनिटर क्यों कैप्चर करती है (और हमारा फिक्स)

दो मॉनिटर वाले सेटअप में, आप चाहे किसी भी स्क्रीन पर काम कर रहे हों, GeekBye हमेशा प्राइमरी डिस्प्ले ही रिकॉर्ड और स्क्रीनशॉट करता था। फिक्स एक छोटा सा फंक्शन था — पर उसका पहला वर्जन गलत था, और code review ने पकड़ा कि क्यों।

स्क्रीन रिकॉर्डिंग
मल्टी-डिस्प्ले
इंजीनियरिंग
GeekBye रिलीज़
स्क्रीन रिकॉर्डिंग गलत मॉनिटर क्यों कैप्चर करती है (और हमारा फिक्स)

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

वही खोट, ज्यादा चुपके से और ज्यादा बुरे रूप में, उन स्क्रीनशॉट्स पर भी लगी जो GeekBye कॉन्टेक्स्ट के तौर पर AI को भेजता है: अपने दूसरे मॉनिटर पर स्क्रीनशॉट शॉर्टकट दबाइए, और AI को पहले मॉनिटर की तस्वीर मिलती है। कोई दिखने वाला सुराग नहीं होता — असिस्टेंट बस गलत स्क्रीन के बारे में जवाब देता है, और आप सोचते रह जाते हैं कि यह इतना confuse क्यों है। GeekBye v2.0.10 ने दोनों ठीक कर दिए।

दो पाइपलाइन, एक आलसी डिफॉल्ट

डेस्कटॉप पर स्क्रीन कैप्चर दो अलग-अलग कोड पाथ हैं, और दोनों ने स्वतंत्र रूप से प्राइमरी डिस्प्ले ही चुन ली थी:

  • वीडियो रिकॉर्डिंग उपलब्ध screen sources को गिनती थी और पहला वाला ले लेती थी — sources[0]। macOS पर वह असल में हमेशा मुख्य डिस्प्ले ही होता है। कोई picker नहीं, इस बारे में कोई तर्क नहीं कि आप असल में कहां थे। हमारे अपने कोड में कमेंट सचमुच लिखा था "auto-select first screen source."
  • स्क्रीनशॉट macOS की screencapture कमांड को -m फ्लैग के साथ इस्तेमाल करते थे। उस फ्लैग का ठीक एक ही मतलब है: सिर्फ मुख्य डिस्प्ले। हार्डकोडेड।

किसी भी पाथ ने वह सवाल कभी नहीं पूछा जो असल में मायने रखता है: यूज़र किस स्क्रीन पर है?

एक चीज जो कभी नहीं टूटी, इसे साफ कर देना जरूरी है क्योंकि लोग मान लेते हैं कि टूटी है: एक ही मॉनिटर पर macOS Spaces के बीच स्विच करना हमेशा सही चला। कैप्चर display स्तर पर होता है — यह जो भी Space चुनी हुई डिस्प्ले पर दिख रहा हो, उसे पकड़ लेता है। यह बग कभी Spaces के बारे में था ही नहीं। यह हमेशा से गलत फिजिकल डिस्प्ले चुनने के बारे में था।

वह फिक्स जो साफ-सा लग रहा था — और गलत था

सही संकेत आसान लगता है: वह डिस्प्ले कैप्चर करो जिस पर यूज़र है। हमारे पहले implementation ने GeekBye की overlay विंडो को आधार बनाया — overlay जिस डिस्प्ले पर रहती है, उसी को कैप्चर करो।

Code review ने इसे मार गिराया, और सही किया। GeekBye की overlay प्राइमरी डिस्प्ले पर, स्थिति (0,0) पर, पूरे work-area को घेरने वाली विंडो के रूप में बनाई जाती है। यह किसी दूसरे मॉनिटर पर तभी जाती है जब आप उसकी pill को खुद खींचकर वहां ले जाएं — और जो keyboard shortcuts उसे इधर-उधर सरकाते हैं, वे प्राइमरी डिस्प्ले के आयामों तक clamp हो जाते हैं, इसलिए वे इसे दूसरे मॉनिटर पर बिलकुल नहीं ले जा सकते। कैप्चर को overlay पर आधारित करने का मतलब था: हर उस यूज़र के लिए जिसने संयोगवश overlay को अपनी काम वाली स्क्रीन पर नहीं खींचा, यह "फिक्स" सीधे वापस प्राइमरी डिस्प्ले पर आ जाता। इससे लगभग किसी का भी ठीक नहीं होता — जबकि सिंगल-मॉनिटर dev मशीन पर एक झटपट टेस्ट में यह चलता हुआ दिखता।

सही आधार है कर्सर। आपका माउस जहां है, वही वह डिस्प्ले है जिस पर आप काम कर रहे हैं — और यह हर उस तरीके के लिए सही है जिससे कोई कैप्चर शुरू होता है: keyboard shortcut वहीं चलता है जहां आप इशारा कर रहे हैं, और Record बटन पर क्लिक करने से आपका कर्सर परिभाषा के अनुसार उसी डिस्प्ले पर होता है। आखिरी फिक्स एक दो-लाइन का फंक्शन है: कर्सर के सबसे नजदीक वाली डिस्प्ले। वीडियो अपने capture source को उस डिस्प्ले के id से मिलाता है; स्क्रीनशॉट -m मुख्य-डिस्प्ले फ्लैग के बजाय उस डिस्प्ले के bounds को screencapture -R (एक विशिष्ट आयत) को पास करते हैं।

हमने जानबूझकर -R (ग्लोबल स्क्रीन निर्देशांकों में एक स्पष्ट आयत) को -D (एक डिस्प्ले इंडेक्स) के मुकाबले चुना: OS का display index framework की display क्रम से मेल खाएगा, इसकी कोई गारंटी नहीं, इसलिए index फिर से एक अटकल का खेल बन जाता। असल display bounds से बना आयत किसी भ्रम में नहीं छोड़ता — और शिप करने से पहले हमने इस फ्लैग का व्यवहार, प्राइमरी के बाईं ओर रखी डिस्प्ले के लिए ऋणात्मक निर्देशांकों समेत, एक असली मल्टी-मॉनिटर सेटअप पर verify किया।

यह एक अच्छा सिखाने वाला बग क्यों है

  1. "स्क्रीन कैप्चर करो" के भीतर एक फैसला छिपा है। सिंगल डिस्प्ले पर कोई फैसला होता ही नहीं, इसलिए वह फैसला कभी डिजाइन नहीं होता — वह डिफॉल्ट कर दिया जाता है। मल्टी-मॉनिटर वही जगह है जहां हर छिपा हुआ डिफॉल्ट सतह पर आता है।
  2. चुपके से गलत होना, दिखते हुए गलत होने से बदतर है। वीडियो वाले बग ने लोगों को खीझाया। स्क्रीनशॉट वाले बग ने AI को, अदृश्य रूप से, गुमराह किया। जब आप ऐसे फीचर बनाते हैं जो किसी मॉडल को कॉन्टेक्स्ट देते हैं, तो एक गलत इनपुट पूरे विश्वास के साथ एक गलत आउटपुट पैदा करता है, और कहीं कोई error नहीं आता। वही वे नाकामियां हैं जिन्हें सबसे जी-जान से ढूंढना चाहिए।
  3. जो फिक्स आपकी मशीन पर पास होता है, वह बाकी सबकी मशीन पर फेल हो सकता है। overlay-आधारित वर्जन सिंगल-मॉनिटर टेस्ट में चला। इस बग का पूरा मुद्दा ही कई मॉनिटर हैं — और reviewer ने हरे टेस्ट पर भरोसा करने के बजाय विंडो की असली स्थिति के बारे में तर्क किया। Review चलते हुए कोड पर लगी रबर स्टैंप नहीं है; यह इस बात का दूसरा मॉडल है कि कोड क्यों चलता है।

GeekBye v2.0.10 रिकॉर्डिंग और स्क्रीनशॉट, दोनों के लिए कर्सर-आधारित फिक्स शिप करता है। अगर आप कई डिस्प्ले चलाते हैं, तो कैप्चर अब आपके साथ चलता है।

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

संबंधित लेख

जब फ़ायरवॉल WebSocket को ब्लॉक कर दे, तब लाइव ट्रांसक्रिप्शन का क्या होता है
Steven
Steven6 मिनट पढ़ें

जब फ़ायरवॉल WebSocket को ब्लॉक कर दे, तब लाइव ट्रांसक्रिप्शन का क्या होता है

कॉर्पोरेट नेटवर्क HTTPS को तो जाने देना पसंद करते हैं, पर WebSocket upgrade को चुपचाप मार डालते हैं। इससे रियल-टाइम ट्रांसक्रिप्शन खामोशी से टूट जाती है। GeekBye v2.0.8 अपने आप एक प्योर-HTTPS ट्रांसपोर्ट पर fall back करता है — और इसे बनाते हुए एक ऐसा बग निकला जो पूरे फीचर को बेकार बना देता।

ट्रांसक्रिप्शन
नेटवर्किंग
इंजीनियरिंग
जिस दिन हमारे ऐप ने खुद पर ही DDoS कर दिया
Steven
Steven6 मिनट पढ़ें

जिस दिन हमारे ऐप ने खुद पर ही DDoS कर दिया

लंबित अपलोड का एक ढेर, जो स्टार्टअप पर एक साथ छोड़ दिया गया, हर GeekBye क्लाइंट को हमारे अपने सर्वरों पर एक छोटे से डिनायल-ऑफ-सर्विस हमले में बदल गया। वह फिक्स — और जो connection-liveness सीढ़ी उसने हमसे बनवाई — v2 ने हमें जो सबसे उपयोगी चीज़ें सिखाईं, उनमें से एक है।

विश्वसनीयता
नेटवर्किंग
इंजीनियरिंग
एक असली वर्शन 2 में सचमुच क्या लगता है: ईमानदार स्थितियों के 206 कमिट
Steven
Steven8 मिनट पढ़ें

एक असली वर्शन 2 में सचमुच क्या लगता है: ईमानदार स्थितियों के 206 कमिट

GeekBye v2 कोई फ़ीचर रिलीज़ नहीं था। यह एक ही विचार पर निशाना साधे 206 कमिट थे: ऐप को अपनी ही स्थिति के बारे में कभी झूठ नहीं बोलना चाहिए। इसकी कीमत क्या है, वह यहाँ है — उस एक-लाइन लॉकफ़ाइल की गलती समेत जिसने हमें कुछ भी शिप करने से लगभग रोक दिया था।

विश्वसनीयता
इंजीनियरिंग
रिलीज़