डाउनलोडिंग

डाउनलोड मैनेजर वह क्या करता है जो वेब ब्राउज़र नहीं करेगा

चार गीगाबाइट की फ़ाइल, नब्बे प्रतिशत पूरी, और फिर एक फ़ोन कॉल — या बस एक लॉक्ड स्क्रीन — और यह ग़ायब है। यह iOS पर डाउनलोडिंग को लेकर सबसे आम शिकायत है, और यह कोई बग नहीं है। यह ऑपरेटिंग सिस्टम ठीक वही कर रहा है जिसके लिए इसे डिज़ाइन किया गया, और यही वजह है कि ऐप की एक अलग क़िस्म मौजूद है।

8 मिनट पढ़ें अपडेट 29 जुलाई 2026

30s iOS के इसे रोकने से पहले एक सस्पेंडेड ऐप लगभग इतनी देर चलता रहता है
206 वह HTTP स्टेटस जो रिज़्यूम करना बिल्कुल मुमकिन बनाता है
1 बाइट सही तरीक़े से रिज़्यूम हुए ट्रांसफ़र का कितना हिस्सा दोबारा डाउनलोड होता है

ऐप बदलते ही ट्रांसफ़र क्यों रुकता है

iOS किसी ऐप को सिर्फ़ इसलिए काम करते रहने नहीं देता क्योंकि वह चाहेगा। जब आप ऐप छोड़ते हैं, यह सेकंडों में सस्पेंड हो जाता है, और एक सस्पेंडेड ऐप के पास न CPU समय है, न नेटवर्क सॉकेट, न यह नोटिस करने का कोई तरीक़ा कि इसे रोका जा चुका है। यह मेमोरी में जो कुछ पकड़े था वह अब भी वहीं है, पर जमा हुआ — और अगर सिस्टम को मेमोरी चाहिए, तो ऐप को बिना बताए सीधे बंद कर दिया जाता है।

ऐप के अंदर एक सामान्य कनेक्शन पर चल रहा डाउनलोड इसलिए होम जेस्चर पर ख़त्म हो जाता है। कुछ ऐप कुछ अतिरिक्त सेकंड का बैकग्राउंड समय मांगकर इसे छुपाते हैं, यही वजह है कि डाउनलोड कभी-कभी बैकग्राउंड में जाने के बिल्कुल उतने ही देर बचा रहता है जितना आपको नोटिस करने में लगे कि यह नहीं बचा।

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

चार तंत्र जो तय करते हैं कि डाउनलोड बचता है या नहीं

Range request: एक HTTP रिक्वेस्ट जो पूरी फ़ाइल के बजाय 5,000,000वें बाइट से आगे मांगती है। अगर सर्वर 206 Partial Content से जवाब दे, तो बीच से रिज़्यूम करना मुमकिन है; अगर यह 200 OK से जवाब देकर शुरुआत से लौटाता है, तो नहीं — फ़ाइल को शून्य से दोबारा लाना पड़ता है।
समानांतर कनेक्शन: एक फ़ाइल को कई हिस्सों में बांटकर एक साथ लाना। यह इसलिए मदद करता है क्योंकि एक अकेला कनेक्शन अक्सर सर्वर से सीमित होता है या राउंड-ट्रिप लेटेंसी से बंधा होता है, इसलिए नहीं कि ज़्यादा सॉकेट खुलने से आपका इंटरनेट तेज़ हो जाता है।
Committed offset: फ़ाइल का कितना हिस्सा सुरक्षित रूप से डिस्क पर लिखा गया है, बनाम अभी भी रास्ते में है। जो डाउनलोड आख़िरी committed बाइट से रिज़्यूम होता है वह सही है; जो यह सोचता है उससे रिज़्यूम होता है कि उसे *क्या* मिला था वह एक करप्ट फ़ाइल बनाता है जो घंटों बाद ही ख़ुद को दिखाती है।
बैकग्राउंड सेशन: ऊपर बताई गई सिस्टम-चलाई ट्रांसफ़र। शुरू होने में धीमी, कोई मनमाना कस्टम लॉजिक नहीं दी जा सकती, और यही अकेली चीज़ है जो ऐप के न चलते हुए भी चलती रहती है।

