VPS-এ নিজের মিউজিক স্ট্রিমিং সার্ভার সেটআপ করার নিয়ম

VPS-এ self-hosted মিউজিক স্ট্রিমিং থেকে আপনি যা পাবেন

VPS-এ self-hosted মিউজিক স্ট্রিমিংয়ের অর্থ হলো, আপনি নিজেই মিউজিক প্লেয়ারটি চালাচ্ছেন এবং মিউজিক ফাইলগুলো সরবরাহ করছেন। আপনার কেনা ফাইলগুলো সার্ভারে জমা থাকে এবং যেকোনো ফোন থেকে সাধারণ লগইন ব্যবহার করে ইন্টারনেটের মাধ্যমে সেগুলো অ্যাক্সেস করা যায়। শুরু করার আগে এই বিষয়টি পরিষ্কার থাকা প্রয়োজন: এটি কোনো স্ট্রিমিং সার্ভিসের ক্যাটালগ নয়, বরং কেবল তাদের প্লেয়ারের বিকল্প। আপনি নিজে না কেনা বা রিপ (rip) করে সার্ভারে কপি না করা পর্যন্ত আপনার লাইব্রেরিতে নতুন কোনো গান যুক্ত হবে না।

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

কোন মিউজিক সার্ভারটি বেছে নেবেন: Navidrome, Jellyfin নাকি Funkwhale?

Navidrome হলো ডিফল্ট পছন্দ যদি আপনি শুধুমাত্র অডিও নিয়ে কাজ করতে চান। এটি একটি একক Go binary এবং একটি কন্টেইনারে চলে, যা তার স্টেট একটি মাত্র SQLite ডাটাবেসে সংরক্ষণ করে। এটি Subsonic API সমর্থন করে, যার কারণেই মূলত প্রচুর সংখ্যক থার্ড-পার্টি ফোন অ্যাপ বিদ্যমান। 2026 সালের আগস্ট মাসে সংস্করণ 0.63.2 ছিল বর্তমান সংস্করণ। প্রজেক্টটির বর্ণনা অনুযায়ী এটি Raspberry Pi Zero-এর মতো ছোট হার্ডওয়্যারেও ভালোভাবে চলে, তাই সার্ভার সফটওয়্যারের জন্য আপনাকে কোনো খরচ করতে হবে না।

Jellyfin ব্যবহার করা যুক্তিযুক্ত যদি আপনি ইতিমধ্যে ভিডিওর জন্য Jellyfin as a media server on a VPS হিসেবে ব্যবহার করে থাকেন। এর মিউজিক লাইব্রেরি কার্যকর এবং Finamp হলো Android ও iOS-এর জন্য একটি Jellyfin মিউজিক অ্যাপ, যা অফলাইনে শোনার জন্য ট্র্যাক ডাউনলোড করতে পারে। এর সীমাবদ্ধতা হলো API। Jellyfin-এ কোনো বিল্ট-ইন Subsonic endpoint নেই এবং যে কমিউনিটি প্লাগইনটি এটি যুক্ত করত, সেটির আপডেট 2022 সালে বন্ধ হয়ে গেছে, তাই Subsonic অ্যাপ ইকোসিস্টেম এর জন্য বন্ধ। আপনাকে Jellyfin-এর নিজস্ব API ব্যবহার করে এমন অ্যাপগুলোই ব্যবহার করতে হবে, যার সংখ্যা তুলনামূলক কম।

Funkwhale হলো ফেডারেশনের সুবিধা সম্বলিত বিকল্প এবং 2026 সালের মার্চ মাসে এর সংস্করণ 2.0 রিলিজ হয়েছে। একটি Funkwhale সার্ভারকে পড (pod) বলা হয়, পডগুলো ActivityPub (Mastodon-এর পেছনের প্রোটোকল) এর মাধ্যমে ফেডারেশন করে এবং এক পডের ব্যবহারকারী অন্য পডের পাবলিক লাইব্রেরি অনুসরণ করতে পারেন। এটিও Subsonic API-এর কিছু অংশ সমর্থন করে, তবে একটি পার্থক্য জেনে রাখা জরুরি: প্রতিটি ব্যবহারকারীকে তাদের নিজস্ব সেটিংসে আলাদা Subsonic পাসওয়ার্ড সেট করতে হয়, কারণ Subsonic প্রোটোকল এমন একটি পাসওয়ার্ড আশা করে যা সার্ভার পুনরায় পড়তে পারে। Funkwhale ইনস্টল করা কিছুটা জটিল, কারণ ওয়েব অ্যাপের পাশাপাশি এর জন্য PostgreSQL এবং একটি টাস্ক কিউ (task queue) প্রয়োজন।

