ডাউনলোড করা

একটা ডাউনলোড ম্যানেজার যা করে, একটা ওয়েব ব্রাউজার যা করবে না

চার গিগাবাইটের একটা ফাইল, নব্বই শতাংশ শেষ, আর তারপর একটা ফোন কল — বা শুধু একটা লক হওয়া স্ক্রিন — আর সেটা উধাও। iOS-এ ডাউনলোড নিয়ে এটাই সবচেয়ে সাধারণ অভিযোগ, আর এটা কোনো বাগ না। এটা অপারেটিং সিস্টেম ঠিক যা করার জন্য বানানো হয়েছিল তাই করছে, আর এই কারণেই একটা আলাদা ধরনের অ্যাপ থাকার দরকার হয়।

7 মিনিট পড়া আপডেট ২৯ জুলাই, ২০২৬

  • ৩০ সেকেন্ড একটা সাসপেন্ড করা অ্যাপ iOS বন্ধ করার আগে মোটামুটি যতক্ষণ চলতে থাকে
  • ২০৬ HTTP স্ট্যাটাস যা রিজিউমিংকে সম্ভব করে তোলে
  • ১ বাইট একটা ঠিকমতো রিজিউম করা ট্রান্সফারের কতটুকু আবার ডাউনলোড হয়

অ্যাপ বদলালে ট্রান্সফার কেন থেমে যায়

iOS কোনো অ্যাপকে শুধু ইচ্ছা হলেই কাজ চালিয়ে যেতে দেয় না। তুমি একটা অ্যাপ থেকে বেরিয়ে গেলে, এটা কয়েক সেকেন্ডের মধ্যেই সাসপেন্ড হয়ে যায়, আর একটা সাসপেন্ড করা অ্যাপের কোনো CPU সময়, কোনো নেটওয়ার্ক সকেট নেই, আর এটা বন্ধ হয়েছে তা খেয়াল করার কোনো উপায়ও নেই। মেমরিতে যা রাখা ছিল তা এখনো আছে, কিন্তু জমাট বাঁধা — আর সিস্টেমের সেই মেমরি দরকার হলে, অ্যাপটাকে না জানিয়েই একদম শেষ করে দেওয়া হয়।

অ্যাপের ভেতরে একটা সাধারণ কানেকশনে চলা একটা ডাউনলোড তাই হোম জেসচারেই শেষ হয়ে যায়। কিছু অ্যাপ কয়েক সেকেন্ডের অতিরিক্ত ব্যাকগ্রাউন্ড সময় চেয়ে এটা লুকায়, যে কারণে একটা ডাউনলোড মাঝেমধ্যে ব্যাকগ্রাউন্ডে যাওয়ার পর ঠিক ততক্ষণই টিকে থাকে যতক্ষণে তুমি খেয়াল করো যে এটা টেকেনি।

সঠিক উত্তরটা পুরোপুরি ভিন্ন ধরনের। iOS একটা ব্যাকগ্রাউন্ড ট্রান্সফার সার্ভিস দেয়: তুমি সিস্টেমকে একটা URL আর গন্তব্যের তালিকা দাও, আর সিস্টেম নিজে, নিজের প্রসেসে, নিজের সময়সূচিতে ডাউনলোডটা করে। তোমার অ্যাপ সাসপেন্ড হতে পারে, শেষ হয়ে যেতে পারে, বা একদমই না চলতে পারে — ট্রান্সফার চলতে থাকে, আর রিপোর্ট করার মতো কিছু হলে অ্যাপটা ব্যাকগ্রাউন্ডে আবার চালু হয়। একটা লক হওয়া স্ক্রিন পার করে বেঁচে থাকা প্রতিটা ডাউনলোডের পেছনে এই ব্যবস্থাটাই আছে, আর এটা ব্যবহার করা একটা অ্যাপের শুরুতেই নেওয়া একটা ডিজাইন সিদ্ধান্ত, তুমি চালু করতে পারো এমন একটা সেটিং না।

যে চারটা প্রক্রিয়া ঠিক করে একটা ডাউনলোড টিকবে কিনা

