ब्राउज़र स्रोत अपडेट के बाद एक डोनेशन दो अलर्ट क्यों ट्रिगर करता है
एक डोनेशन दो अलर्ट क्यों ट्रिगर करता है
ब्राउज़र स्रोत अपडेट के बाद पेज फिर से लोड होता है। स्क्रिप्ट दोबारा सर्वर से कनेक्ट होती है, इवेंट्स की सदस्यता लेती है और नोटिफिकेशन दिखाने के लिए हैंडलर बनाती है। अगर पुराना हैंडलर हटाया नहीं गया या एक साथ दो कनेक्शन काम कर रहे हैं, तो एक डोनेशन इवेंट को कई बार प्रोसेस किया जाता है।
अपडेट अपने आप में ज़रूरी नहीं कि गड़बड़ी का कारण हो। यह अक्सर सिर्फ़ कनेक्शन लॉजिक में मौजूद गलती को सामने लाता है। उदाहरण के लिए, इनिशियलाइज़ेशन फ़ंक्शन पेज लोड होने पर चल सकता है, फिर कनेक्शन बहाल होने पर और एक बार फिर सर्विस मैसेज मिलने के बाद। हर रन donation इवेंट की नई सदस्यता जोड़ता है।
नतीजे में सर्वर एक डोनेशन ऑब्जेक्ट भेजता है, लेकिन ब्राउज़र वही फ़ंक्शन दो बार कॉल करता है। कभी-कभी डुप्लिकेशन सर्वर साइड होता है: ऐप नए कनेक्शन को अलग प्राप्तकर्ता मानता है और इवेंट पुराने और नए दोनों सत्रों को भेजता है। इसलिए पहले यह तय करना ज़रूरी है कि दोहराव कहाँ हो रहा है: स्रोत में, हैंडलर में या दिखाने के चरण में।
दोहराव कहाँ हो रहा है, यह कैसे पता करें
एक सरल टेस्ट से शुरू करें। ब्राउज़र स्रोत का लिंक अलग विंडो या टैब में खोलें, पेज की सिर्फ़ एक कॉपी रखें और एक टेस्ट इवेंट भेजें। अगर अलर्ट एक बार दिखता है, तो कारण संभवतः सीन सेटिंग्स या स्रोत की कई कॉपियों से जुड़ा है। अगर अलग टैब में ही दोहराव हो रहा है, तो पेज के कोड और सदस्यता तंत्र की जाँच करें।
डोनेशन प्रोसेसिंग को कई चरणों में बाँटना उपयोगी है: इवेंट प्राप्त करना, इवेंट जाँचना, अलर्ट को कतार में डालना और रेंडर करना। लॉग या कंसोल में अस्थायी रूप से हर चरण पर एक मार्कर दिखाएँ। अगर प्राप्ति की एंट्री दो बार आती है, तो समस्या विज़ुअल लेयर से पहले है। अगर इवेंट एक बार मिला है लेकिन कतार में दो आइटम हैं, तो गलती हैंडलर में है। अगर कतार में एक आइटम है और स्क्रीन पर दो अलर्ट हैं, तो डिस्प्ले फ़ंक्शन और HTML कंटेनर की जाँच करें।
डायग्नोस्टिक्स के लिए, अगर डोनेशन डेटा में ID भेजी जाती है तो हर इवेंट के साथ उसकी ID जोड़ें। प्राप्त करते समय और दिखाने से पहले यह ID रिकॉर्ड करें। दो कॉल में एक ही ID यह दिखाती है कि एक इवेंट दोबारा प्रोसेस हुआ है। दो अलग ID दो डिलीवरी बताती हैं, जिन्हें अलग से जाँचना होगा।
सिर्फ़ टैब की संख्या न जाँचें। OBS में दो कॉपियाँ सीन कॉपी करने, नेस्टेड सीन जोड़ने या उसी पते के साथ ब्राउज़र स्रोत दोबारा जोड़ने के बाद दिख सकती हैं। कभी-कभी एक स्रोत अलग लेयर में रह जाता है और दूसरा उसके ऊपर जुड़ जाता है। देखने में यह डबल अलर्ट जैसा लगता है, जबकि इवेंट एक बार ही आया था।
रीकनेक्ट के बाद दोबारा सदस्यता लेना
सबसे आम कारण यह है कि हैंडलर हर कनेक्शन पर जोड़ा जाता है, लेकिन डिस्कनेक्ट पर हटाया नहीं जाता। सरल रूप में समस्या ऐसी दिखती है: फ़ंक्शन अलर्ट दिखाने वाले हैंडलर के साथ socket.on चलाता है, फिर कनेक्शन टूटता है, ऐप दोबारा कनेक्ट होता है और socket.on दोहराता है। इसके बाद एक आने वाला डोनेशन दो फ़ंक्शन कॉल करता है। अगले रीकनेक्ट पर इनकी संख्या और बढ़ सकती है।
यही गलती सामान्य addEventListener के साथ भी होती है। अगर इनिशियलाइज़ेशन फ़ंक्शन कई बार चलता है, तो ब्राउज़र एक ही इवेंट के लिए कई लिस्नर जोड़ देता है। “इनिशियलाइज़ेशन पहले ही हो चुका है” वाला फ़्लैग हमेशा मदद नहीं करता: पूरे पेज रीलोड पर वेरिएबल रीसेट हो जाते हैं, और उसी पेज के भीतर रीकनेक्ट पर समस्या बनी रहती है।
सदस्यता कनेक्शन के जीवनकाल में एक बार बननी चाहिए, और नई सदस्यता से पहले पुरानी सदस्यता स्पष्ट रूप से हटाई जानी चाहिए। इवेंट हैंडलर के लिए removeEventListener और वही फ़ंक्शन रेफ़रेंस इस्तेमाल करें जो कनेक्ट करते समय दिया गया था। सॉकेट वाली लाइब्रेरी के लिए आमतौर पर off, unsubscribe या इसी तरह का डिस्कनेक्ट तरीका चाहिए।
सॉकेट के लिए न्यूनतम स्कीम ऐसी हो सकती है: const onDonation = data => showAlert(data); socket.off('donation', onDonation); socket.on('donation', onDonation); function cleanup() { socket.off('donation', onDonation); window.removeEventListener('beforeunload', cleanup); socket.close(); } window.addEventListener('beforeunload', cleanup);
यहाँ खास लाइब्रेरी नहीं, बल्कि क्रियाओं का क्रम मायने रखता है। हैंडलर एक वेरिएबल में रखा जाता है, इसलिए उसे उसी रेफ़रेंस से हटाया जा सकता है। नई सदस्यता से पहले पुरानी हटाई जाती है, और पेज बंद होने या स्रोत रुकने पर cleanup चलता है। अगर हर रन पर नया सॉकेट बनता है, तो पहले पुराना बंद करें और उसके बाद ही नया बनाएँ। वरना दोनों कनेक्शन एक ही डेटा प्राप्त करते रह सकते हैं।
रीकनेक्ट के समय पुराना कनेक्शन भी बंद करें और जुड़े टाइमर साफ़ करें। वरना पुराना सॉकेट डेटा प्राप्त करता रह सकता है जबकि नया पहले से काम कर रहा हो। यह खासकर तब होता है जब कोड पिछला रद्द किए बिना रीकनेक्ट का नया टाइमर शुरू कर देता है।
OBS और ब्राउज़र स्रोत में क्या जाँचें
अगर अलग विंडो में अलर्ट एक बार दिखता है, तो सीन पर जाएँ। प्रीव्यू रोकें, अतिरिक्त लेयर अस्थायी रूप से हटाएँ और एक ब्राउज़र स्रोत रखें। फिर संबंधित सीन पर व्यवहार जाँचें। यह टेस्ट सभी सीन और फ़िल्टर एक साथ जाँचने से तेज़ है।
- एक ही पेज पते वाले दो स्रोत खोजें।
- सीन की कॉपियाँ और नेस्टेड सीन जाँचें, जहाँ वही ओवरले हो सकता है।
- सुनिश्चित करें कि अलर्ट एक साथ ब्राउज़र स्रोत और उसी पेज वाली किसी दूसरी लेयर से न दिखे।
- सेटिंग्स बदलने के बाद सिर्फ़ सीन स्विच न करें, स्रोत को पूरी तरह रीस्टार्ट करें।
कभी-कभी URL या पैरामीटर अपडेट होने के बाद OBS में ब्राउज़र स्रोत का पुराना टैब बना रहता है। स्रोत को बंद कर दोबारा जोड़ने से परिकल्पना जाँचने में मदद मिलती है, लेकिन यह कोड ठीक करने का विकल्प नहीं है। अगर हर अपडेट के बाद समस्या लौटती है, तो हैंडलर की दोबारा रजिस्ट्रेशन या दोहरा कनेक्शन खोजें।
डिस्कनेक्ट की देरी को भी ध्यान में रखें। अपडेट के समय पुराना सत्र तुरंत बंद नहीं हो सकता। अगर सर्वर कुछ सेकंड तक उसे सक्रिय मानता है, तो इस बीच आया इवेंट दोनों सत्रों में पहुँच सकता है। सर्वर का सामान्य लॉजिक निष्क्रिय कनेक्शन हटाना चाहिए और पेज बंद होने के बाद सदस्यता नहीं छोड़नी चाहिए।
एक ही इवेंट की दोबारा डिलीवरी से सुरक्षा
ब्राउज़र स्रोत के सही काम करने पर भी कभी-कभी एक इवेंट दोबारा डिलीवर हो सकता है। यह कनेक्शन बहाल होने, मैसेज दोबारा भेजे जाने या इवेंट प्राप्त होने और उसकी प्रोसेसिंग की पुष्टि के बीच गड़बड़ी होने पर संभव है। इसलिए अलर्ट हैंडलर को दोहराव के प्रति मजबूत होना चाहिए।
सबसे अच्छा तरीका है डोनेशन की यूनिक ID जाँचना। इवेंट को कतार में डालने से पहले उसकी ID को पहले से प्रोसेस किए गए इवेंट्स के सेट में सहेजें। अगर वह ID पहले मिल चुकी है, तो दोहराव छोड़ दें। सूची सीमित समय तक रखें ताकि वह बेवजह न बढ़ती रहे।
इसके लिए सिर्फ़ राशि, भेजने वाले का नाम या संदेश का टेक्स्ट इस्तेमाल न करें। दो अलग डोनेशन का डेटा एक जैसा हो सकता है। समय से जाँच भी भरोसेमंद नहीं है: कई अलग डोनेशन लगभग एक साथ आ सकते हैं। अगर ID नहीं है, तो फ़ील्ड्स और समय के संयोजन की अस्थायी रूप से तुलना कर सकते हैं, लेकिन यह बैकअप विकल्प है जिसमें दो इवेंट गलती से जोड़ने का जोखिम है।
डुप्लिकेट सुरक्षा अलर्ट दिखाने से पहले होनी चाहिए, एनिमेशन के भीतर नहीं। वरना दूसरी कॉल फिर भी पेज पर एलिमेंट जोड़ देगी, साउंड बजा देगी या कतार में एक और एंट्री डाल देगी। कतार को अलग से नियंत्रित करें: एक इवेंट उसमें एक ही बार जुड़ना चाहिए, और दोबारा कॉल से दूसरी स्वतंत्र कतार शुरू नहीं होनी चाहिए।
अगर इवेंट कई टैब या कंपोनेंट के बीच भेजा जाता है, तो जाँचें कि क्या उसे एक साथ कई प्राप्तकर्ता प्रोसेस नहीं कर रहे। एक साझा मैसेज चैनल कई हैंडलर से जुड़ा हो सकता है। ऐसे में या तो एक ही उपभोक्ता रखें, या स्पष्ट रूप से तय करें कि अलर्ट दिखाने के लिए कौन सा कंपोनेंट ज़िम्मेदार है।
कैश साफ़ करना हमेशा मदद क्यों नहीं करता
ब्राउज़र स्रोत अपडेट के बाद अक्सर कैश साफ़ करने की सलाह दी जाती है। यह तब स्थिति सुधार सकता है जब स्क्रिप्ट का पुराना वर्ज़न लोड हुआ हो, लेकिन कैश पहले से चल रहे पेज में अतिरिक्त हैंडलर नहीं हटाता और स्रोत की दूसरी कॉपी बंद नहीं करता। अगर हर रीकनेक्ट के बाद दोहराव लगातार हो रहा है, तो कारण लगभग निश्चित रूप से कनेक्शन लॉजिक या सीन की संरचना में है।
जाँचें कि क्या वाकई फ़ाइलों का नया वर्ज़न लोड हो रहा है। अस्थायी रूप से रिसोर्स का पता बदलें या दिए गए अपडेट तंत्र का उपयोग करें, फिर ब्राउज़र स्रोत रीस्टार्ट करें। इसके बाद एक विंडो और स्रोत की एक कॉपी के साथ फिर टेस्ट करें। लिंक में लगातार रैंडम पैरामीटर न जोड़ें: इससे कैश के कई वेरिएंट बन सकते हैं और डायग्नोस्टिक्स मुश्किल हो सकती है।
अगर बीच का कैश या service worker इस्तेमाल हो रहा है, तो वह भी पुरानी स्क्रिप्ट दे सकता है। ऐसे में लोड हुई फ़ाइल का वर्ज़न और अपेक्षित वर्ज़न की तुलना करें। लेकिन पुरानी फ़ाइल के साथ भी दोबारा सदस्यता का कारण दूर करना ज़रूरी है, वरना अगले अपडेट के बाद समस्या फिर आएगी।
अलर्ट कोड में क्या जाँचें
पहले वे सभी जगह खोजें जहाँ socket.on, addEventListener, कनेक्शन फ़ंक्शन और कतार शुरू करना कॉल होता है। कभी-कभी समस्या एक हैंडलर में नहीं, बल्कि यह होती है कि दो अलग मॉड्यूल स्वतंत्र रूप से donation इवेंट सुनते हैं और हर एक अपना डिस्प्ले शुरू करता है।
फिर कंपोनेंट का जीवनचक्र जाँचें, अगर अलर्ट किसी फ़्रेमवर्क से दिखता है। सदस्यता को इफ़ेक्ट या समान ब्लॉक में रखा जाता है और क्लीनअप फ़ंक्शन लौटाया जाता है। पिछला हटाए बिना हर स्टेट अपडेट पर नया हैंडलर नहीं बनाना चाहिए। सामान्य JavaScript में सक्रिय सॉकेट और मौजूदा हैंडलर का रेफ़रेंस रखना ज़रूरी है ताकि पेज रुकने पर उन्हें ठीक से बंद किया जा सके।
रीकनेक्ट के टाइमर जाँचें। नया टाइमर पुराने के ऊपर नहीं चलना चाहिए। वरना कई डिस्कनेक्ट के बाद समानांतर कनेक्शन प्रयास बनते हैं और उनके साथ अतिरिक्त सदस्यताएँ भी। हर टाइमर को clearTimeout या clearInterval से साफ़ करना चाहिए जब उसकी ज़रूरत न हो।
अलग से उस कोड को देखें जो अलर्ट दिखाता है। उसे एक साथ कतार में एलिमेंट जोड़कर उसी ऑब्जेक्ट के लिए डिस्प्ले फ़ंक्शन तुरंत कॉल नहीं करना चाहिए। यह भी जाँचें कि एलिमेंट की स्टेट बदलने पर एनिमेशन दोबारा शुरू न हो। अगर लॉग में एक प्राप्ति और कतार में एक एंट्री है, लेकिन स्क्रीन पर दो नोटिफिकेशन हैं, तो खोज यहीं करनी है।
डायग्नोस्टिक्स चेकलिस्ट: क्रम से क्या करें
- ब्राउज़र स्रोत का URL अलग टैब में खोलें और एक टेस्ट डोनेशन भेजें। दर्ज करें कि OBS के बाहर दोहराव दिखता है या नहीं।
- सीन में स्रोत की सिर्फ़ एक कॉपी रखें। सीन की कॉपियाँ, नेस्टेड सीन और वे लेयर जाँचें जहाँ वही पता हो सकता है।
- प्राप्ति, कतार में डालने और दिखाने के चरणों पर इवेंट ID के साथ लॉग जोड़ें। इससे दिखेगा कि ऑब्जेक्ट की संख्या कहाँ बढ़ रही है।
- socket.on और addEventListener के सभी कॉल खोजें। जाँचें कि पुराने हैंडलर socket.off और removeEventListener से उसी फ़ंक्शन रेफ़रेंस के साथ हट रहे हैं या नहीं।
- रीकनेक्ट जाँचें: पुराना सॉकेट बंद हो रहा है, पुराना टाइमर रद्द हो रहा है और पिछली सदस्यता के ऊपर नई सदस्यता नहीं बन रही।
- कतार से पहले डोनेशन की यूनिक ID की जाँच जोड़ें, फिर स्रोत पूरी तरह रीस्टार्ट करें और एक इवेंट के साथ टेस्ट दोहराएँ।
अगर अलग टैब में इवेंट एक बार मिलता है लेकिन OBS दो अलर्ट दिखाता है, तो स्रोत की दूसरी कॉपी या सीन में दोहराव खोजें। अगर इवेंट अलग टैब में ही दो बार आता है, तो सदस्यताएँ, कनेक्शन और सर्वर डिलीवरी जाँचें। अगर प्राप्ति और कतार एक बार दर्ज होते हैं लेकिन स्क्रीन पर दो नोटिफिकेशन हैं, तो समस्या विज़ुअल लेयर में है।
Last Articles
डिज़ाइन और कार्यक्षमता में क्या बदला हमने साइट को अपडेट किया है ताकि इसके साथ काम करना तेज़ और आसान हो। मुख्य बदलाव इंटरफ़ेस, व्यक्तिगत कैबिनेट और ऑर..
Good afternoon, I've collected all the news during this time.: 1. The main news is that prices for twitch viewers have been greatly reduced, while Tw..
1. हमारे सभी दर्शकों के लिए 15% छूट के लिए प्रोमो कोड "December2025" का उपयोग करें2. हमने 1 जनवरी तक अपने कॉन्फ़िगरेशन टूल और सबसे सस्ते दर्शक श्रेणी ..
चिकोटी सेवाएं हैं स्थिर रूप से काम करना, इसलिए हम दस्तों, पुनर्विक्रेताओं के साथ सहयोग करने के लिए तैयार हैं, सेवा मालिक, बॉट मालिक, और कई अन्य । ..
हम हमारी ट्विच व्यूअर सेवाओं को पूरी तरह से अपडेट कर दिया है, और वे अब हैं स्थिरतापूर्वक काम करना । हम केवल दर्शकों के लिए उच्च गुणवत्ता वाले आईप..
Hello everyone! Today, we are announcing a new feature—"Twitch Viewer Configurator". Now, you can customize any plan for your Twitch channel. Choo..
Greetings, I have compiled a guide for streamers, which will be very relevant at the moment. Now YouTube and twitch have disabled monetization from vi..
We have finally developed the APINow it will be more convenient for our partner sites to work with us.To update the maximum tariffs for YouTube, an up..
साझेदारी सेवाओं और रेफरल कार्यक्रम की भारी लोकप्रियता के कारण, हमने एक सहयोग तालिका बनाई है। सार बहुत सरल है: अधिक लाइव दर्शक - हमारी ओर से अधिक विज्ञ..
स्ट्रीमर्स के लिए हमारी सेवाएं
Shopee
Bigo
कंटेंट क्रिएटर्स के लिए हमारी सेवाएं