যদি আপনার ফেডারেশনের প্রয়োজন না থাকে অথবা Jellyfin ইতিমধ্যে চলমান না থাকে, তবে Navidrome বেছে নিন। এই গাইডের বাকি অংশে Docker ব্যবহার করে Navidrome সেটআপ করা হয়েছে।

কেন Subsonic API নির্ধারণ করে আপনি কোন ফোন অ্যাপটি ব্যবহার করবেন

Subsonic ছিল একটি মিউজিক সার্ভার যার HTTP API সেলফ-হোস্টেড অডিওর জন্য সাধারণ ভাষা হয়ে উঠেছিল, এবং OpenSubsonic হলো সেই কমিউনিটি প্রজেক্ট যা এটিকে ক্রমাগত উন্নত করছে। এই ইতিহাসের কারণেই আপনার ফোনে বিভিন্ন বিকল্প রয়েছে। Navidrome-এর নিজস্ব কোনো মোবাইল অ্যাপ নেই এবং এর প্রয়োজনও নেই, কারণ যেকোনো Subsonic ক্লায়েন্ট সার্ভার অ্যাড্রেস এবং আপনার অ্যাকাউন্টের বিবরণ দিয়ে লগ ইন করতে পারে।

অফলাইন সিঙ্ক (offline sync)-এর ক্ষেত্রে এটি সবচেয়ে গুরুত্বপূর্ণ, কারণ এই ফিচারটিই নির্ধারণ করে আপনার সেটআপটি দৈনন্দিন ব্যবহারের উপযোগী কি না। টানেলের ভেতর থাকা ফোন আপনার সার্ভারে পৌঁছাতে পারে না, তাই ক্লায়েন্টকে অবশ্যই আগে থেকেই ফাইলগুলো লোকাল স্টোরেজে কপি করে রাখতে হবে। প্রতিটি ক্লায়েন্টই স্ট্রিমিং করতে পারে। কিন্তু কেবল কিছু ক্লায়েন্ট ডাউনলোড করার সুবিধা দেয়। navidrome.org/apps-এ থাকা ক্লায়েন্ট ডিরেক্টরিতে কোনগুলো এই সুবিধা দেয় তা উল্লেখ করা আছে, এবং উভয় প্ল্যাটফর্মেই প্রচুর বিকল্প রয়েছে: অ্যান্ড্রয়েডে Substreamer ও Ultrasonic, এবং iOS-এ Amperfy ও play:Sub। শক্তিশালী ক্লায়েন্টগুলোর মধ্যে কয়েকটি পেইড অ্যাপ, এবং অ্যান্ড্রয়েডের ক্ষেত্রে Symfonium-এর নাম সবচেয়ে বেশি শোনা যায়। সিদ্ধান্ত নেওয়ার আগে অন্তত দুটি অ্যাপ ইনস্টল করে দেখুন, কারণ সিস্টেমের এই অংশটিই আপনি প্রতিদিন ব্যবহার করবেন।

একটি মিউজিক লাইব্রেরির জন্য কতটুকু স্টোরেজ প্রয়োজন?

[
  {
    "label": "Opus 128k",
    "kbps": 128,
    "gb_per_1000_albums": 43
  },
  {
    "label": "MP3 320k",
    "kbps": 320,
    "gb_per_1000_albums": 108
  },
  {
    "label": "FLAC 16/44.1",
    "kbps": 900,
    "gb_per_1000_albums": 304
  },
  {
    "label": "FLAC 24/96",
    "kbps": "3,000",
    "gb_per_1000_albums": "1,013"
  }
]