রেঞ্জ রিকোয়েস্ট
পুরো ফাইলের বদলে ৫,০০০,০০০ বাইট থেকে শুরু করে চাওয়া একটা HTTP রিকোয়েস্ট। সার্ভার 206 Partial Content দিয়ে উত্তর দিলে, মাঝখান থেকে রিজিউম করা সম্ভব; 200 OK দিয়ে শুরু থেকে শুরু করলে, সম্ভব না — ফাইলটা শূন্য থেকে আবার আনতে হবে।
প্যারালাল কানেকশন
একটা ফাইলকে কয়েকটা রেঞ্জে ভাগ করে একই সাথে আনা। এটা কাজে দেয় কারণ একটা একক কানেকশন প্রায়ই সার্ভারের সীমাবদ্ধ করা বা রাউন্ড-ট্রিপ লেটেন্সির কারণে ধীর হয়ে যায়, তোমার ইন্টারনেট বেশি সকেট খোলার সাথে দ্রুত হয় বলে না।
কমিটেড অফসেট
ফাইলের কতটুকু নিরাপদে ডিস্কে লেখা হয়েছে, এখনো চলমান থাকার বিপরীতে। একটা ডাউনলোড যেটা শেষ কমিট করা বাইট থেকে রিজিউম করে সেটা সঠিক; যেটা এটা কী *পেয়েছে বলে মনে করে* তা থেকে রিজিউম করে সেটা এমন একটা ভাঙা ফাইল তৈরি করে যা ঘণ্টাখানেক পরেই নিজের আসল রূপ দেখায়।
ব্যাকগ্রাউন্ড সেশন
ওপরে বর্ণিত সিস্টেম-চালিত ট্রান্সফার। এটা শুরু হতে বেশি সময় নেয়, একে যেকোনো কাস্টম লজিক দেওয়া যায় না, আর অ্যাপটা না চললেও এটাই একমাত্র জিনিস যা চলতে থাকে।

একটা ডাউনলোড কেন ব্যর্থ হয়, আর প্রতিটা ব্যর্থতা কেমন দেখায়

বেশিরভাগ "আটকে থাকা ডাউনলোড" রিপোর্ট এই পাঁচটার একটা, আর এদের আকৃতি জানলে আলাদা করাটা সহজ।

তুমি যা দেখোআসলে যা ঘটছেকী সাহায্য করে
অ্যাপ থেকে বেরিয়ে যাওয়ার মুহূর্তেই থেমে যায়ট্রান্সফারটা প্রসেসের ভেতরে চলছিল, একটা ব্যাকগ্রাউন্ড সেশনে না।বাইরে থেকে তোমার কিছু করার নেই — এটা একটা অ্যাপ ডিজাইনের সমস্যা।
প্রতিবার ০% থেকে আবার শুরু হয়সার্ভার রেঞ্জ রিকোয়েস্ট উপেক্ষা করে, তাই মাঝখান থেকে চালিয়ে যাওয়ার কোনো উপায় নেই।একটা স্থিতিশীল কানেকশন, বা একটা ছোট ফাইল। কিছু হোস্ট শুধু সাইন করা লিংকের জন্যই রেঞ্জ অনুমতি দেয়।
কয়েক মিনিট পর, বারবার ব্যর্থ হয়লিংকটার মেয়াদ শেষ। অনেক হোস্ট পাঁচ বা দশ মিনিটের জন্য বৈধ URL দেয়।নিজের পাতা থেকে লিংকটা আবার আনো আর নতুন করে শুরু করো; পুরনোটা কখনো কাজ করবে না।
দ্রুত ডাউনলোড হয়, তারপর ফাইলটা খোলে নাযা এসেছে তা একটা ভিডিও ফাইলের নামের একটা HTML এরর পাতা বা লগইন পাতা।আকারটা দেখো — একটা ১৪ KB "সিনেমা" আসলে একটা ওয়েব পাতা। কমিট করার আগে লিংকটা পরীক্ষা করো।
দ্রুত কানেকশন থাকা সত্ত্বেও খুবই ধীরসার্ভারের দিকে প্রতি-কানেকশন থ্রটলিং।সার্ভার অনুমতি দিলে আরও প্যারালাল কানেকশন। এটা সকেটের বদলে IP অ্যাড্রেস দিয়ে সীমা বাঁধলে, কিছুই সাহায্য করবে না।

