हम एक बड़े नेटवर्क में एक छोटे रेडियो स्टेशन का निर्माण कैसे करते हैं

यह आलेख वर्णन नहीं करेगा कि आप विभिन्न कार्यों के लिए विभिन्न लिनक्स सिस्टम में आईसीकास्ट को कैसे कॉन्फ़िगर कर सकते हैं। नहीं। इस लेख में, मैं प्रसारण रेडियो स्टेशन को वैश्विक नेटवर्क पर लाने के लिए एक छोटी परियोजना के छोटे इतिहास को उजागर करना चाहूंगा। किन समस्याओं का सामना करना पड़ा और हमने उन्हें कैसे हल किया।

So. थोड़ा प्रागितिहास - हमारी मातृभूमि मास्को की राजधानी में अपने प्रधान कार्यालय के साथ कई प्रसारण संगीत रेडियो स्टेशनों की एक रेडियो होल्डिंग है। रेडियो स्टेशन खुद राजधानी के एफएम बैंड में प्रसारित होते हैं, उनके अपने दर्शक होते हैं और वे अपने श्रोताओं से काफी खुश होते हैं। लेकिन बदकिस्मती - 2012 के आंगन में, और इंटरनेट प्रसारण की दिशा इतनी अस्थिर और इतनी नहीं विकसित हो रही है। फिर एक मुख्य के ढांचे के भीतर कई शब्द और छोटी कहानियां होंगी, यदि दिलचस्पी है, तो बिल्ली का स्वागत करें।

समस्या का बयान लंबे समय से अधिक है, दोनों पूरे होल्डिंग के सामान्य निदेशक के लिए और खुद रेडियो स्टेशनों के कई कार्यक्रम निदेशकों के लिए। लेकिन एक छोटी सी समस्या थी - किसी भी तरह से होल्डिंग ने इस सेवा को मुद्रीकृत करने के तरीके नहीं देखे, और चूंकि विमुद्रीकरण नहीं है, इसलिए एक पागल समाधान बनाने के लिए कोई बजट नहीं हैं। कार्य अतिदेय क्यों है - उस समय (वसंत 2012) मौजूदा सेवा विश्वसनीयता, गुणवत्ता और सुविधा के लिए किसी भी आवश्यकताओं को पूरा नहीं करती थी। बस 2012 के वसंत में, होल्डिंग ने तकनीकी विभाग और आईटी सेवा के नेतृत्व को बदल दिया। मेरे भाग्य और मेरे सहयोगियों ने इस कंपनी की आईटी सेवा को प्रबंधित करने का अवसर दिया।
So.

प्रारंभिक स्थिति

कंपनी में इंटरनेट प्रसारण सर्वर के एक छोटे से सेट द्वारा प्रदान किया गया था:

• 1 वितरण सर्वर (FreeBSD, doped icecast, thanscoder, 3 Gbit e ईथरनेट, M IX Butlerova)
• मास्को में एक स्टूडियो कॉम्प्लेक्स (उर्फ हेड ऑफिस) में स्थापित 2 एन्कोडिंग सर्वर और एमपी 3 स्ट्रीम में एनालॉग / एईएस स्रोतों को मुख्य वितरण सर्वर (विंडोज एक्सपी, आईसीकास्ट, एडकास्ट) में एन्कोडिंग करते हैं।

