VPS पर अपना खुद का music streaming server कैसे बनाएं

VPS पर self-hosted music streaming आपको क्या प्रदान करती है

VPS पर self-hosted music streaming का अर्थ है कि आप स्वयं player चलाते हैं और संगीत आप उपलब्ध कराते हैं। सर्वर उन फाइलों को रखता है जिन्हें आप पहले से ही own करते हैं, और कोई भी फोन सामान्य login के माध्यम से internet पर उन तक पहुँच सकता है। शुरू करने से पहले इस सौदे के बारे में ईमानदार रहें: यह streaming service के player को बदलता है, उसके catalogue को नहीं। आपकी library में तब तक कुछ भी नया नहीं आता जब तक आप उसे खरीदते या rip नहीं करते, और file को सर्वर पर copy नहीं करते।

Audio, video की तुलना में सर्वर के लिए बहुत हल्का होता है। फाइलें छोटी होती हैं, फोन बिना किसी सहायता के हर सामान्य format को decode कर लेते हैं, और एक listener video call की तुलना में कम bandwidth का उपयोग करता है। यहाँ CPU सबसे आसान हिस्सा है। Disk space ही वास्तविक बाधा है। अन्य दो चीजें जो यह तय करती हैं कि यह काम करेगा या नहीं, वे हैं आपके tags की गुणवत्ता और क्या आपका phone app offline उपयोग के लिए संगीत download कर सकता है।

कौन सा म्यूजिक सर्वर: Navidrome, Jellyfin, या Funkwhale?

Navidrome डिफ़ॉल्ट विकल्प है यदि आप केवल ऑडियो में रुचि रखते हैं। यह एक कंटेनर में एक Go बाइनरी है, और यह अपनी स्थिति को एक एकल SQLite डेटाबेस में रखता है। यह Subsonic API का उत्तर देता है, जो कि उन सभी थर्ड-पार्टी फोन ऐप्स के अस्तित्व का मुख्य कारण है। अगस्त 2026 में संस्करण 0.63.2 वर्तमान था। प्रोजेक्ट इसे Raspberry Pi Zero जैसे छोटे हार्डवेयर पर भी अच्छी तरह चलने वाला बताता है, इसलिए सर्वर सॉफ़्टवेयर वह हिस्सा नहीं है जिसके लिए आप भुगतान करेंगे।

Jellyfin का उपयोग करना तब सार्थक है यदि आप पहले से ही Jellyfin को मीडिया सर्वर के रूप में VPS पर वीडियो के लिए चला रहे हैं। इसकी म्यूजिक लाइब्रेरी काम करती है, और Finamp एंड्रॉइड और iOS के लिए एक Jellyfin म्यूजिक ऐप है जो ऑफ़लाइन सुनने के लिए ट्रैक डाउनलोड करता है। इसकी सीमा API है। Jellyfin में कोई इन-बिल्ट Subsonic एंडपॉइंट नहीं है, और जिस कम्युनिटी प्लगइन ने इसे जोड़ा था, उसे 2022 में अपडेट करना बंद कर दिया गया था, इसलिए Subsonic ऐप इकोसिस्टम इसके लिए बंद है। आप इसके बजाय उन ऐप्स का उपयोग करते हैं जो Jellyfin के अपने API का उपयोग करते हैं, और ऐसे ऐप्स की संख्या कम है।

Funkwhale फेडरेटेड विकल्प है, और संस्करण 2.0 मार्च 2026 में रिलीज़ किया गया था। Funkwhale सर्वर को पॉड (pod) कहा जाता है, पॉड्स ActivityPub (Mastodon के पीछे का प्रोटोकॉल) पर फेडरेट होते हैं, और एक पॉड का उपयोगकर्ता दूसरे पॉड पर पब्लिक लाइब्रेरी को फॉलो कर सकता है। यह Subsonic API के एक हिस्से का भी उत्तर देता है, जिसमें एक अंतर जानने योग्य है: प्रत्येक उपयोगकर्ता अपनी सेटिंग्स में एक अलग Subsonic पासवर्ड सेट करता है, क्योंकि Subsonic प्रोटोकॉल एक ऐसे पासवर्ड की अपेक्षा करता है जिसे सर्वर पढ़ सके। Funkwhale का इंस्टॉलेशन भारी है, क्योंकि इसे वेब ऐप के अलावा PostgreSQL और एक टास्क क्यू (task queue) की आवश्यकता होती है।