যখন ডাউনলোড করার মতো কোনো ফাইলই নেই

ওয়েবের অনেকখানি ভিডিও একটা ফাইল হিসেবে আসে না। এটা আসে HLS হিসেবে — একটা .m3u8 প্লেলিস্ট যা কয়েকশো ছোট সেগমেন্টের তালিকা দেয়, প্রতিটা কয়েক সেকেন্ডের, প্রায়ই একাধিক কোয়ালিটি লেভেলে যাতে তোমার কানেকশন বদলালে প্লেয়ার বদলাতে পারে। সিনেমাটা ধরে রাখার মতো একক কোনো URL নেই, কারণ সিনেমাটা শুধু একটা ক্রম হিসেবেই আছে।

একটা সেভ করা মানে প্রতিটা সেগমেন্ট আনা আর তারপর রিমাক্স করা: ভিডিও আর অডিও স্ট্রিম একটা সাধারণ MP4 কন্টেইনারে লেখা। কিছুই আবার এনকোড হয় না, তাই কিছুই হারায় না আর এটায় সিনেমার দৈর্ঘ্যের বদলে সেকেন্ড লাগে। ফলাফলটা একটা সাধারণ ফাইল যা যেকোনো জায়গায় চলে।

এই কারণেই "এই স্ট্রিমটা ডাউনলোড করো" একটা ফাইল ডাউনলোড করার চেয়ে শুরু হতে লক্ষণীয়ভাবে বেশি সময় নেয়: প্লেলিস্টটা আনতে আর পার্স করতে হয়, একটা কোয়ালিটি লেভেল বাছতে হয়, আর তারপরই সেগমেন্ট আসতে শুরু করতে পারে। আর এই কারণেই কিছু স্ট্রিম একদমই সেভ করা যায় না — সেগমেন্টগুলো একটা DRM স্কিমের অধীনে এনক্রিপ্ট করা থাকলে, চাবিগুলো ইচ্ছাকৃতভাবে পাওয়া যায় না, আর আইন মেনে চলা কোনো টুলই এটা এড়িয়ে যেতে পারবে না।

একটা আসল ডাউনলোড ম্যানেজারকে একটা ডাউনলোড বোতামের থেকে যা আলাদা করে

এটা অ্যাপ বন্ধ হওয়ার পরও টিকে থাকে

সিস্টেমকে দেওয়া ব্যাকগ্রাউন্ড ট্রান্সফার, একটা হ্যান্ডওভারসহ যা একই কমিটেড বাইট থেকে চলতে থাকে, ফাইল আবার শুরু করার বদলে।

কমিট করার আগে এটা বলে দেয় একটা লিংক কী

আকার, ধরন আর সার্ভার রিজিউমিং সাপোর্ট করে কিনা — সবকিছু একটা মাত্র HEAD রিকোয়েস্ট থেকে জানা যায়, আর একটা ডেটা প্ল্যানের চার গিগাবাইট খরচ করার আগে সবই কাজে লাগে।

এটা ভাসিয়ে দেওয়ার বদলে সারিবদ্ধ করে

একসাথে দশটা ফাইল একসাথে তিনটার চেয়ে ধীর, কারণ প্রতিটা কানেকশন ছোট একটা ভাগ পায় আর ব্যর্থতা বেড়ে যায়। যুক্তিসঙ্গত একটা কনকারেন্সি সীমাসহ একটা সারি আগে শেষ হয়।

যা নামে সেটা একটা সাধারণ ফাইল

তুমি দেখতে পাও এমন একটা ফোল্ডারে, বুদ্ধিমানের মতো নাম দেওয়া, যেকোনো কিছুতে চলার মতো — শুধু সেই অ্যাপই খুলতে পারে এমন একটা ডেটাবেস ব্লব না।