इसके अलावा, एमपी 3 सिग्नल को सीधे नहीं भेजा गया था - प्रत्येक रेडियो स्टेशनों के लिए, और उनमें से 5 थे, 256 kbit / s की एक धारा बनाई गई थी और एन्कोडिंग के स्थानीय icecast सर्वर पर प्रकाशित किया गया था, जिसके बाद NAT के माध्यम से मुख्य वितरण सर्वर ने स्वतंत्र रूप से इन धाराओं को स्थानांतरित कर दिया और उन्हें ट्रांसकोड किया अतिरिक्त में (64, 96, 128, 320)। यह सर्वर की तरफ था, क्लाइंट की तरफ सब कुछ और भी बदतर था - कोई फ्लैश / एचटीएमएल क्लाइंट सिद्धांत रूप में मौजूद नहीं था, रेडियो स्टेशनों की वेबसाइट पर एक छोटी सी एफएक्यू पोस्ट की गई थी, कैसे धाराओं से कनेक्ट किया जाए और ग्राहकों के सभी "चाट" समाप्त हो गए। यह जोड़ना आवश्यक है कि इस डिजाइन ने बिल्कुल भी काम नहीं किया, और लगभग हर दिन हमने 3-3.5 हजार श्रोताओं तक पहुंचने के दौरान होल्डिंग के मुख्य रेडियो स्टेशन की धाराओं के "टूटने" को देखा, एक नियम के रूप में, "ब्रेकडाउन" दिन के दौरान कई बार हुआ। विफलताओं के कारण अलग-अलग थे, फिर ट्रांसकोडर उठेगा, फिर किसी कारण से सर्वर यह तय करेगा कि यह दूरस्थ माउंट बिंदु, या कुछ और नहीं देखता है। संक्षेप में, यह स्पष्ट रूप से कुछ करना था।
मेरे तार्किक प्रश्न के लिए, इस पूरी अर्थव्यवस्था के लिए सहायता प्रदान करने वाले इंजीनियरों को संबोधित - यह इतना "तार्किक" क्यों नहीं है कि सब कुछ बनाया गया है? सामान्य उत्तर का पालन किया गया - ठीक है, इसलिए यह ऐतिहासिक रूप से हुआ। यह ध्यान दिया जाना चाहिए कि नोवोसिबिर्स्क के बाहरी आउटसोर्सिंग कर्मचारी icecast "परिष्करण" में लगे हुए थे। वह एक महान व्यक्ति है, वह फ्रीबीएसडी को दूर-दूर तक जानता है, सी या सी ++ में लिखता है, लेकिन उसे मल्टीमीडिया में बहुत समझ नहीं है, लेकिन वह निश्चित रूप से नहीं जानता कि नेटवर्क पर बड़े प्रसारण प्लेटफार्मों का निर्माण कैसे किया जाता है। और उसे इसकी आवश्यकता नहीं है, वह इसके लिए पैसे नहीं देता है। इसके अलावा, समय का अंतर, संक्षेप में, मोड़ उस समय पारित किया गया जब जनरल ने तकनीकी विभाग के प्रमुख के साथ हमारे कार्यालय में प्रवेश किया और कहा - दोस्तों, मेरे नेटवर्क पर कुछ iPhone के साथ नहीं खेलता है, चलो पहले से ही कुछ करते हैं । उसे जवाब देने के लिए कुछ भी नहीं था - ठीक है, वह वास्तव में नहीं खेलता है, क्योंकि फिर से, वहाँ कुछ गिर गया, आदि।

पहले आपको सोचने की जरूरत है

कोई भी व्यवस्थापक आपको आईकॉस्ट की दृष्टि से बताएगा कि क्या सोचना है, यहां यह "फ़ाइल" करना आवश्यक है। लेकिन यह हमारा मामला नहीं है। हम इतने "ऐतिहासिक" रूप से चिंतित हैं कि इन अस्तबलों को कुछ सामान्य स्तर पर लाने की आवश्यकता है। उस समय मौजूद मुख्य समस्याएं:

• अतिरेक का निम्न स्तर - वास्तव में, एक भी सिस्टम घटक अनावश्यक नहीं था
• कम से कम कुछ प्रकार के लोड संतुलन की एक प्रणाली की कमी - सभी एक सर्वर पर प्रवाहित होती है, सभी क्लाइंट एक सर्वर पर। और फिर हम देखेंगे कि वह उन्हें रखता है या नहीं।
• बड़ी संख्या में अनजानी असफलताएँ
• डायग्नॉस्टिक्स को आईकॉस्ट और फ्रीबीएसडी कोर कस्टमाइज़ेशन + आउटडेटेड प्रोडक्ट (कुछ झबरा वर्जन का फ्रीबीएसडी) + इस उत्पाद के साथ समस्याओं के कारण टीसीपी / आईपी स्टैक के "सही ढंग से" कार्यान्वित नहीं किए गए, जो क्रॉल से बाहर निकलते हैं, मुश्किल हैं। बहुत सारे सत्रों के साथ भार
• एफएम सिग्नल प्रोसेसिंग की पूरी कमी - यह एक रेडियो वातावरण में बहुत अव्यवसायिक माना जाता है, अगर आपको पीएम या टिप्पणियों में स्पष्टीकरण की आवश्यकता है
• रेडियो स्टेशनों की वेबसाइट पर सीधे खेलने के लिए फ्लैश / html क्लाइंट की कमी है
• निगरानी प्रणाली की कमी

संक्षेप में, जहां यह है, वहां खुदाई करें, अब यह सब किसी प्रकार के तर्कसंगत दृष्टिकोण को कैसे आगे बढ़ा सकता है।