डाउनलोड क्यों फ़ेल होता है, और हर फ़ेलियर कैसा दिखता है

ज़्यादातर "अटका डाउनलोड" रिपोर्ट इन पांच में से एक है, और शक्ल पता होने पर इन्हें अलग बताना आसान है।

आप जो देखते हैं	असल में क्या हो रहा है	क्या मदद करता है
ऐप छोड़ते ही रुक जाता है	ट्रांसफ़र इन-प्रोसेस चल रहा था, बैकग्राउंड सेशन में नहीं।	बाहर से आप कुछ नहीं कर सकते — यह ऐप डिज़ाइन का मामला है।
हर बार 0% से दोबारा शुरू होता है	सर्वर range request मानता नहीं, इसलिए बीच से आगे बढ़ने का कोई तरीक़ा नहीं।	एक स्थिर कनेक्शन, या छोटी फ़ाइल। कुछ होस्ट सिर्फ़ साइन की गई लिंक के लिए रेंज इजाज़त देते हैं।
कुछ मिनट बाद बार-बार फ़ेल होता है	लिंक एक्सपायर हो गई है। कई होस्ट पांच या दस मिनट के लिए वैध URL जारी करते हैं।	लिंक को उसके पेज से दोबारा लाएं और फिर से शुरू करें; पुरानी कभी काम नहीं करेगी।
तेज़ी से डाउनलोड होता है, फिर फ़ाइल नहीं खुलती	जो पहुंचा वह एक HTML एरर पेज या वीडियो फ़ाइल के नाम वाला लॉगिन पेज था।	साइज़ जांचें — 14 KB की "फ़िल्म" एक वेब पेज है। लिंक को कमिट करने से पहले जांचें।
तेज़ कनेक्शन के बावजूद बहुत धीमा	सर्वर के सिरे पर प्रति-कनेक्शन थ्रॉटलिंग।	अगर सर्वर इजाज़त दे तो ज़्यादा समानांतर कनेक्शन। अगर यह सॉकेट के बजाय IP पते से कैप करता है, तो कुछ मदद नहीं करेगा।

जब डाउनलोड करने के लिए कोई फ़ाइल है ही नहीं

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

एक को सेव करने का मतलब है हर सेगमेंट लाना और फिर रीमक्स करना: वीडियो और ऑडियो स्ट्रीम को एक सामान्य MP4 कंटेनर में लिखना। कुछ भी दोबारा एन्कोड नहीं होता, इसलिए कुछ खोता नहीं और इसमें फ़िल्म जितनी लंबाई के बजाय कुछ सेकंड लगते हैं। नतीजा एक सामान्य फ़ाइल है जो कहीं भी चलती है।

यही वजह है कि "यह स्ट्रीम डाउनलोड करो" फ़ाइल डाउनलोड करने से शुरू होने में साफ़ ज़्यादा समय लेता है: प्लेलिस्ट को लाना और पार्स करना पड़ता है, एक क्वालिटी स्तर चुनना पड़ता है, और तभी सेगमेंट आना शुरू हो सकते हैं। और यही वजह है कि कुछ स्ट्रीम बिल्कुल सेव नहीं हो सकतीं — अगर सेगमेंट DRM स्कीम के तहत एन्क्रिप्टेड हैं, तो कीज़ जान-बूझकर पाई नहीं जा सकतीं, और क़ानून का सम्मान करने वाला कोई भी टूल इसे पार नहीं करेगा।

असली डाउनलोड मैनेजर को डाउनलोड बटन से क्या अलग करता है

यह ऐप बंद होने से बचता है

बैकग्राउंड ट्रांसफ़र सिस्टम को सौंपे गए, एक हैंडओवर के साथ जो फ़ाइल दोबारा शुरू करने के बजाय उसी committed बाइट से जारी रहता है।