যে অভ্যাস বেশিরভাগ ডাউনলোড সমস্যা এড়ায়

  • বড় ফাইল Wi-Fi-তে শুরু করো আর প্রথম কয়েক সেকেন্ড স্ক্রিন চালু রাখো

    ব্যাকগ্রাউন্ড সেশনে হ্যান্ডওভার হয় দ্রুতই; তারপর স্ক্রিন আর গুরুত্বপূর্ণ থাকে না।

  • একসাথে বিশটা আইটেম সারিবদ্ধ করবে না

    প্রায় সব কানেকশনেই তিন থেকে পাঁচটা একসাথে চলা ট্রান্সফার সবচেয়ে ভালো।

  • আগে খালি জায়গা দেখো, পরে না

    একটা ট্রান্সফার যা ডিস্ক ভরিয়ে দেয় তা ৯৮%-এ ব্যর্থ হয়, আর iOS হয়তো জায়গা বানাতে ততক্ষণে তোমার ক্যাশ পরিষ্কার করে ফেলেছে।

  • একটা তাৎক্ষণিক "সম্পন্ন"-কে সন্দেহের চোখে দেখো

    দুই সেকেন্ডে শেষ হওয়া একটা সিনেমা মানে একটা এরর পাতা। ফাইলের আকারটা দেখো।

  • মেয়াদ শেষ হওয়া লিংক তাদের পাতা থেকে আবার আনো

    একটা মৃত সাইন করা URL আবার চেষ্টা করলে অ্যাপ যতবারই চেষ্টা করুক, চিরকাল ব্যর্থই হবে।

ডিভাইস জুড়ে এটা কীভাবে আলাদা

iPhone

সবচেয়ে কঠোর পরিবেশ: সাসপেনশন আক্রমণাত্মক আর স্টোরেজ টাইট। ব্যাকগ্রাউন্ড সেশন এখানে একটা অপ্টিমাইজেশন না, এটাই একমাত্র জিনিস যা কাজ করে।

iPad

একই নিয়ম, চলার জন্য বেশি জায়গাসহ — আর একমাত্র iOS ডিভাইস যেখানে একটা বড় লাইব্রেরি যুক্তিসঙ্গতভাবে ইন্টারনাল স্টোরেজের বদলে একটা এক্সটার্নাল ড্রাইভে যেতে পারে।

Mac

কোনো সাসপেনশনই নেই, তাই লম্বা ট্রান্সফার যেকোনো ডেস্কটপের মতোই আচরণ করে। বাস্তব সীমাটা সার্ভার, অপারেটিং সিস্টেম না।

এখানে যেসব প্রশ্ন ওঠে

বেশি কানেকশন মানেই কি সবসময় দ্রুত ডাউনলোড?

না। এটা কাজে দেয় যখন একটা সার্ভার প্রতিটা কানেকশনের গতি সীমাবদ্ধ করে, যা সাধারণ। যখন সীমাটা তোমার নিজের কানেকশন, তখন এটা কিছুই করে না, আর একটা হোস্ট প্রতি IP অ্যাড্রেসে সকেট গোনা শুরু করলে ও প্রত্যাখ্যান করলে জিনিস আরও খারাপ করতে পারে। চার থেকে আট এর মধ্যে কোনো জায়গা কাজের সীমা; ত্রিশ পাল্টা ফল দেয়।

স্ক্রিন লক থাকলেও কি একটা ডাউনলোড চলতে পারে?

হ্যাঁ, যদি এটা সিস্টেমের ব্যাকগ্রাউন্ড ট্রান্সফার সার্ভিসকে দেওয়া হয়ে থাকে। লক স্ক্রিন এই সার্ভিসের জন্য অপ্রাসঙ্গিক — অ্যাপটা সাসপেন্ড হওয়াই এখানে গুরুত্বপূর্ণ, আর এই ব্যবস্থার পুরো লক্ষ্যই হলো এটা যাই হোক না কেন চলতে থাকে।

আমার ডাউনলোড কেন রিজিউম না করে আবার শুরু হয়?