सोचना बंद करो - यह "गश" करने का समय है

समाधान एक प्रणालीगत था - किसी भी आईटी प्रबंधक के दिमाग में क्या आता है जब उसका सामना एक विशेष कार्य से होता है - ठीक है, लेकिन चलो इसे पैसे के लिए आउटसोर्स करते हैं। कुछ प्रबंधक जो विशेष रूप से हाथ में साफ नहीं होते हैं, वे आउटसोर्सिंग की लागत में अपनी रुचि डालने का प्रबंधन करते हैं, लेकिन हम इसके बारे में बात नहीं कर रहे हैं। मेरे बॉस और मैंने एक ही बार में दोनों निर्णय लिए, अर्थात् या हम इसे स्वयं करते हैं और कैसे, या हम इसे आउटसोर्स करते हैं, तो सवाल उठता है - इसकी लागत कितनी होगी? इसलिए, आउटसोर्सिंग का प्रश्न अपने आप गिर गया, जैसे ही हमने गणना की कि नेटवर्क को तीसरे पक्ष को प्रसारण देने में कितना खर्च आएगा और इस कार्य को हमेशा के लिए भूल जाएगा। ऐसी कंपनियां जो अपनी सेवाओं को सार्वजनिक रूप से अपनी सेवाओं के लिए ऐसी कीमतें प्रदान करती हैं कि रेडियो बाजार में बड़े खिलाड़ी उनके पास कभी नहीं आएंगे, यह एक तथ्य है। मॉस्को में शीर्ष दस में भी सबसे बड़े रेडियो स्टेशनों की लाभप्रदता निश्चित रूप से इन शर्तों के तहत उन्हें आत्मसमर्पण करने की अनुमति देगी, लेकिन यह अभी भी एक महत्वपूर्ण व्यय आइटम होगा, और यह सामान्य मुद्रीकरण की अनुपस्थिति में है। ऐसी सेवाएं हैं जो विभिन्न प्रकार के विज्ञापन रखने के रूप में प्रसारण और मुद्रीकरण दोनों प्रदान करती हैं, लेकिन सेवाओं के लिए उनकी कीमतें काफी अधिक हैं, और निवेश पर वापसी का मुद्दा बहुत तीव्र है, इसलिए इसे NO कहा गया था। हम इसके लिए नहीं जा सकते हैं, खासकर जब से हमने सबसे किफायती तरीकों से परिचालन खर्च को कम करने के लिए हमें काम पर रखा है, और यहां सब कुछ बिल्कुल विपरीत होगा। संक्षेप में, हमने इस विचार को छोड़ दिया।
इसे स्वयं बनाएं - कैसे?

• अतिरेक - icecast-kh के स्तर पर अंतर्निहित संतुलन तंत्र के साथ वितरण सर्वरों की संख्या 4 तक बढ़ाएं। हम वर्चुअलाइजेशन प्लेटफ़ॉर्म पर एन्कोडिंग सॉफ़्टवेयर निकालते हैं। हम एन्कोडर्स से पहले वितरण स्तर के आईकॉस्ट को निकालते हैं और इसे एक अलग वर्चुअल मशीन पर डालते हैं। हम केंद्रीय कार्यालय में इंटरनेट चैनलों को आरक्षित करते हैं
• संतुलन - icecast-kh के साथ बढ़ते बिंदुओं के भरने के आधार पर लोड को संतुलित करना
• यह ओम्निया एक्स / ई को एन्कोडिंग सॉफ्टवेयर के रूप में उपयोग करने का प्रस्ताव है, यह आपको एन्कोडिंग और एफएम ऑडियो प्रसंस्करण की आवश्यकता दोनों को बंद करने की अनुमति देता है
• मुख्य वितरण सर्वर पर ट्रांसकोडिंग की पूरी अस्वीकृति, सर्वर को पूरी तरह से तैयार स्ट्रीम प्राप्त करना चाहिए और केवल इसे वितरित करना चाहिए
• सर्वरों पर FreeBSD की पूर्ण अस्वीकृति और किसी प्रकार के लिनक्स में संक्रमण (अंत में, उन्होंने Ubuntu 12.04 LTS को चुना)
• पड़ोसी विभाग द्वारा लेखन साइट पर खेलने के लिए एक पूर्ण फ्लैश / एचटीएमएल क्लाइंट, आईओएस + एंड्रायड मोबाइल प्लेटफॉर्म के लिए क्लाइंट विकसित करना
• न केवल एमपी 3 के साथ ग्राहकों को प्रदान करना, बल्कि मोबाइल ऑपरेटरों के नेटवर्क पर सुनने के लिए AACv2 + स्ट्रीम भी
• इवेंट द्वारा फ़ाइलों को बदलने की क्षमता के साथ एक सक्रिय निगरानी प्रणाली की स्थापना