Navidrome चुनें जब तक कि आप फेडरेशन न चाहते हों, या जब तक Jellyfin पहले से चल न रहा हो। इस गाइड का शेष भाग Docker के साथ Navidrome को सेटअप करता है।

Subsonic API यह कैसे तय करती है कि आपको कौन सा फोन ऐप मिलता है

Subsonic एक म्यूजिक सर्वर था जिसका HTTP API self-hosted ऑडियो के लिए एक सामान्य भाषा बन गया, और OpenSubsonic वह कम्युनिटी प्रोजेक्ट है जो इसे लगातार विकसित कर रहा है। यही इतिहास कारण है कि आपके फोन पर कई विकल्प मौजूद हैं। Navidrome अपना कोई मोबाइल ऐप नहीं देता और उसे इसकी आवश्यकता भी नहीं है, क्योंकि कोई भी Subsonic client सर्वर एड्रेस और आपके अकाउंट विवरण के साथ लॉगिन कर सकता है।

यह ऑफलाइन सिंक (offline sync) के लिए सबसे महत्वपूर्ण है, जो वह फीचर है जो यह तय करता है कि आपका सेटअप दैनिक उपयोग में टिकेगा या नहीं। टनल में मौजूद फोन आपके सर्वर तक नहीं पहुँच सकता, इसलिए client को फाइलें पहले ही लोकल स्टोरेज में कॉपी कर लेनी चाहिए। हर client स्ट्रीमिंग करता है। केवल कुछ ही डाउनलोड की सुविधा देते हैं। navidrome.org/apps पर मौजूद client डायरेक्टरी बताती है कि कौन से ऐप ऐसा करते हैं, और दोनों प्लेटफॉर्म पर विकल्प व्यापक हैं: Android पर Substreamer और Ultrasonic, iOS पर Amperfy और play:Sub। कई बेहतरीन clients पेड ऐप्स हैं, और Android पर 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 सेकंड का मानें। बिटरेट (kbps में) को 2,700 से गुणा करें और फिर 8,000 से विभाजित करें, जिससे परिणाम मेगाबाइट (MB) में प्राप्त होगा। 320 kbps पर एक एल्बम के लिए 108 MB की आवश्यकता होती है, इसलिए एक हजार एल्बम के लिए लगभग 108 GB स्टोरेज चाहिए।

लॉसलेस (Lossless) फॉर्मेट के मामले में यह उत्तर बदल जाता है। सामान्य सामग्री पर CD क्वालिटी FLAC का औसत लगभग 900 kbps होता है, इसलिए एक हजार एल्बम के लिए लगभग 304 GB की आवश्यकता होगी। 24 bit, 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?

Music server डेटा का एक बड़ा संग्रह है, जिसमें न के बराबर computation की आवश्यकता होती है। 40 kilobytes प्रति सेकंड की गति से फाइल पढ़ने पर कोई भी disk खाली रहती है, और CPU केवल library scan या transcoding के दौरान काम करता है, जिसकी आपको शायद ही कभी जरूरत पड़े। इसलिए, compute plan में मिलने वाली तेज NVMe यहाँ कोई लाभ नहीं देती, जबकि इसकी प्रति gigabyte कीमत ही वह बाधा है जो आपको FLAC फाइलों को upload करने से रोकती है। यह वह स्थिति है जहाँ a storage VPS एक सामान्य VPS से बेहतर होता है, क्योंकि उन plans की कीमत core के बजाय terabyte के आधार पर तय की जाती है।

Memory की आवश्यकता कम है। Navidrome कुछ सौ megabytes में एक व्यक्तिगत library को serve कर सकता है, और playback के बजाय scan के दौरान ही सबसे अधिक memory का उपयोग होता है। सर्वर को 1 GB या 2 GB RAM दें और बजट का बाकी हिस्सा disk पर खर्च करें।

Docker Compose के साथ Navidrome इंस्टॉल करें

सबसे पहले वे डायरेक्टरीज़ बनाएँ, जिनका स्वामित्व उस user id के पास हो जिसके तहत container चलेगा। यदि आप 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 को यह दिखाना चाहिए कि service चल रही है, न कि restart हो रही है। जो container लूप में restart होता है, वह लगभग हमेशा /srv/navidrome पर अनुमतियों (permissions) की समस्या होती है, और docker compose logs navidrome उस फाइल का नाम बताता है जिसे वह लिख नहीं सका।