यह कमिट करने से पहले लिंक के बारे में बताता है

साइज़, टाइप और सर्वर रिज़्यूमिंग सपोर्ट करता है या नहीं — सब एक अकेली HEAD रिक्वेस्ट से जाना जा सकता है, और डेटा प्लान के चार गीगाबाइट ख़र्च करने से पहले सब उपयोगी।

यह भर देने के बजाय क़तार लगाता है

एक साथ दस फ़ाइलें तीन-तीन से धीमी हैं, क्योंकि हर कनेक्शन को छोटा हिस्सा मिलता है और फ़ेलियर बढ़ते हैं। एक समझदार समानांतरता लिमिट वाली क़तार पहले ख़त्म होती है।

जो पहुंचता है वह एक सामान्य फ़ाइल है

एक फ़ोल्डर में जिसे आप देख सकते हैं, समझदारी से नाम रखी, कुछ भी उसे चला सकता है — कोई डेटाबेस blob नहीं जिसे सिर्फ़ वही ऐप खोल सके।

आदतें जो ज़्यादातर डाउनलोड समस्याएं रोकती हैं

बड़ी फ़ाइलें Wi-Fi पर शुरू करें और पहले कुछ सेकंड स्क्रीन ऑन रखें
बैकग्राउंड सेशन को हैंडओवर जल्दी होता है; उसके बाद स्क्रीन का कोई मतलब नहीं रहता।
एक साथ बीस आइटम क़तार में न लगाएं
लगभग हर कनेक्शन पर तीन से पांच समानांतर ट्रांसफ़र सबसे अच्छी जगह है।
बाद में नहीं, पहले खाली जगह जांचें
डिस्क भर देने वाला ट्रांसफ़र 98% पर फ़ेल होता है, और iOS ने शायद जगह बनाने की कोशिश में आपके कैश पहले ही साफ़ कर दिए हों।
तुरंत "पूरा" होने को शक की नज़र से देखें
दो सेकंड में ख़त्म हुई फ़िल्म एक एरर पेज है। फ़ाइल साइज़ देखें।
एक्सपायर लिंक उनके पेज से दोबारा लाएं
मरे साइन किए URL को दोबारा कोशिश करना हमेशा फ़ेल होगा, ऐप चाहे कितनी भी बार कोशिश करे।

यह डिवाइस के बीच कैसे अलग है

iPhone

सबसे सख़्त माहौल: सस्पेंशन आक्रामक है और स्टोरेज तंग है। बैकग्राउंड सेशन यहां कोई ऑप्टिमाइज़ेशन नहीं, यही अकेली चीज़ है जो काम करती है।

iPad

वही नियम, ज़्यादा जगह के साथ चलने की — और अकेला iOS डिवाइस जहां एक बड़ी लाइब्रेरी इंटरनल स्टोरेज के बजाय समझदारी से एक्सटर्नल ड्राइव पर उतर सकती है।

Mac

कोई सस्पेंशन बिल्कुल नहीं, इसलिए लंबे ट्रांसफ़र वैसे ही चलते हैं जैसे किसी भी डेस्कटॉप पर। व्यावहारिक सीमा सर्वर है, ऑपरेटिंग सिस्टम नहीं।

इससे उठने वाले सवाल

क्या ज़्यादा कनेक्शन का मतलब हमेशा तेज़ डाउनलोड है?

नहीं। ये तब मदद करते हैं जब सर्वर हर कनेक्शन की स्पीड सीमित करता है, जो आम है। जब लिमिट आपका अपना कनेक्शन हो तो ये कुछ नहीं करते, और जब कोई होस्ट प्रति-IP सॉकेट गिने और मना करना शुरू करे तो हालत ख़राब हो सकती है। चार से आठ के बीच उपयोगी रेंज है; तीस उल्टा असर करता है।

क्या स्क्रीन लॉक होने पर भी डाउनलोड जारी रह सकता है?