ऐसा क्यों?
मेरी राय में, बड़ी संख्या में धाराओं को ले जाने वाले icecasts के सामने किसी भी लोड बैलेंसर्स को रखने का प्रयास, बिल्कुल अर्थहीन है। यदि आपके सर्वर में एक गीगाबिट संचार चैनल है, जिसमें अपेक्षाकृत कमजोर प्रोसेसर और थोड़ी मात्रा में रैम है, तो आइसकास्ट इसे पूरी तरह से ब्लॉक कर देगा, बस क्लाइंट को खींच लेंगे। तो आप क्या संतुलन करेंगे? कई गिगाबिट स्ट्रीम, और विफलता के एक बिंदु के साथ क्या करना है? क्या एक रास्ता है - हम स्विच का उपयोग करके केवल नेटवर्क स्तर पर संतुलन रखते हैं, अगर आपके पास पोर्ट चैनल है। तीन गीगाबिट चैनल के साथ, आप 2.7 गीगाबिट्स प्रति सेकंड, सभी 4 के लिए चार चैनलों के साथ, और इसी तरह से गिन सकते हैं। सर्वरों के बीच लोड वितरण, ताकि माउंट पॉइंट्स को अधिभारित न किया जाए, आईसीकास्ट खुद इसे लागू कर सकता है, इसका केएच संस्करण। व्यवहार में, यह पता चला कि icecast 128 kbit / s MP3 के एक माउंट पॉइंट पर 3200-3500 से अधिक नहीं रखता है - कारण, जैसा कि हम समझते हैं, यह प्रोसेसर कोर पर उच्च भार है। तथ्य यह है कि icecast, डिफ़ॉल्ट रूप से, एक कोर पर एक माउंट बिंदु को संसाधित करता है। यदि सिस्टम में कोर की संख्या से अधिक माउंट पॉइंट हैं, तो यह कोर द्वारा उन्हें अलग करना शुरू कर देता है, लेकिन फिर से, समान रूप से नहीं, बल्कि एक कोर पर माउंट पॉइंट द्वारा। यदि आपके प्रोसेसर बहुत तेज़ नहीं हैं, तो आपको एक माउंट बिंदु पर 3,000 से अधिक एक साथ माउंट नहीं लोड करना चाहिए, आप उन्हें एक ही सर्वर पर एक छिपे हुए माउंट बिंदु पर स्थानांतरित करने के लिए चाल का उपयोग कर सकते हैं, लेकिन एक अलग नाम के साथ। नियमित रूप से icecast में, यह "विकृत" तर्क ठीक काम करता है। केएच संस्करण के लिए आवश्यक है कि एक और आरोह बिंदु का एक अलग स्रोत हो।
दूसरे, मेरा मानना ​​है कि प्रसारण कार्यों के लिए एक राक्षसी सर्वर बनाने का मतलब है कि मंच के क्षैतिज विकास की संभावना को पूरी तरह से ध्यान में नहीं रखना, जो कि पूरी तरह से सच नहीं है, भविष्य में यह अभी भी और कैसे आता है। इसलिए, क्षैतिज स्केलिंग के साथ विकल्प चुना गया था।
वे स्वामित्व सॉफ्टवेयर के साथ कोड क्यों करना चाहते थे - वे एफएम प्रसंस्करण और एन्कोडिंग के अलग-अलग घटकों के रूप में बगीचे को बाड़ना नहीं चाहते थे, और इस समस्या को हल करने के लिए AXIA लाइववायर का परिचय बहुत "स्वादिष्ट" था। एक और प्लस यह था कि कई एन्कोडर का परीक्षण करने के बाद, यह स्पष्ट हो गया कि AXIA संपीड़न गुणवत्ता के मामले में मुक्त लोगों से अलग है, अर्थात लंगड़ा आदि की तुलना में। वह बेहतर लगती है। मैं लंबे समय तक, बाद में या टिप्पणियों में "क्यों?" की व्याख्या नहीं करना चाहता।

हम "रील" शुरू करते हैं