उस फाइल में चार विवरण स्पष्ट करने योग्य हैं। port को केवल 127.0.0.1 पर प्रकाशित किया गया है, इसलिए सर्वर reverse proxy के माध्यम से पहुँच योग्य है न कि खुले इंटरनेट से port 4533 पर: Docker अपने स्वयं के firewall नियम लिखता है, इसलिए एक साधारण 4533:4533 उस बॉक्स पर भी exposed रहता है जहाँ ufw सब कुछ denied रिपोर्ट करता है। music volume केवल पढ़ने के लिए (read-only) है, जिसका अर्थ है कि scanner का कोई बग आपकी एकमात्र कॉपी को हटा नहीं सकता है। ND_SCANNER_SCHEDULE डिफ़ॉल्ट रूप से अक्षम है, और Navidrome 0.55 से पहले लिखे गए गाइड इसे ND_SCANSCHEDULE कहते हैं, जो अब मौजूद नहीं है। तीन backup सेटिंग्स इन-बिल्ट डेटाबेस बैकअप को चालू करती हैं जिस पर नीचे दिया गया बैकअप सेक्शन निर्भर करता है।

अपना संगीत सर्वर पर लाएं

अपनी लाइब्रेरी को rsync के साथ कॉपी करें। यदि कनेक्शन टूटता है, तो यह फिर से शुरू करने के बजाय वहीं से आगे बढ़ता है।

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

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

स्रोत (source) के अंत में लगा स्लैश (trailing slash) महत्वपूर्ण है। इसके बिना आपको /srv/music/Music प्राप्त होगा। जब कॉपी पूरी हो जाए, तो ओनरशिप ठीक करें:

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

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

कंटेनर user id 1000 के रूप में चलता है और माउंट read-only होता है, इसलिए प्रत्येक फाइल का उस id द्वारा पढ़ा जाना आवश्यक है। यदि आपका SSH अकाउंट VPS पर uid 1000 नहीं है, तो कॉपी की गई फाइलें किसी और के स्वामित्व में होंगी और स्कैन में शून्य ट्रैक मिलेंगे, जबकि वेब इंटरफेस खाली दिखाई देगा। id -u आपकी वास्तविक id प्रिंट करता है, और 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 पहली request पर certificate के लिए अनुरोध करता है। Ports 80 और 443 दोनों का खुला होना आवश्यक है, क्योंकि ACME (automatic certificate management environment) challenge का उत्तर port 80 पर दिया जाता है। Nginx पर, location block में proxy_buffering off; जोड़ें: Navidrome एक long-lived connection के माध्यम से web interface पर progress events भेजता है, और buffering चालू होने पर, interface उस response का इंतजार करता रहता है जिसे nginx ने रोक रखा है। यदि आप इसे अपने subdomain के बजाय /music जैसे path के अंतर्गत serve करते हैं, तो ND_BASEURL को उसी path पर सेट करें, अन्यथा interface एक blank page के रूप में लोड होगा। तीन सामान्य proxies की तुलना Nginx, Caddy and Traefik on a VPS में की गई है।

साइट खोलें और पहला account बनाएँ। इसमें कोई default password नहीं होता है, और पहले visitor को admin user बनाने के लिए कहा जाता है, इसलिए किसी को भी पता बताने से पहले यह काम कर लें। फिर उस सटीक path का परीक्षण करें जिसका उपयोग phone client करता है:

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" से शुरू होता है और server type के रूप में navidrome का नाम बताता है। यदि body में "status":"failed" और error code 40 शामिल है, तो इसका मतलब है कि proxy ठीक है और credentials गलत हैं। इस चरण पर आने वाली certificate error को सबसे पहले ठीक करें, क्योंकि अधिकांश phone clients एक खराब certificate को ऐसी error message के साथ अस्वीकार कर देते हैं जो user को कोई जानकारी नहीं देती है।

पहली स्कैन के बाद आपकी लाइब्रेरी गलत क्यों दिखती है