हां, अगर यह सिस्टम की बैकग्राउंड ट्रांसफ़र सेवा को सौंपा गया हो। लॉक स्क्रीन उस सेवा के लिए बेमानी है — मायने ऐप का सस्पेंड होना रखता है, और पूरे तंत्र का मक़सद ही यह है कि यह वैसे भी चलता रहे।

मेरा डाउनलोड रिज़्यूम होने के बजाय दोबारा क्यों शुरू होता है?

सर्वर ने range request का सम्मान नहीं किया। आप बता सकते हैं क्योंकि प्रोग्रेस आगे बढ़ने के बजाय शून्य पर लौटती है। कुछ होस्ट सिर्फ़ अपने साइन किए डाउनलोड URL पर रेंज सपोर्ट करते हैं, कुछ इसे पूरी तरह बंद कर देते हैं, और कुछ छोटी फ़ाइलों के लिए मानते हैं बड़ी के लिए नहीं।

क्या स्ट्रीम को MP4 में बदलना उसे दोबारा एन्कोड करने जैसा ही है?

नहीं। रीमक्सिंग मौजूदा वीडियो और ऑडियो को बिना छुए एक MP4 कंटेनर में ले जाती है — लॉसलेस, और कुछ सेकंड में ख़त्म होने लायक़ तेज़। री-एन्कोडिंग तस्वीर को अलग कोडेक से दोबारा बनाती है और हमेशा क्वालिटी खोती है। अगर दो घंटे की स्ट्रीम सेव करने में दो घंटे लगें, तो कुछ बिना ज़रूरत के दोबारा एन्कोड हो रहा है।

FoxDL

FoxDL कैसे डाउनलोड करता है

इंजन के दो रास्ते हैं: एक इन-प्रोसेस जो ऐप स्क्रीन पर होते हुए तेज़ है, और सिस्टम बैकग्राउंड सेशन जो ऐप न होने पर उसी बाइट से आगे संभाल लेता है।

एक फ़ाइल के लिए समानांतर हिस्से, जो सीधे डिस्क पर अपनी आख़िरी जगह पर लिखे जाते हैं, बाद में जोड़े जाने वाले अस्थायी हिस्सों में नहीं।
बैकग्राउंड ट्रांसफ़र जो ऐप स्क्रीन छोड़ने के बाद भी जारी रहते हैं, और आख़िरी committed offset से आगे बढ़ते हैं — उस आख़िरी बाइट से नहीं जो ऐप को लगा था उसे मिली है।
ड्रॉप, रीबूट या फ़ोर्स-क्विट के बाद रिज़्यूम, बशर्ते सर्वर range request का सम्मान करे। जब नहीं करता, तो FoxDL लूप करने के बजाय यह बता देता है।
HLS स्ट्रीम MP4 में रीमक्स होती हैं, इसलिए लाइब्रेरी में जो उतरता है वह एक सामान्य फ़ाइल है, सेगमेंट का फ़ोल्डर नहीं।
एक डाउनलोड इंस्पेक्टर जो शुरू करने से पहले लिंक का असली साइज़, टाइप और रिज़्यूम सपोर्ट बताता है।
सब कुछ एक सामान्य फ़ोल्डर में उतरता है जिसे Files ऐप देख सकता है।

फ़्री भत्ते प्लेटफ़ॉर्म के हिसाब से अलग हैं: iPhone और iPad पर कुछ पास, ख़ुद शुरू किए एक छोटे रिवॉर्डेड वीडियो से भरे; Mac पर, जहां कोई विज्ञापन बिल्कुल नहीं, एक तय रोज़ाना गिनती। Pro हर डिवाइस पर लिमिट हटा देता है।

अक्सर पूछे जाने वाले प्रश्न

सभी प्रश्न

आपकी लाइब्रेरी, आख़िरकार एक ही जगह।

मुफ़्त डाउनलोड। कोई खाता नहीं — पूरी सुविधाएँ मुफ़्त संस्करण में।

डाउनलोड करें App Store