उन्होंने तुरंत क्या सामना किया - यह स्पष्ट हो गया कि श्रोताओं की संख्या, इसके अलावा, उन लोगों को मापना आवश्यक था, जो एक साथ थे और एक दिन, दिन, सप्ताह, आदि के दौरान जमा हुए थे। स्पष्टीकरण की प्रक्रिया में, यह स्पष्ट हो गया कि इस तरह के प्रवाह को छोड़ने के लिए और उनमें से कई बेहद "मोटी" (उदाहरण के लिए 320) हैं, हम बस नहीं कर सकते। यह पहला गंभीर ठोकर था, और अतीत में इस कार्य के कार्यान्वयन के लिए जिम्मेदार सामान्य इंजीनियरों की तुलना में कार्यक्रम के निदेशकों और अन्य टॉपर्स को समझाना बहुत आसान था। मन की "ऑडीओफाइल" स्थिति ने उद्देश्य वास्तविकता को समझने से इनकार कर दिया। हमने इसे धोने से नहीं किया था, इसलिए इसमें बहुत सारे रक्त खर्च हुए और बहुत सारे भावनात्मक घाव छोड़ दिए। लेकिन भगवान का शुक्र है कि किसी को अधीनस्थों के साथ निकाल दिया गया या खराब कर दिया गया। हमने सब कुछ क्रम में रखना शुरू कर दिया। हम 5 रेडियो स्टेशनों में से प्रत्येक के लिए निम्नलिखित मानक धाराओं में आए - 128 और 64 kbit / s MP3, 56 & 48 kbit / s AACv2 +।
लंबे समय तक वे मुख्य वितरण सर्वर को नहीं छूते थे, उन्होंने आंतरिक बुनियादी ढांचे को सीमित कर दिया। अंत में, 2013 के वसंत में एक दिन, मैंने और मेरे अधीनस्थ ने सुबह एम आईएक्स पर डार्ट किया और आगे बढ़ने के साथ सब कुछ और सब कुछ के पतन का मंचन किया। यह बहुत अच्छी तरह से निकला। Icecast-kh के साथ संयोजन के रूप में लिनक्स को शुरू करने के फायदे तुरंत स्पष्ट हो गए - यह वास्तव में उसी लोड के तहत कमजोर प्रोसेसर को लोड करना शुरू कर दिया। अंतर 20% तक था। यह बहुत कुछ है। साथ ही, उन्होंने तुरंत लोड को 4 सर्वरों में फैला दिया और दिन के दौरान उन्हें एक एकल डीएनएस रिकॉर्ड से जोड़ना शुरू किया।
सामान्य खिलाड़ी प्राप्त करने के साथ विकास विभाग की कठिनाइयों के कारण, हमने DNS में राउंड एंड रॉबिन तंत्र के साथ लोड संतुलन को पूरक करने का निर्णय लिया। वह निश्चित रूप से सबसे विश्वसनीय नहीं है, लेकिन अभी तक इसके बारे में नहीं है।

मैं सिगरेट चूतड़ के पहाड़ों को छोड़ रहा हूं ... सारांश