এই হিসাবগুলো বিটরেট থেকে পাওয়া আনুমানিক মান, কোনো বাস্তব সংগ্রহের পরিমাপ নয়। আপনার নিজের ফাইলের সাথে মিলিয়ে দেখার জন্য এই গাণিতিক হিসাবটি যথেষ্ট সহজ। একটি অ্যালবামকে 45 মিনিট বা 2,700 সেকেন্ড হিসেবে ধরুন। প্রতি সেকেন্ডে কিলোবিট হিসেবে বিটরেটকে 2,700 দিয়ে গুণ করুন, তারপর 8,000 দিয়ে ভাগ করে মেগাবাইট বের করুন। 320 kbps বিটরেটে একটি অ্যালবামের আকার হয় 108 MB, তাই এক হাজার অ্যালবামের জন্য প্রায় 108 GB জায়গা প্রয়োজন।

লসলেস (Lossless) ফরম্যাটের ক্ষেত্রে হিসাবটি ভিন্ন। সাধারণ অডিওর ক্ষেত্রে CD কোয়ালিটির FLAC গড়ে প্রায় 900 kbps হয়, তাই এক হাজার অ্যালবামের জন্য প্রায় 304 GB জায়গা লাগে। একটি 24 বিট, 96 kHz লাইব্রেরির আকার প্রায় 1,013 GB পর্যন্ত হতে পারে, যা কাগজে তালিকা করা যায় এমন একটি সংগ্রহের জন্য পুরো এক টেরাবাইট। ফোন-ফ্রেন্ডলি Opus কপিতে 128 kbps বিটরেটে সেই একই এক হাজার অ্যালবাম 43 GB-এর মধ্যে ধরে যায়। আপনার বর্তমান লাইব্রেরিতে du -sh /path/to/music চালান, কারণ স্টোরেজ প্ল্যান বেছে নেওয়ার সময় আপনার নিজস্ব গড় বিটরেটই একমাত্র গুরুত্বপূর্ণ সংখ্যা।

ব্যান্ডউইথ খরচের তুলনায় স্টোরেজ ছোট বিষয়। একটি 320 kbps স্ট্রিম মানে প্রতি সেকেন্ডে 40 কিলোবাইট, তাই এক ঘণ্টা শুনলে প্রায় 144 MB ডেটা খরচ হয়। মাসে একশ ঘণ্টা শুনলে প্রায় 14 GB খরচ হয়, যা কোনো VPS ট্রান্সফার লিমিটে প্রভাব ফেলে না। তবে ব্যতিক্রম হলো ফোনে প্রথমবার অফলাইন সিঙ্ক করা, যা এক সন্ধ্যায় কয়েক দশ গিগাবাইট ডেটা খরচ করতে পারে।

Storage tier নাকি compute tier?

একটি মিউজিক সার্ভার মূলত প্রচুর পরিমাণে 'cold data'-র ভাণ্ডার, যেখানে কম্পিউটেশনের কাজ প্রায় নেই বললেই চলে। প্রতি সেকেন্ডে 40 কিলোবাইট গতিতে ফাইল পড়ার সময় যেকোনো ডিস্ক অলস অবস্থায় থাকে, আর CPU কেবল লাইব্রেরি স্ক্যান বা ট্রান্সকোডিংয়ের সময় কাজ করে, যা সাধারণত খুব একটা প্রয়োজন হয় না। তাই compute plan-এর দ্রুতগতির NVMe এখানে কোনো বাড়তি সুবিধা দেয় না, বরং এর প্রতি গিগাবাইটের উচ্চমূল্যই FLAC ফাইল আপলোড করার ক্ষেত্রে বাধা হয়ে দাঁড়ায়। এই ধরনের ক্ষেত্রে একটি storage VPS সাধারণ VPS-এর চেয়ে ভালো, কারণ এই প্ল্যানগুলোর মূল্য নির্ধারণ করা হয় প্রতি টেরাবাইটের ভিত্তিতে, কোর-এর ভিত্তিতে নয়।