Navidrome फोल्डर के बजाय टैग के आधार पर ब्राउज़ करता है, इसलिए टैग ही तय करते हैं कि आपको क्या दिखाई देगा। जिस ट्रैक में album artist टैग नहीं होता, उसे उसके track artist के अंतर्गत फाइल किया जाता है। यही कारण है कि अलग-अलग कलाकारों वाले एक संकलन (compilation) के बीस अलग-अलग एल्बम बन जाते हैं, जिनमें हर एक में केवल एक ट्रैक होता है। इसे Navidrome में नहीं, बल्कि फाइलों में ठीक करें: MusicBrainz Picard और beets दोनों ही MusicBrainz डेटाबेस में एल्बम को खोजते हैं और मानक टैग वापस लिखते हैं।

Navidrome एक multi artist टैग को अलग-अलग कलाकारों में विभाजित भी करता है, इसलिए जिस बैंड के नाम में विभाजक (separator) होता है, वह गलती से विभाजित हो जाता है; AC/DC इसका वह उदाहरण है जिसका सामना हर कोई करता है। ND_SCANNER_ARTISTSPLITEXCEPTIONS में वे नाम रखे जाते हैं जिन्हें कभी विभाजित नहीं किया जाना चाहिए।

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

उपयोगकर्ता, प्लेलिस्ट और शेयरिंग

एक एडमिन वेब इंटरफेस में अन्य अकाउंट बनाता है, और इसमें सेल्फ-साइनअप की सुविधा नहीं है। प्रत्येक उपयोगकर्ता को अलग प्ले काउंट, प्लेलिस्ट, फेवरेट्स और रेटिंग्स मिलती हैं, ताकि एक ही घर के सदस्यों का टेस्ट प्रोफाइल आपस में न मिले।

प्लेलिस्ट दो तरह से आती हैं। क्लाइंट में बनाई गई प्लेलिस्ट डेटाबेस में रहती है। लाइब्रेरी फोल्डर में डाली गई एक .m3u फाइल को स्कैन के दौरान इम्पोर्ट किया जाता है, जो डेस्कटॉप प्लेयर से प्लेलिस्ट को ट्रांसफर करने का आसान तरीका है। स्मार्ट प्लेलिस्ट .nsp फाइलें होती हैं, जो छोटी JSON रूल फाइलें हैं और उसी तरह इम्पोर्ट की जाती हैं, और लाइब्रेरी में बदलाव होने पर वे खुद को अपडेट कर लेती हैं।

वर्जन 0.63.0 से शेयरिंग डिफ़ॉल्ट रूप से इनेबल है, जिसे जुलाई 2026 में रिलीज किया गया था। यह किसी उपयोगकर्ता को किसी एल्बम का पब्लिक लिंक बनाने की अनुमति देता है जिसे कोई भी बिना लॉग इन किए खोल सकता है। यदि सर्वर पर आपकी पूरी लाइब्रेरी मौजूद है, तो शायद आप ऐसा न चाहें, और ND_ENABLESHARING को false पर सेट करने से यह सुविधा बंद हो जाती है।

म्यूजिक फाइलों से अलग डेटाबेस का बैकअप लें

Navidrome का अपना बैकअप केवल डेटाबेस को कवर करता है। डॉक्यूमेंटेशन इस बारे में स्पष्ट है: बैकअप प्रक्रिया केवल डेटाबेस का बैकअप लेती है, जिसका अर्थ है कि इसमें यूजर्स, प्ले काउंट और अन्य डेटा शामिल हैं, लेकिन यह म्यूजिक या कॉन्फ़िगरेशन का बैकअप नहीं लेती है। इस विभाजन को समझना सही तरीका है, क्योंकि दोनों हिस्सों के विफल होने के कारण अलग-अलग होते हैं। म्यूजिक फाइलों को उस डिस्क से दोबारा कॉपी किया जा सकता है जिससे आपने उन्हें रिप किया था। प्ले काउंट, रेटिंग, पसंदीदा और प्लेलिस्ट कहीं और मौजूद नहीं होते हैं, और एक रीस्कैन उन्हें वापस नहीं ला सकता है।

Compose फाइल पहले से ही /data/backup में एक nightly कॉपी लिखती है और उनमें से सात को सुरक्षित रखती है। अपग्रेड से पहले हाथ से एक कॉपी ले लें:

sudo docker compose run --rm navidrome backup create

रिस्टोर करने से वर्तमान डेटाबेस मिट जाता है और बैकअप को उसकी जगह कॉपी कर दिया जाता है, और इसे Navidrome के बंद रहने के दौरान ही चलना चाहिए। लाइव सर्वर पर रिस्टोर करने की प्रक्रिया सुरक्षित नहीं होती है।