नवंबर 2013 में, इस शानदार कंपनी में मेरा काम समाप्त हो गया। इस कार्य के हिस्से के रूप में मुझे क्या गर्व हो सकता है और क्या नहीं।
4 सर्वरों का कुल कृषि प्रवाह दिन के दौरान 2.5 Gbit / s से अधिक हो गया और महीने से महीने में धीरे-धीरे बढ़ता रहा। किए गए सभी आंदोलनों से पहले, वह 1.2-1.3 से अधिक नहीं था। वास्तव में, कंपनी ने उन सभी की सेवा नहीं की जो एक सेवा प्राप्त करना चाहते थे, लेकिन केवल वे जो पहले समय में थे।
प्रारंभिक आंकड़ों के अनुसार, हम "ब्रेक थ्रू" करने में सक्षम थे, जो प्रति सप्ताह डेढ़ लाख यूनिक का संकेतक था, ये आंकड़े पहले से ही किसी तरह बेचे जा सकते हैं। इंट्रो फाइलों को रखने का तंत्र जो प्रत्येक जुड़े हुए उपयोगकर्ता के लिए एक व्यावसायिक भूमिका निभाता है, जबकि बिना ट्रैकिंग के जो पहले से ही खो गया था और जो नहीं किया था, लेकिन यह पहला प्लेसमेंट अनुभव था।
लोड सर्वरों पर समान रूप से फैलने लगा और इससे सेवा की गुणवत्ता प्रभावित हुई। रुकावट केवल वास्तविक नेटवर्क विफलताओं और अन्य समस्याओं के परिणामस्वरूप उत्पन्न हुई, लेकिन अब स्वयं सेवाओं या अन्य समस्याओं के गलत कॉन्फ़िगरेशन के कारण नहीं थे।
कम बिटरेट के साथ उच्च गुणवत्ता वाली धाराओं के उद्भव के कारण, मोबाइल प्लेटफ़ॉर्म से उनकी वृद्धि की ओर ग्राहकों की संख्या में बदलाव शुरू हो गया है। यह मुझे एक इंजीनियर के रूप में प्रसन्न करता है - आखिरकार, यह अनिवार्य रूप से एक पूरे के रूप में रेडियो स्टेशनों के लिए भविष्य का वितरण मॉडल है।
आंतरिक icecasts को गोली मार दी गई थी और सभी वितरण सर्वरों को वितरण के लिए एक एकल आंतरिक icecast बनाया गया था + इसे कुछ क्षेत्रीय भागीदारों द्वारा बैकअप सिग्नल स्रोत के रूप में भी उपयोग किया गया था। इसने हमें एक या दो से अधिक बार बचाया, और क्षेत्रीय विशेषज्ञों ने रिजर्व की विश्वसनीय सेवा के लिए धन्यवाद कहा।

मुझे किस बात पर गर्व नहीं हो सकता
Omnia AX / E में पूर्ण परिवर्तन लाने की योजना अधूरी रह गई - उन्होंने पूरी तरह से वित्तपोषण से इनकार कर दिया। नतीजतन, हमें एक बगीचे में बाड़ लगाने के लिए मजबूर किया गया था, जो कि एफएम के रूप में एक गोदाम में पाया जाता है, जिसे एमएमएम के रूप में प्राचीन माना जाता है। निगरानी की समस्या बनी रही - वित्त से इनकार, हमने PRTG को लागू करने का फैसला किया, बस नागोइस और अधिक पर कोई मानव संसाधन नहीं थे, इस कार्य ने किसी भी सर्वर की विफलता का तुरंत जवाब देना और बड़ी संख्या में ग्राहकों को कई मिनट के मौन से रोकना असंभव बना दिया। सर्वरों को वितरित करने की लॉग फ़ाइलों की एनालिटिक्स की एक सामान्य प्रणाली को लागू करना संभव नहीं था - एक सामान्य प्रणाली को सामान्य मापदंडों के अलावा, विशुद्ध रूप से मीडिया डेटा, AQH और अन्य की तरह, गणना करने में सक्षम माना जाता है। एकमात्र प्रणाली जो मुझे पता है कि कॉस्टरस्टैट है, अन्य सभी मुख्य रूप से वेब सर्वरों को संसाधित करने के लिए डिज़ाइन किए गए हैं और काफी फिट नहीं हैं। अधिकांश मोबाइल प्लेटफार्मों के लिए पूर्ण-विकसित खिलाड़ी पूरी तरह से विकसित नहीं थे, वे केवल आईओएस के तहत खत्म करने में सक्षम थे, लेकिन कम से कम इसलिए, खासकर जब से कार्य हमारे साथ नहीं था।
मुझे नहीं पता है कि पूरा होने की डिग्री का मूल्यांकन कैसे किया जाए, लेकिन हम खिलाड़ी तंत्र के आधार पर एक पूर्ण-संतुलन संतुलन प्रणाली शुरू करने में सफल नहीं हुए, क्योंकि मुख्य रूप से खिलाड़ी के विकास के लिए जिम्मेदार विभाग की समस्याओं के कारण। लेकिन इससे कोई फर्क नहीं पड़ता, हमारे पास उन्हें दोष देने के लिए कुछ भी नहीं है और कुछ भी नहीं।
आपको यह समझने की आवश्यकता है कि इस कंपनी में मेरे काम के दौरान तकनीकी विभाग और आईटी सेवा द्वारा हल किए गए एकमात्र कार्य से यह दूर है, इसलिए ऐसी अवधि में आश्चर्यचकित न हों। यह ऐसा है जैसे मैं बहाना बना रहा हूं।

यदि कोई मल्टीमीडिया क्षेत्र में आईटी के विषय में रुचि रखता है, तो मैं कुछ अन्य विषयों पर कहानियां जारी रख सकता हूं, क्योंकि अनुभव है।