মেমোরির প্রয়োজনীয়তাও খুব সামান্য। Navidrome একটি ব্যক্তিগত লাইব্রেরি কয়েকশ মেগাবাইট র‍্যামেই চালাতে পারে এবং প্লেব্যাকের চেয়ে স্ক্যান করার সময় র‍্যামের ব্যবহার বেশি হয়। সার্ভারটিতে 1 GB বা 2 GB র‍্যাম বরাদ্দ করুন এবং বাজেটের বাকি অংশ ডিস্কের জন্য ব্যয় করুন।

Docker Compose দিয়ে Navidrome ইনস্টল করা

প্রথমে ডিরেক্টরিগুলো তৈরি করুন, যার মালিকানা সেই ইউজার আইডির অধীনে থাকবে যে ইউজার দিয়ে কন্টেইনারটি চলবে। আপনি যদি Compose-এর সাথে নতুন পরিচিত হন, তবে VPS-এ Docker Compose এই ফাইলে কী কী ধরে নেওয়া হয়েছে তা ব্যাখ্যা করে।

sudo install -d -m 755 -o 1000 -g 1000 /srv/navidrome /srv/music

docker-compose.yml ফাইলটি অন্য কোনো কিছুর সাথে না রেখে, তার নিজস্ব ডিরেক্টরিতে তৈরি করুন:

services:
  navidrome:
    image: deluan/navidrome:0.63.2
    user: "1000:1000"
    ports:
      - "127.0.0.1:4533:4533"
    restart: unless-stopped
    environment:
      ND_LOGLEVEL: "info"
      ND_SESSIONTIMEOUT: "24h"
      ND_SCANNER_SCHEDULE: "@every 24h"
      ND_BACKUP_PATH: "/data/backup"
      ND_BACKUP_SCHEDULE: "0 4 * * *"
      ND_BACKUP_COUNT: "7"
    volumes:
      - /srv/navidrome:/data
      - /srv/music:/music:ro

docker compose up -d
docker compose ps

docker compose ps কমান্ডটি চালানোর পর সার্ভিসটি 'restarting' না দেখিয়ে 'running' অবস্থায় থাকা উচিত। একটি কন্টেইনার যদি বারবার রিস্টার্ট হতে থাকে, তবে সেটি প্রায় সবসময়ই /srv/navidrome-এর পারমিশন সংক্রান্ত সমস্যা। আর docker compose logs navidrome ফাইলটির নাম নির্দেশ করে যেখানে কন্টেইনারটি লিখতে পারছে না।

এই ফাইলের চারটি বিষয় ব্যাখ্যা করা প্রয়োজন। পোর্টটি শুধুমাত্র 127.0.0.1-এ পাবলিশ করা হয়েছে, যাতে সার্ভারটি সরাসরি ইন্টারনেট থেকে 4453 পোর্টে না এসে শুধুমাত্র রিভার্স প্রক্সির মাধ্যমে অ্যাক্সেস করা যায়: Docker নিজস্ব ফায়ারওয়াল রুল তৈরি করে, তাই একটি সাধারণ 4533:4533 কমান্ড ব্যবহার করলেও সেটি উন্মুক্ত থেকে যায়, এমনকি যদি ufw-তে সবকিছু ডিনাই করা থাকে তবুও। মিউজিক ভলিউমটি শুধুমাত্র পড়ার জন্য (read-only) সেট করা হয়েছে, যাতে স্ক্যানার কোনো বাগের কারণে আপনার অরিজিনাল ফাইল ডিলিট করতে না পারে। ND_SCANNER_SCHEDULE ডিফল্টভাবে নিষ্ক্রিয় থাকে, এবং Navidrome 0.55 ভার্সনের আগের গাইডগুলোতে একে ND_SCANSCHEDULE বলা হতো, যে নামটি এখন আর নেই। তিনটি ব্যাকআপ সেটিংস বিল্ট-ইন ডাটাবেস ব্যাকআপ চালু করে, যার ওপর নিচের ব্যাকআপ সেকশনটি নির্ভরশীল।