ये फाइलें अभी भी उसी VPS पर मौजूद हैं, इसलिए वे VPS के खराब होने पर सुरक्षित नहीं रहेंगी। /srv/navidrome को एक शेड्यूल पर किसी दूसरी मशीन या ऑब्जेक्ट स्टोरेज पर पुश करें, जो कि वह कार्य है जिसके लिए restic and BorgBackup बनाए गए हैं। पूरी डायरेक्टरी छोटी है, आमतौर पर एक गीगाबाइट से काफी कम, इसलिए बॉक्स से बाहर एक दैनिक एन्क्रिप्टेड कॉपी की लागत लगभग शून्य है और यह वह सब कुछ वापस दिला देती है जिसे रीस्कैन नहीं कर सकता।

FAQ

क्या मुझे VPS पर संगीत को transcode करने की आवश्यकता है?

लगभग कभी नहीं। फोन और ब्राउज़र MP3, AAC, Opus और FLAC को स्वयं decode कर लेते हैं, इसलिए सर्वर फ़ाइल को वैसा ही भेजता है और CPU का उपयोग न के बराबर होता है। एक स्थिति है जहाँ इसे सक्षम करना उचित है: मोबाइल डेटा पर FLAC लाइब्रेरी को स्ट्रीम करना, जहाँ लगभग 900 kbps से Opus में 128 kbps तक convert करने पर डेटा का उपयोग लगभग सात गुना कम हो जाता है। Navidrome इसे प्रति उपयोगकर्ता और प्रति प्लेयर कर सकता है, और जब तक आप इसे चालू नहीं करते, यह बंद रहता है।

मेरा फोन ऐप ऑफ़लाइन सुनने के लिए संगीत डाउनलोड क्यों नहीं कर पा रहा है?

क्योंकि ऑफ़लाइन स्टोरेज एक क्लाइंट फीचर है, सर्वर फीचर नहीं। Subsonic API किसी भी क्लाइंट को पूरी फ़ाइल लाने की अनुमति देता है, लेकिन ऐप यह तय करता है कि फोन पर कॉपी रखनी है या नहीं। navidrome.org/apps पर क्लाइंट डायरेक्टरी देखें और ऐसा क्लाइंट चुनें जिसके विवरण में ऑफ़लाइन डाउनलोड या कैशिंग का उल्लेख हो। कुछ क्लाइंट केवल वही कैश करते हैं जो आपने पहले ही चला लिया है, जो यात्रा से पहले एल्बम को सिंक करने जैसा नहीं है।

स्कैन के बाद एक एल्बम कई एल्बमों में क्यों विभाजित हो गया?

ट्रैक में album artist टैग गायब है या सुसंगत नहीं है। Navidrome फ़ोल्डर के बजाय टैग के आधार पर समूह बनाता है, इसलिए बारह अलग-अलग आर्टिस्ट वैल्यू वाले और बिना किसी साझा album artist वैल्यू वाले बारह ट्रैक बारह अलग-अलग एल्बम की तरह दिखते हैं। एल्बम के हर ट्रैक पर album artist टैग सेट करें, संकलन (compilation) के लिए आमतौर पर इसे Various Artists पर रखें, फिर इसे दोबारा स्कैन होने दें। MusicBrainz Picard या beets इसे एक पूरे फ़ोल्डर के लिए एक साथ कर देंगे।

क्या self-hosted संगीत स्ट्रीमिंग Spotify की जगह ले सकती है?

यह प्लेयर और लाइब्रेरी की जगह लेती है, कैटलॉग की नहीं। आपको हर डिवाइस पर अपना खुद का कलेक्शन मिलता है, उन प्लेलिस्ट और प्ले काउंट के साथ जिन्हें कोई भी लाइसेंसिंग बदलाव आपसे छीन नहीं सकता। आपको नए रिलीज़ नहीं मिलते, और आपको अन्य लोगों के सुनने के आधार पर बनी सिफारिशें (recommendations) नहीं मिलतीं। जो लोग इसे चलाते हैं, उनमें से अधिकांश अपना संगीत खरीदते हैं और खोज (discovery) के लिए एक सस्ता स्ट्रीमिंग अकाउंट रखते हैं।