সার্ভার রেঞ্জ রিকোয়েস্ট মানেনি। তুমি বুঝতে পারবে কারণ প্রগ্রেসটা এগোনোর বদলে শূন্যে ফিরে যায়। কিছু হোস্ট শুধু তাদের সাইন করা ডাউনলোড URL-এই রেঞ্জ সাপোর্ট করে, কিছু এটা পুরোপুরি বন্ধ রাখে, আর কয়েকটা ছোট ফাইলে এটা মানে কিন্তু বড় ফাইলে না।

একটা স্ট্রিমকে MP4-এ রূপান্তর করা কি একে আবার এনকোড করার মতোই?

না। রিমাক্সিং বিদ্যমান ভিডিও আর অডিওকে অক্ষত অবস্থায় একটা MP4 কন্টেইনারে সরিয়ে নেয় — লসলেস, আর কয়েক সেকেন্ডেই শেষ হওয়ার মতো দ্রুত। রি-এনকোডিং একটা ভিন্ন কোডেক দিয়ে ছবিটা আবার বানায় আর সবসময় কিছু মান হারায়। একটা দুই ঘণ্টার স্ট্রিম সেভ করতে দুই ঘণ্টা লাগলে, দরকার না থাকা সত্ত্বেও কিছু একটা আবার এনকোড হচ্ছে।

FoxDL

FoxDL কীভাবে ডাউনলোড করে

ইঞ্জিনটার দুটো লেন আছে: একটা প্রসেসের ভেতরের, যা অ্যাপ স্ক্রিনে থাকলে দ্রুত চলে, আর সিস্টেমের ব্যাকগ্রাউন্ড সেশন, যা না থাকলে একই বাইট থেকে দায়িত্ব নেয়।

  • একটা ফাইলের জন্য প্যারালাল চাংক, পরে জোড়া লাগাতে হয় এমন সাময়িক অংশের বদলে সরাসরি ডিস্কে নিজের শেষ জায়গায় লেখা।
  • ব্যাকগ্রাউন্ড ট্রান্সফার যা অ্যাপ স্ক্রিন থেকে সরে যাওয়ার পরও চলতে থাকে, আর শেষ কমিটেড অফসেট থেকে শুরু করে — অ্যাপ কী পেয়েছে বলে মনে করেছিল সেই শেষ বাইট থেকে না।
  • একটা বিচ্ছিন্নতা, একটা রিবুট বা একটা ফোর্স-কুইটের পরও রিজিউম, যদি সার্ভার রেঞ্জ রিকোয়েস্ট মানে। মানলে না, FoxDL লুপ করার বদলে এটা বলে দেয়।
  • HLS স্ট্রিম MP4-এ রিমাক্স করা হয়, তাই লাইব্রেরিতে যা নামে তা সেগমেন্টের একটা ফোল্ডার না, একটা সাধারণ ফাইল।
  • শুরু করার আগে একটা লিংকের আসল আকার, ধরন আর রিজিউম সাপোর্ট রিপোর্ট করা একটা ডাউনলোড ইনস্পেক্টর
  • সবকিছু একটা সাধারণ ফোল্ডারে নামে যা Files অ্যাপ দেখতে পায়।

ফ্রি সুযোগ প্ল্যাটফর্ম অনুযায়ী আলাদা: iPhone আর iPad-এ তুমি নিজে শুরু করা একটা ছোট রিওয়ার্ডেড ভিডিও দিয়ে ভরে নেওয়া অল্প কয়েকটা পাস; Mac-এ, যেখানে একদমই কোনো বিজ্ঞাপন নেই, একটা নির্দিষ্ট দৈনিক সংখ্যা। Pro প্রতিটা ডিভাইসে এই সীমা সরিয়ে দেয়।

সাধারণ প্রশ্ন

সব প্রশ্ন

আরও পড়ুন

তোমার লাইব্রেরি, অবশেষে এক জায়গায়।

বিনামূল্যে ডাউনলোড। অ্যাকাউন্ট নেই — সব ফিচার ফ্রি ভার্সনে।

ডাউনলোড করো App Store থেকে