আপনার মিউজিক সার্ভারে আপলোড করুন

rsync ব্যবহার করে লাইব্রেরি কপি করুন। সংযোগ বিচ্ছিন্ন হলে এটি নতুন করে শুরু না করে আগের অবস্থান থেকে কাজ চালিয়ে নিতে পারে।

rsync -av --info=progress2 ~/Music/ user@music.example.com:/srv/music/

rsync -avP /path/to/local/music/ user@your-vps-ip:/path/to/docker/music/

সোর্সের শেষে থাকা স্ল্যাশ (/) গুরুত্বপূর্ণ। এটি ছাড়া কপি করলে /srv/music/Music তৈরি হবে। কপি শেষ হলে ফাইলের মালিকানা ঠিক করুন:

sudo chown -R 1000:1000 /srv/music
id -u

chown -R 1000:1000 /path/to/docker/music/

কন্টেইনারটি 1000 ইউজার আইডি দিয়ে চলে এবং মাউন্টটি read-only মোডে থাকে, তাই প্রতিটি ফাইল এই আইডির মাধ্যমে পড়ার উপযোগী হতে হবে। যদি আপনার SSH অ্যাকাউন্টটি VPS-এ 1000 ইউজার আইডি না হয়, তবে কপি করা ফাইলগুলোর মালিকানা অন্য কারো কাছে থাকবে এবং স্ক্যান করার সময় কোনো ট্র্যাক পাওয়া যাবে না, ফলে ওয়েব ইন্টারফেসটি খালি দেখাবে। id -u কমান্ডটি আপনার বর্তমান ইউজার আইডি দেখাবে এবং Docker কন্টেইনারে PUID এবং PGID যেভাবে কাজ করে লিঙ্কে ম্যাপিং সম্পর্কে বিস্তারিত ব্যাখ্যা দেওয়া আছে।

একটি reverse proxy এবং TLS যাতে ফোনটি যেকোনো জায়গা থেকে কাজ করে

VPS-এর দিকে একটি DNS A record পয়েন্ট করুন, তারপর Caddy-কে তিনটি লাইন দিন:

music.example.com {
    reverse_proxy 127.0.0.1:4533
}

sudo systemctl reload caddy

Caddy প্রথম অনুরোধের সময় certificate-এর জন্য আবেদন করে। পোর্ট 80 এবং 443 উভয়ই খোলা থাকতে হবে, কারণ ACME (automatic certificate management environment) চ্যালেঞ্জের উত্তর পোর্ট 80-এ দেওয়া হয়। Nginx-এর ক্ষেত্রে, location ব্লকে proxy_buffering off; যোগ করুন: Navidrome একটি দীর্ঘস্থায়ী সংযোগের মাধ্যমে ওয়েব ইন্টারফেসে প্রগ্রেস ইভেন্ট পাঠায়, এবং buffering চালু থাকলে ইন্টারফেসটি এমন একটি উত্তরের জন্য অপেক্ষা করে যা Nginx আটকে রেখেছে। যদি আপনি এটিকে নিজস্ব subdomain-এর পরিবর্তে /music-এর মতো কোনো path-এর অধীনে পরিবেশন করেন, তবে ND_BASEURL-কে একই path-এ সেট করুন, অন্যথায় ইন্টারফেসটি খালি পৃষ্ঠা হিসেবে লোড হবে। তিনটি সাধারণ প্রক্সির তুলনা Nginx, Caddy and Traefik on a VPS-এ দেওয়া হয়েছে।

সাইটটি খুলুন এবং প্রথম অ্যাকাউন্টটি তৈরি করুন। এখানে কোনো ডিফল্ট পাসওয়ার্ড নেই, এবং প্রথম ভিজিটরকে অ্যাডমিন ইউজার তৈরি করতে বলা হয়, তাই কাউকে ঠিকানাটি দেওয়ার আগেই এটি করুন। তারপর ফোন ক্লায়েন্ট যে সঠিক path ব্যবহার করে তা পরীক্ষা করুন:

SALT=$(openssl rand -hex 6)
TOKEN=$(printf '%s%s' 'YOUR_PASSWORD' "$SALT" | md5sum | cut -d' ' -f1)
curl -s "https://music.example.com/rest/ping.view?u=YOUR_USER&t=$TOKEN&s=$SALT&v=1.16.1&c=curl&f=json"

একটি সঠিক উত্তরের শুরুতে {"subsonic-response":{"status":"ok" থাকে এবং সার্ভারের ধরন হিসেবে navidrome-এর নাম উল্লেখ থাকে। যদি বডিতে "status":"failed" এবং error code 40 থাকে, তবে বুঝতে হবে প্রক্সি ঠিক আছে কিন্তু credentials ভুল। এই ধাপে কোনো certificate error দেখা দিলে তা সবার আগে সমাধান করুন, কারণ বেশিরভাগ ফোন ক্লায়েন্ট ভুল certificate প্রত্যাখ্যান করে এবং ব্যবহারকারীকে কোনো অর্থবহ বার্তা দেয় না।

প্রথম স্ক্যানের পর আপনার লাইব্রেরি কেন অগোছালো দেখায়

Navidrome ফোল্ডারের পরিবর্তে ট্যাগ (tags) অনুযায়ী ব্রাউজ করে, তাই ট্যাগগুলোই নির্ধারণ করে আপনি কী দেখতে পাবেন। কোনো ট্র্যাকে যদি album artist ট্যাগ না থাকে, তবে সেটি track artist-এর অধীনে জমা হয়। এই কারণেই বিভিন্ন শিল্পীর সমন্বয়ে তৈরি একটি কম্পাইলেশন অ্যালবাম, প্রতিটি শিল্পীর নামে আলাদা আলাদা বিশটি অ্যালবামে বিভক্ত হয়ে যায়। এটি Navidrome-এ নয়, বরং ফাইলগুলোতে ঠিক করুন: MusicBrainz Picard এবং beets উভয়ই MusicBrainz ডাটাবেসে অ্যালবাম খুঁজে বের করে এবং সঠিক স্ট্যান্ডার্ড ট্যাগগুলো ফাইলে লিখে দেয়।

Navidrome একটি multi artist ট্যাগকে আলাদা আলাদা শিল্পীতে বিভক্ত করে ফেলে। ফলে যে ব্যান্ডের নামে বিভাজক (separator) থাকে, সেগুলো ভুলবশত আলাদা হয়ে যায়; AC/DC হলো এর একটি সাধারণ উদাহরণ যা সবাই সম্মুখীন হয়। ND_SCANNER_ARTISTSPLITEXCEPTIONS-এ সেই নামগুলো রাখা হয় যা কখনোই বিভক্ত করা যাবে না।

নতুন ফাইল সার্ভারে আসার কয়েক সেকেন্ডের মধ্যেই ফাইল ওয়াচার (file watcher) সেগুলো শনাক্ত করে। এই ওয়াচারটি কার্নেল চেঞ্জ নোটিফিকেশনের ওপর নির্ভর করে, কিন্তু অন্য মেশিন থেকে মাউন্ট করা নেটওয়ার্ক শেয়ারে লেখা ফাইলের ক্ষেত্রে এই নোটিফিকেশনগুলো কাজ করে না। তাই এই ধরনের সেটআপে লাইব্রেরি আপডেট রাখার জন্য পর্যায়ক্রমিক ND_SCANNER_SCHEDULE ব্যবহার করতে হয়। একটি পূর্ণাঙ্গ রিস্ক্যান (full rescan) প্রতিটি ফাইলের ট্যাগ পুনরায় পড়ে, যা বড় লাইব্রেরির ক্ষেত্রে বেশ ধীরগতির। আর এই কারণেই নিচের ডাটাবেসটি সুরক্ষিত রাখা জরুরি।

ব্যবহারকারী, প্লেলিস্ট এবং শেয়ারিং

একজন অ্যাডমিন ওয়েব ইন্টারফেস থেকে অন্যান্য অ্যাকাউন্ট তৈরি করেন, এখানে নিজে থেকে সাইন-আপ করার কোনো ব্যবস্থা নেই। প্রতিটি ব্যবহারকারীর জন্য আলাদা প্লে-কাউন্ট, প্লেলিস্ট, ফেভারিট এবং রেটিং থাকে, ফলে পরিবারের সবার রুচি একটি প্রোফাইলে মিশে যায় না।

প্লেলিস্ট দুইভাবে তৈরি হতে পারে। ক্লায়েন্টে তৈরি করা প্লেলিস্ট ডাটাবেসে সংরক্ষিত থাকে। লাইব্রেরি ফোল্ডারে রাখা একটি .m3u ফাইল স্ক্যান করার সময় ইমপোর্ট করা হয়, যা ডেস্কটপ প্লেয়ার থেকে প্লেলিস্ট নিয়ে আসার সহজ উপায়। স্মার্ট প্লেলিস্টগুলো হলো .nsp ফাইল, যা ছোট JSON রুল ফাইল এবং একইভাবে ইমপোর্ট করা হয়। লাইব্রেরিতে পরিবর্তন আসার সাথে সাথে এগুলো নিজে থেকেই আপডেট হয়।

জুলাই 2026-এ রিলিজ হওয়া 0.63.0 ভার্সন থেকে শেয়ারিং সুবিধাটি ডিফল্টভাবে চালু থাকে। এটি ব্যবহারকারীকে কোনো অ্যালবামের জন্য একটি পাবলিক লিঙ্ক তৈরি করতে দেয়, যা লগইন ছাড়াই যে কেউ খুলতে পারে। আপনার পুরো লাইব্রেরি ধারণকারী সার্ভারের ক্ষেত্রে এটি হয়তো আপনি চাইবেন না, সেক্ষেত্রে ND_ENABLESHARING-কে false-এ সেট করলে এই সুবিধাটি বন্ধ হয়ে যাবে।

মিউজিক ফাইল থেকে আলাদাভাবে ডাটাবেস ব্যাকআপ নিন

Navidrome-এর নিজস্ব ব্যাকআপ শুধুমাত্র ডাটাবেস কভার করে। ডকুমেন্টেশনে এটি স্পষ্টভাবে বলা আছে: ব্যাকআপ প্রক্রিয়াটি শুধুমাত্র ডাটাবেস ব্যাকআপ নেয়, যার অর্থ ব্যবহারকারী, প্লে কাউন্ট এবং অন্যান্য তথ্য সংরক্ষিত হয়, কিন্তু মিউজিক বা কনফিগারেশন ফাইল ব্যাকআপ হয় না। এই বিভাজনটি মনে রাখা জরুরি, কারণ এই দুই ধরনের ডেটা ভিন্নভাবে নষ্ট হতে পারে। মিউজিক ফাইলগুলো যে ডিস্ক থেকে রিপ (rip) করেছিলেন, সেখান থেকে পুনরায় কপি করা সম্ভব। কিন্তু প্লে কাউন্ট, রেটিং, ফেভারিট এবং প্লেলিস্ট অন্য কোথাও থাকে না এবং একটি রিস্ক্যান (rescan) করলে এগুলো ফিরে আসে না।

Compose ফাইলটি ইতিমধ্যে প্রতি রাতে /data/backup-এ একটি কপি তৈরি করে এবং সাতটি কপি সংরক্ষণ করে। আপগ্রেড করার আগে হাতে একটি কপি নিয়ে নিন:

sudo docker compose run --rm navidrome backup create

রিস্টোর করার সময় বর্তমান ডাটাবেস মুছে ফেলে ব্যাকআপটি সেখানে কপি করা হয়, তাই Navidrome বন্ধ থাকা অবস্থায় এটি চালাতে হবে। লাইভ সার্ভারে রিস্টোর করা নিরাপদ নয়।

এই ফাইলগুলো একই VPS-এ থাকে, তাই VPS নষ্ট হয়ে গেলে এগুলো আর পাওয়া যাবে না। একটি নির্দিষ্ট সময়সূচী অনুযায়ী /srv/navidrome-কে অন্য কোনো মেশিনে বা অবজেক্ট স্টোরেজে পুশ করুন, যার জন্য restic and BorgBackup তৈরি করা হয়েছে। পুরো ডিরেক্টরিটি ছোট, সাধারণত এক গিগাবাইটের অনেক নিচে, তাই প্রতিদিন একটি এনক্রিপ্টেড কপি সার্ভারের বাইরে রাখলে খরচ প্রায় নেই বললেই চলে, কিন্তু রিস্ক্যান করে যা ফিরে পাওয়া সম্ভব নয়, তা এতে সুরক্ষিত থাকে।

FAQ

আমার কি VPS-এ মিউজিক ট্রান্সকোড করার প্রয়োজন আছে?

প্রায় কখনোই না। ফোন এবং ব্রাউজারগুলো নিজেরাই MP3, AAC, Opus এবং FLAC ডিকোড করতে পারে, তাই সার্ভার ফাইলটিকে যেমন আছে তেমনই পাঠিয়ে দেয় এবং এতে CPU-এর ব্যবহার প্রায় শূন্য থাকে। তবে একটি ক্ষেত্রে এটি চালু করা যেতে পারে: মোবাইল ডেটার মাধ্যমে FLAC লাইব্রেরি স্ট্রিম করার সময়। সেক্ষেত্রে প্রায় 900 kbps থেকে Opus ফরম্যাটে 128 kbps-এ রূপান্তর করলে ডেটার ব্যবহার প্রায় সাত গুণ কমে যায়। Navidrome প্রতিটি ইউজার এবং প্লেয়ারের জন্য আলাদাভাবে এটি করতে পারে এবং আপনি নিজে চালু না করা পর্যন্ত এটি বন্ধ থাকে।

আমার ফোনের অ্যাপ কেন অফলাইন শোনার জন্য মিউজিক ডাউনলোড করতে পারছে না?

কারণ অফলাইন স্টোরেজ একটি ক্লায়েন্ট ফিচার, সার্ভার ফিচার নয়। Subsonic API যেকোনো ক্লায়েন্টকে পুরো ফাইলটি নিয়ে আসার সুযোগ দেয়, কিন্তু ফোনে কপি রাখা হবে কি না তা অ্যাপ নির্ধারণ করে। navidrome.org/apps-এ ক্লায়েন্ট ডিরেক্টরি দেখুন এবং এমন একটি অ্যাপ বেছে নিন যার বর্ণনায় অফলাইন ডাউনলোড বা ক্যাশিংয়ের উল্লেখ আছে। কিছু ক্লায়েন্ট শুধুমাত্র আপনার প্লে করা গানগুলো ক্যাশ করে, যা ভ্রমণের আগে পুরো অ্যালবাম সিঙ্ক করার মতো নয়।

স্ক্যান করার পর একটি অ্যালবাম কেন কয়েকটি অ্যালবামে বিভক্ত হয়ে গেল?

ট্র্যাকগুলোতে 'album artist' ট্যাগ অনুপস্থিত অথবা অসামঞ্জস্যপূর্ণ। Navidrome ফোল্ডারের পরিবর্তে ট্যাগের ভিত্তিতে গান সাজায়। তাই বারোটি ট্র্যাকের যদি বারোটি ভিন্ন আর্টিস্ট ভ্যালু থাকে এবং কোনো সাধারণ 'album artist' ভ্যালু না থাকে, তবে সেগুলোকে বারোটি আলাদা অ্যালবাম হিসেবে দেখাবে। অ্যালবামের প্রতিটি ট্র্যাকে 'album artist' ট্যাগ সেট করুন (কম্পাইলেশনের ক্ষেত্রে সাধারণত 'Various Artists' ব্যবহার করুন) এবং তারপর পুনরায় স্ক্যান করুন। MusicBrainz Picard বা beets ব্যবহার করে পুরো ফোল্ডারের জন্য এটি একসাথে করা সম্ভব।

সেলফ-হোস্টেড মিউজিক স্ট্রিমিং কি Spotify-এর বিকল্প?

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