VPS-ல் சொந்தமாக music streaming server அமைப்பது எப்படி?

VPS-ல் self-hosted music streaming செய்வதன் நன்மைகள்

VPS-ல் self-hosted music streaming என்பது, நீங்களே music player-ஐ இயக்கி, நீங்களே பாடல்களை வழங்குவதைக் குறிக்கும். உங்களிடம் ஏற்கனவே உள்ள கோப்புகளை server-ல் சேமித்து வைக்கலாம். இணையம் வழியாக எந்தவொரு phone-லிருந்தும் சாதாரண login மூலம் அவற்றை அணுகலாம். தொடங்குவதற்கு முன் ஒரு விஷயத்தை கவனத்தில் கொள்ளவும்: இது streaming service-ன் player-க்கு மாற்றாக இருக்குமே தவிர, அதன் catalogue-க்கு மாற்றாக இருக்காது. நீங்கள் ஒரு பாடலை வாங்கி அல்லது rip செய்து, அந்த கோப்பை server-க்கு நகர்த்தும் வரை, உங்கள் library-ல் புதிய பாடல்கள் எதுவும் தோன்றாது.

வீடியோவை விட ஆடியோவிற்கு server-ன் சுமை மிகக் குறைவு. கோப்புகள் அளவில் சிறியவை, எந்தவொரு பொதுவான format-ஐயும் phone-களே நேரடியாக decode செய்துவிடும், மேலும் ஒரு பயனர் கேட்கும் ஆடியோ, ஒரு video call-ஐ விடக் குறைவான bandwidth-ஐயே பயன்படுத்தும். இதில் CPU பயன்பாடு மிக எளிது. Disk space மட்டுமே உண்மையான சவாலாக இருக்கும். இது சரியாகச் செயல்படுமா என்பதைத் தீர்மானிக்கும் மற்ற இரண்டு காரணிகள்: உங்கள் கோப்புகளின் tags தரம் மற்றும் உங்கள் phone app-ல் offline பயன்பாட்டிற்காகப் பாடல்களைத் தரவிறக்கம் செய்யும் வசதி உள்ளதா என்பதுதான்.

எந்த music server-ஐத் தேர்வு செய்வது: Navidrome, Jellyfin, அல்லது Funkwhale?

நீங்கள் ஆடியோவை மட்டுமே முக்கியமாகக் கருதினால், Navidrome சிறந்த தேர்வாகும். இது ஒரே ஒரு Go binary-ஆக ஒரு container-ல் இயங்குகிறது, மேலும் அதன் தரவுகளை ஒரே ஒரு SQLite database-ல் சேமிக்கிறது. இது Subsonic API-க்கு ஆதரவளிக்கிறது; இதனால்தான் பல மூன்றாம் தரப்பு மொபைல் செயலிகள் இதனுடன் இணக்கமாகச் செயல்படுகின்றன. ஆகஸ்ட் 2026-ல் இதன் 0.63.2 பதிப்பு புழக்கத்தில் இருந்தது. Raspberry Pi Zero போன்ற குறைந்த திறன் கொண்ட வன்பொருளிலும் இது சிறப்பாக இயங்கும் என்று இந்தத் திட்டம் குறிப்பிடுகிறது, எனவே server மென்பொருளுக்காக நீங்கள் கட்டணம் செலுத்த வேண்டியதில்லை.

நீங்கள் ஏற்கனவே Jellyfin-ஐ ஒரு media server-ஆக VPS-ல் வீடியோவிற்காகப் பயன்படுத்துகிறீர்கள் என்றால், Jellyfin-ஐப் பயன்படுத்துவது பயனுள்ளது. இதன் music library சிறப்பாகச் செயல்படுகிறது, மேலும் Finamp என்ற Jellyfin music செயலி Android மற்றும் iOS தளங்களில் ஆஃப்லைனில் கேட்பதற்காகப் பாடல்களைத் தரவிறக்கம் செய்ய உதவுகிறது. இதன் வரம்பு API-ல் உள்ளது. Jellyfin-ல் Subsonic endpoint வசதி இல்லை, மேலும் இதற்கான சமூகத்தால் உருவாக்கப்பட்ட plugin 2022-ல் புதுப்பிக்கப்படுவது நிறுத்தப்பட்டது, எனவே Subsonic செயலி சூழல் இதற்குப் பொருந்தாது. அதற்குப் பதிலாக, Jellyfin-ன் சொந்த API-ஐப் பயன்படுத்தும் செயலிகளை மட்டுமே நீங்கள் பயன்படுத்த முடியும், அவற்றின் எண்ணிக்கை குறைவு.

Funkwhale என்பது கூட்டமைப்பு (federated) வசதி கொண்ட விருப்பமாகும், இதன் 2.0 பதிப்பு மார்ச் 2026-ல் வெளியிடப்பட்டது. Funkwhale server ஒரு pod என்று அழைக்கப்படுகிறது; pod-கள் ActivityPub (Mastodon-ன் பின்னால் உள்ள protocol) மூலம் ஒன்றிணைகின்றன, ஒரு pod-ல் உள்ள பயனர் மற்றொரு pod-ல் உள்ள பொது நூலகத்தைப் பின்தொடர முடியும். இது Subsonic API-ன் ஒரு பகுதியையும் ஆதரிக்கிறது, ஆனால் கவனிக்க வேண்டிய ஒரு வித்தியாசம் உள்ளது: ஒவ்வொரு பயனரும் தங்கள் அமைப்புகளில் தனி Subsonic கடவுச்சொல்லை அமைக்க வேண்டும், ஏனெனில் Subsonic protocol-க்கு server-ஆல் படிக்கக்கூடிய கடவுச்சொல் தேவைப்படுகிறது. Funkwhale-ஐ நிறுவுவது சற்று கடினமானது, ஏனெனில் இதற்கு web app-உடன் சேர்த்து PostgreSQL மற்றும் task queue தேவைப்படுகிறது.

உங்களுக்குக் கூட்டமைப்பு வசதி தேவையில்லை என்றாலோ அல்லது ஏற்கனவே Jellyfin இயங்கவில்லை என்றாலோ, Navidrome-ஐத் தேர்வு செய்யவும். இந்த வழிகாட்டியின் மீதமுள்ள பகுதிகள் Docker மூலம் Navidrome-ஐ அமைப்பது குறித்து விளக்குகின்றன.

Subsonic API ஏன் உங்கள் தொலைபேசி செயலியைத் தீர்மானிக்கிறது

Subsonic என்பது ஒரு இசை வழங்கியாகும் (music server). இதன் HTTP API, சுய-வழங்கி (self-hosted) ஆடியோவிற்கான பொதுவான மொழியாக மாறியது. OpenSubsonic என்பது இந்த API-ஐ தொடர்ந்து மேம்படுத்தும் ஒரு சமூகத் திட்டமாகும். இந்த வரலாற்றின் காரணமாகவே, உங்கள் தொலைபேசியில் பல செயலிகளைத் தேர்ந்தெடுக்கும் வாய்ப்பு உள்ளது. Navidrome தனக்கென பிரத்யேக மொபைல் செயலியை வெளியிடுவதில்லை (ships no mobile app); அதற்குத் தேவையும் இல்லை. ஏனெனில், எந்தவொரு Subsonic client-ம் ஒரு server முகவரி மற்றும் உங்கள் கணக்கு விவரங்களைக் கொண்டு உள்நுழைய முடியும்.

ஆஃப்லைன் ஒத்திசைவு (offline sync) விஷயத்தில் இது மிக முக்கியமானது. தினசரி பயன்பாட்டில் உங்கள் அமைப்பு சிறப்பாகச் செயல்படுமா என்பதைத் தீர்மானிக்கும் அம்சம் இதுவே. சுரங்கப்பாதையில் பயணிக்கும்போது உங்கள் server-ஐ அணுக முடியாது என்பதால், client முன்கூட்டியே கோப்புகளை உள்ளூர் சேமிப்பகத்திற்கு (local storage) நகல் எடுத்திருக்க வேண்டும். அனைத்து client-களும் ஸ்ட்ரீமிங் செய்யும். சில மட்டுமே பதிவிறக்கம் செய்யும். navidrome.org/apps-ல் உள்ள client பட்டியலில் எவை பதிவிறக்க வசதி கொண்டவை என்பது குறிப்பிடப்பட்டுள்ளது. Android-ல் Substreamer மற்றும் Ultrasonic, iOS-ல் Amperfy மற்றும் play:Sub என இரு தளங்களிலும் பல தேர்வுகள் உள்ளன. சிறந்த client-களில் பல கட்டணச் செயலிகளாக உள்ளன. 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"
  }
]

இவை பிட்ரேட் (bitrate) அடிப்படையில் கணக்கிடப்பட்ட தோராயமான அளவுகள், உண்மையான சேகரிப்பின் அளவீடுகள் அல்ல. உங்கள் கோப்புகளைக் கொண்டு நீங்களே எளிதாகக் கணக்கிடலாம். ஒரு ஆல்பத்தை 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 தேவைப்படும்; அதாவது காகிதத்தில் பட்டியலிடக்கூடிய ஒரு சிறிய சேகரிப்பிற்கு ஒரு முழு டெராபைட் (TB) தேவைப்படலாம். தொலைபேசிக்கு ஏற்ற Opus கோப்புகள் 128 kbps வேகத்தில் இருந்தால், அதே ஆயிரம் ஆல்பங்களை 43 GB-க்குள் அடக்கிவிடலாம். உங்களிடம் ஏற்கனவே உள்ள நூலகத்தில் du -sh /path/to/music கட்டளையை இயக்கவும், ஏனெனில் நீங்கள் ஒரு திட்டத்தைத் தேர்ந்தெடுக்கும்போது உங்கள் நூலகத்தின் சராசரி பிட்ரேட் மட்டுமே முக்கியமானது.

பயன்பாட்டுச் செலவில் பேண்ட்விட்த் (bandwidth) சிறிய பங்கையே வகிக்கிறது. ஒரு 320 kbps ஸ்ட்ரீம் வினாடிக்கு 40 கிலோபைட்கள் (KB) வேகத்தில் இயங்கும், எனவே ஒரு மணிநேரக் கேட்பிற்கு சுமார் 144 MB தரவு செலவாகும். ஒரு மாதத்தில் நூறு மணிநேரம் கேட்டால் சுமார் 14 GB மட்டுமே செலவாகும், இதை எந்த VPS பரிமாற்ற வரம்பும் (transfer allowance) பெரிதாகக் கருதாது. ஆனால், தொலைபேசியில் முதல்முறை ஆஃப்லைன் ஒத்திசைவு (offline sync) செய்யும்போது, ஒரே இரவில் பல பத்து ஜிபி தரவு பரிமாற்றம் நடக்க வாய்ப்புள்ளது.

Storage tier அல்லது compute tier?

Music server என்பது மிகக்குறைந்த கணக்கீட்டுத் திறன் கொண்ட, அதிகப்படியான cold data-க்களைக் கொண்ட ஒரு அமைப்பாகும். ஒரு கோப்பை வினாடிக்கு 40 kilobytes வேகத்தில் வாசிக்கும்போது, எந்தவொரு disk-ம் வேலையின்றி சும்மா இருக்கும். library scan அல்லது transcoding செய்யும் போது மட்டுமே CPU வேலை செய்யும், ஆனால் நீங்கள் பெரும்பாலும் இதைச் செய்யப்போவதில்லை. எனவே, compute plan-ல் உள்ள வேகமான NVMe இங்கு எந்தப் பயனும் தராது. மாறாக, அதன் gigabyte-க்கான விலை, நீங்கள் FLAC கோப்புகளை பதிவேற்றுவதைத் தடுக்கும் ஒரு காரணியாக இருக்கும். இத்தகைய சூழலில் storage VPS, சாதாரண VPS-ஐ விடச் சிறந்தது. ஏனெனில், அந்தத் திட்டங்கள் core-க்கு பதிலாக terabyte அடிப்படையில் விலை நிர்ணயம் செய்யப்படுகின்றன.

Memory தேவை மிகக்குறைவு. Navidrome ஒரு தனிப்பட்ட library-ஐ சில நூறு megabytes-ல் கையாளும். playback-ஐ விட scan செய்யும் போதுதான் அதிக memory தேவைப்படும். அந்த server-க்கு 1 GB அல்லது 2 GB RAM ஒதுக்கிவிட்டு, மீதமுள்ள பட்ஜெட்டை disk-க்காகச் செலவிடுங்கள்.

Docker Compose மூலம் Navidrome-ஐ நிறுவுதல்

முதலில், container இயங்கும் user id-க்குச் சொந்தமான directories-ஐ உருவாக்கவும். உங்களுக்கு Compose புதியது என்றால், VPS-ல் Docker Compose என்ற கட்டுரை இந்த file எதைக் கருதுகிறது என்பதை விளக்குகிறது.

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

docker-compose.yml-ஐ அதன் சொந்த directory-ல் மட்டும் உருவாக்கவும்:

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 restarting நிலையில் இல்லாமல் இயங்கிக்கொண்டிருப்பதை உறுதிப்படுத்த வேண்டும். ஒரு container தொடர்ந்து restart ஆகிக்கொண்டிருந்தால், அது பெரும்பாலும் /srv/navidrome-ல் உள்ள permissions சிக்கலாகும்; docker compose logs navidrome என்பது அந்த container-ஆல் எழுத முடியாத கோப்பின் பெயரைக் குறிக்கும்.

அந்த file-ல் உள்ள நான்கு விவரங்களை விளக்குவது அவசியம். port 127.0.0.1-ல் மட்டுமே வெளியிடப்பட்டுள்ளது, எனவே server-ஐ reverse proxy வழியாக மட்டுமே அணுக முடியும்; பொது இணையத்திலிருந்து port 4533 வழியாக அணுக முடியாது. Docker தனது சொந்த firewall விதிகளை எழுதுவதால், ufw மூலம் அனைத்தும் மறுக்கப்பட்டதாகக் காட்டினாலும், சாதாரண 4533:4533 பொதுவெளியில் வெளிப்படும். music volume 'read-only' முறையில் உள்ளது, எனவே scanner-ல் ஏதேனும் பிழை ஏற்பட்டாலும் உங்கள் கோப்புகளை அது அழிக்க முடியாது. ND_SCANNER_SCHEDULE முன்னிருப்பாக முடக்கப்பட்டுள்ளது; Navidrome 0.55-க்கு முந்தைய வழிகாட்டிகளில் இது ND_SCANSCHEDULE என்று குறிப்பிடப்பட்டிருக்கும், அந்தப் பெயர் இப்போது புழக்கத்தில் இல்லை. கீழே உள்ள backup பகுதிக்குத் தேவையான, உள்ளமைக்கப்பட்ட database backup வசதியை இந்த மூன்று backup அமைப்புகளும் செயல்படுத்துகின்றன.

உங்கள் இசைக்கோப்புகளை server-க்கு மாற்றுதல்

rsync கட்டளையைப் பயன்படுத்தி உங்கள் library-ஐ server-க்கு நகர்த்தவும். இணைப்பு துண்டிக்கப்பட்டால், மீண்டும் முதலிலிருந்து தொடங்காமல், பாதியில் நின்ற இடத்திலிருந்து தொடர இது உதவும்.

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

மூலக் கோப்பகத்தின் (source) இறுதியில் உள்ள slash முக்கியமானது. அதைத் தவிர்த்தால் /srv/music/Music ஏற்படும். நகலெடுக்கும் பணி முடிந்ததும், கோப்புகளின் உரிமையாளரை (ownership) சரிசெய்யவும்:

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

இந்த container user id 1000-ல் இயங்குகிறது, மேலும் mount செய்யப்பட்ட கோப்பகம் read-only நிலையில் உள்ளது. எனவே, ஒவ்வொரு கோப்பும் அந்த id-ஆல் வாசிக்கக்கூடியதாக இருக்க வேண்டும். உங்கள் SSH கணக்கு VPS-ல் 1000 என்ற uid-ஐக் கொண்டிருக்கவில்லை என்றால், நகலெடுக்கப்பட்ட கோப்புகள் வேறொருவரின் உரிமையில் இருக்கும். இதனால் scan செய்யும்போது ஒரு பாடல் கூட கிடைக்காது, web interface காலியாகவே இருக்கும். id -u உங்கள் தற்போதைய id-ஐக் காட்டும். Docker container-களில் PUID மற்றும் PGID எவ்வாறு செயல்படுகின்றன என்பது குறித்த விளக்கம் மேப்பிங் முறையை விரிவாக விளக்குகிறது.

எங்கிருந்தும் மொபைலில் இயங்க ஒரு reverse proxy மற்றும் TLS

DNS A record-ஐ VPS-ஐ நோக்கிச் சுட்டிக்காட்டவும், பின் Caddy-க்கு இந்த மூன்று வரிகளை வழங்கவும்:

music.example.com {
    reverse_proxy 127.0.0.1:4533
}

sudo systemctl reload caddy

முதல் கோரிக்கையின்போதே Caddy சான்றிதழைப் (certificate) பெற்றுக்கொள்ளும். ACME (automatic certificate management environment) சவால் port 80-ல் பூர்த்தி செய்யப்படுவதால், ports 80 மற்றும் 443 ஆகிய இரண்டையும் திறந்து வைத்திருக்க வேண்டும். Nginx-ல், location block-க்குள் proxy_buffering off;-ஐச் சேர்க்கவும்: Navidrome தனது progress நிகழ்வுகளை ஒரு நீண்ட கால இணைப்பின் (long lived connection) மூலம் web interface-க்கு அனுப்பும். buffering இயக்கப்பட்டிருந்தால், Nginx பதிலுக்காகக் காத்திருக்கும்போது interface அப்படியே நின்றுவிடும். இதை அதன் சொந்த subdomain-க்கு பதிலாக /music போன்ற ஒரு path-ல் வழங்கினால், ND_BASEURL-ஐ அதே path-க்கு அமைக்கவும், இல்லையெனில் interface காலியாகத் தோன்றும். மூன்று பொதுவான proxy-களின் ஒப்பீடு Nginx, Caddy and Traefik on a VPS பகுதியில் உள்ளது.

தளத்தைத் திறந்து முதல் கணக்கை உருவாக்கவும். இயல்புநிலை கடவுச்சொல் (default password) எதுவும் இல்லை, முதல் பயனர் admin-ஐ உருவாக்கக் கேட்கப்படுவார், எனவே முகவரியை மற்றவர்களுக்குப் பகிரும் முன்பே இதைச் செய்துவிடவும். பின், மொபைல் client பயன்படுத்தும் சரியான 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" என்று தொடங்கி, server வகையாக navidrome-ஐக் காட்டும். "status":"failed" மற்றும் error code 40 கொண்ட பதில் கிடைத்தால், proxy சரியாகச் செயல்படுகிறது, ஆனால் credentials தவறாக உள்ளது என்று பொருள். இந்த நிலையில் சான்றிதழ் பிழை (certificate error) ஏற்பட்டால், அதை முதலில் சரிசெய்யவும்; ஏனெனில் பெரும்பாலான மொபைல் client-கள் தவறான சான்றிதழை நிராகரிக்கும்போது, பயனருக்குப் புரியாத பொதுவான பிழைச் செய்தியையே காட்டும்.

முதல் ஸ்கேனுக்குப் பிறகு உங்கள் லைப்ரரி ஏன் தவறாகத் தெரிகிறது

Navidrome கோப்புறைகளுக்கு (folders) பதிலாக டேக் (tags) அடிப்படையில் உலாவுகிறது, எனவே நீங்கள் காண்பவை டேக்குகளைப் பொறுத்தே அமையும். 'album artist' டேக் இல்லாத ஒரு ட்ராக், அதன் 'track artist' பெயரில் வகைப்படுத்தப்படும். இதனால்தான், ஒவ்வொரு ட்ராக்கிலும் வெவ்வேறு கலைஞர்களைக் கொண்ட ஒரு தொகுப்பு (compilation), தலா ஒரு ட்ராக் கொண்ட இருபது தனித்தனி ஆல்பங்களாக மாறுகிறது. இதை Navidrome-ல் சரிசெய்யாமல், கோப்புகளிலேயே சரிசெய்ய வேண்டும்: MusicBrainz Picard மற்றும் beets ஆகிய இரண்டும் MusicBrainz தரவுத்தளத்தில் ஆல்பத்தைத் தேடி, சரியான டேக்குகளைக் கோப்புகளில் எழுதிவிடும்.

Navidrome ஒரு 'multi artist' டேக்கை தனித்தனி கலைஞர்களாகப் பிரிக்கும். எனவே, பிரிப்பான் (separator) கொண்ட பெயரைக் கொண்ட ஒரு இசைக்குழு தவறுதலாகப் பிரிக்கப்படும்; AC/DC என்பது அனைவரும் சந்திக்கும் ஒரு உதாரணம். ND_SCANNER_ARTISTSPLITEXCEPTIONS-ல் பிரிக்கப்படக்கூடாத பெயர்களைக் குறிப்பிட வேண்டும்.

புதிய கோப்புகள் பதிவேற்றப்பட்ட சில நொடிகளில் 'file watcher' அவற்றை அடையாளம் காணும். இந்த watcher கர்னல் மாற்ற அறிவிப்புகளை (kernel change notifications) சார்ந்துள்ளது. மற்றொரு கணினியிலிருந்து நெட்வொர்க் ஷேர் (network share) மூலம் இணைக்கப்பட்ட கோப்புகளுக்கு இந்த அறிவிப்புகள் வராது. அத்தகைய அமைப்புகளில், லைப்ரரியைப் புதுப்பித்த நிலையில் வைத்திருக்க அவ்வப்போது ND_SCANNER_SCHEDULE-ஐப் பயன்படுத்த வேண்டும். முழுமையான 'rescan' ஒவ்வொரு கோப்பின் டேக்கையும் வாசிக்கும், இது பெரிய லைப்ரரிகளில் மெதுவாக இருக்கும். இதனால்தான் கீழே உள்ள தரவுத்தளத்தைப் பாதுகாப்பது அவசியமாகிறது.

பயனர்கள், பிளேலிஸ்ட்கள் மற்றும் பகிர்தல்

நிர்வாகி மட்டுமே இணைய இடைமுகத்தில் (web interface) பிற கணக்குகளை உருவாக்க முடியும்; பயனர்கள் தாங்களாகவே பதிவு செய்துகொள்ளும் வசதி இல்லை. ஒவ்வொரு பயனருக்கும் தனித்தனி play counts, playlists, favourites மற்றும் ratings இருப்பதால், ஒரு வீட்டில் உள்ள அனைவரும் ஒரே ரசனைப் பட்டியலைப் பகிர வேண்டிய அவசியம் இருக்காது.

பிளேலிஸ்ட்கள் இரண்டு வழிகளில் வருகின்றன. ஒரு client-ல் உருவாக்கப்படும் பிளேலிஸ்ட் database-ல் சேமிக்கப்படும். library folder-ல் இடப்படும் ஒரு .m3u கோப்பு, scan செய்யும்போது இறக்குமதி செய்யப்படும்; இது desktop player-லிருந்து பிளேலிஸ்ட்களைக் கொண்டுவருவதற்கான எளிதான வழியாகும். Smart playlists என்பவை .nsp கோப்புகள் ஆகும். இவை சிறிய JSON விதிமுறைகளைக் கொண்ட கோப்புகள், அதே முறையில் இறக்குமதி செய்யப்படுகின்றன. library மாறும்போது இவை தானாகவே புதுப்பித்துக்கொள்ளும்.

ஜூலை 2026-ல் வெளியான 0.63.0 பதிப்பிலிருந்து பகிர்தல் (sharing) வசதி இயல்பாகவே (default) செயல்படுத்தப்பட்டுள்ளது. இது ஒரு பயனர் தனது album-க்கு பொதுவான இணைப்பை (public link) உருவாக்க அனுமதிக்கிறது; இதன் மூலம் லாக்-இன் செய்யாமலேயே எவரும் அதைத் திறக்க முடியும். உங்கள் முழு library-யையும் வைத்திருக்கும் server-ல் இது நீங்கள் விரும்பாத ஒன்றாக இருக்கலாம். அத்தகைய சூழலில், ND_ENABLESHARING என்பதை false என அமைப்பதன் மூலம் இந்த வசதியை முடக்கலாம்.

இசை கோப்புகளிலிருந்து தரவுத்தளத்தை தனித்தனியாக காப்புப்பிரதி எடுத்தல்

Navidrome-ன் சொந்த காப்புப்பிரதி வசதி தரவுத்தளத்தை மட்டுமே உள்ளடக்கும். ஆவணங்கள் இதைத் தெளிவாகக் குறிப்பிடுகின்றன: காப்புப்பிரதி செயல்முறை தரவுத்தளத்தை மட்டுமே காப்புப்பிரதி எடுக்கும், அதாவது பயனர்கள், பாடல்கள் கேட்கப்பட்ட எண்ணிக்கை மற்றும் பிற தகவல்கள் இதில் அடங்கும்; இசை கோப்புகளையோ அல்லது உள்ளமைவு (config) கோப்புகளையோ இது காப்புப்பிரதி எடுக்காது. இந்த இரண்டையும் தனித்தனியாகக் கருதுவதே சரியான அணுகுமுறை, ஏனெனில் இவை இரண்டும் வெவ்வேறு காரணங்களால் செயலிழக்கக்கூடும். இசை கோப்புகளை நீங்கள் அவற்றை நகலெடுத்த வட்டில் (disk) இருந்து மீண்டும் பெற்றுக்கொள்ளலாம். ஆனால், பாடல்கள் கேட்கப்பட்ட எண்ணிக்கை, மதிப்பீடுகள், விருப்பமானவை மற்றும் பிளேலிஸ்ட்கள் வேறு எங்கும் இருக்காது, மேலும் ஒரு rescan செய்தாலும் அவற்றை மீண்டும் கொண்டுவர முடியாது.

Compose கோப்பு ஏற்கனவே /data/backup-ல் இரவு நேர நகல் ஒன்றை உருவாக்கி, ஏழு நகல்களைச் சேமித்து வைக்கிறது. மேம்படுத்தலுக்கு (upgrade) முன்பு கைமுறையாக ஒரு நகலை எடுக்கவும்:

sudo docker compose run --rm navidrome backup create

மீட்டெடுக்கும்போது (restore) தற்போதைய தரவுத்தளம் அழிக்கப்பட்டு, காப்புப்பிரதி கோப்பு அந்த இடத்தில் நகலெடுக்கப்படும். Navidrome நிறுத்தப்பட்டிருக்கும்போது மட்டுமே இந்தச் செயல்முறை நடைபெற வேண்டும். இயங்கிக்கொண்டிருக்கும் server-ல் மீட்டெடுக்கும் செயல்முறை பாதுகாப்பானது அல்ல.

அந்தக் கோப்புகள் அதே VPS-ல் இருப்பதால், VPS செயலிழந்தால் அவை கிடைக்காது. /srv/navidrome-ஐ ஒரு கால அட்டவணையின்படி மற்றொரு கணினிக்கு அல்லது object storage-க்கு அனுப்பவும்; இதற்காகவே restic and BorgBackup உருவாக்கப்பட்டுள்ளன. முழு கோப்பகமும் (directory) சிறியது, பொதுவாக ஒரு gigabyte-க்கும் குறைவானது, எனவே தினசரி குறியாக்கம் செய்யப்பட்ட (encrypted) நகலை வெளியே சேமிப்பது மிகக் குறைந்த செலவில், rescan மூலம் மீட்க முடியாத அனைத்தையும் பாதுகாக்கும்.

FAQ

VPS-ல் இசையை transcode செய்ய வேண்டுமா?

தேவையில்லை. தொலைபேசிகள் மற்றும் உலாவிகள் MP3, AAC, Opus மற்றும் FLAC கோப்புகளைத் தாங்களாகவே decode செய்துவிடும். எனவே, server கோப்பை அப்படியே அனுப்புகிறது, இதனால் CPU பயன்பாடு மிகக் குறைவு. ஒரே ஒரு சூழலில் மட்டும் இதைச் செய்யலாம்: மொபைல் டேட்டாவில் FLAC library-ஐப் பயன்படுத்தும்போது, சுமார் 900 kbps வேகத்தில் உள்ள கோப்பை 128 kbps வேகத்தில் Opus-க்கு மாற்றினால், டேட்டா பயன்பாடு சுமார் ஏழு மடங்கு குறையும். Navidrome-ல் பயனர் மற்றும் player வாரியாக இதைச் செய்ய முடியும்; நீங்கள் இயக்கும் வரை இது செயலிழந்தே இருக்கும்.

எனது தொலைபேசி செயலியால் ஏன் ஆஃப்லைனில் கேட்க இசையைப் பதிவிறக்க முடியவில்லை?

ஏனெனில் ஆஃப்லைன் சேமிப்பு என்பது server வசதி அல்ல, அது client செயலியின் வசதி. Subsonic API மூலம் எந்தவொரு client-ம் முழு கோப்பையும் பெற முடியும், ஆனால் தொலைபேசியில் கோப்பைச் சேமிப்பதா வேண்டாமா என்பதை அந்தச் செயலிதான் முடிவு செய்கிறது. navidrome.org/apps தளத்தில் உள்ள client பட்டியலைப் பார்த்து, ஆஃப்லைன் பதிவிறக்கம் அல்லது caching வசதி கொண்ட ஒன்றைத் தேர்ந்தெடுக்கவும். சில செயலிகள் நீங்கள் ஏற்கனவே கேட்ட பாடல்களை மட்டுமே cache செய்யும்; இது பயணத்திற்கு முன் ஒரு முழு ஆல்பத்தை sync செய்வதற்குச் சமமல்ல.

ஸ்கேன் செய்த பிறகு ஒரு ஆல்பம் ஏன் பல ஆல்பங்களாகப் பிரிந்தது?

பாடல்களில் album artist tag விடுபட்டிருக்கலாம் அல்லது சீரற்றதாக இருக்கலாம். Navidrome கோப்புறைகளை விட tags அடிப்படையிலேயே இசையை வகைப்படுத்துகிறது. எனவே, பன்னிரண்டு பாடல்களில் வெவ்வேறு artist பெயர்கள் இருந்து, பொதுவான album artist tag இல்லையென்றால், அது பன்னிரண்டு தனித்தனி ஆல்பங்களாகத் தெரியும். ஆல்பத்தின் அனைத்துப் பாடல்களுக்கும் album artist tag-ஐச் சரியாக அமைக்கவும் (தொகுப்பு ஆல்பங்களுக்கு 'Various Artists' எனப் பயன்படுத்தலாம்), பிறகு மீண்டும் ஸ்கேன் செய்யவும். MusicBrainz Picard அல்லது beets மூலம் ஒரு முழு கோப்புறையையும் ஒரே நேரத்தில் சரிசெய்ய முடியும்.

சுய-ஹோஸ்ட் செய்யப்பட்ட மியூசிக் ஸ்ட்ரீமிங் Spotify-க்கு மாற்றாகுமா?

இது player மற்றும் library-க்கு மாற்றாகுமே தவிர, பாடல்களின் தொகுப்பிற்கு (catalogue) மாற்றாகாது. உங்கள் சொந்த இசைத் தொகுப்பை எல்லா சாதனங்களிலும் பெறலாம்; உரிம மாற்றங்களால் உங்கள் பிளேலிஸ்ட்களோ அல்லது பாடல் எண்ணிக்கையோ பாதிக்கப்படாது. ஆனால் புதிய வெளியீடுகள் கிடைக்காது, மற்றவர்களின் ரசனையை அடிப்படையாகக் கொண்ட பரிந்துரைகளும் கிடைக்காது. இதைப் பயன்படுத்துபவர்கள் பெரும்பாலும் சொந்தமாக இசை வாங்கி வைத்துக்கொண்டு, புதிய பாடல்களைக் கண்டறிய மலிவான ஸ்ட்ரீமிங் கணக்குகளைப் பயன்படுத்துகின்றனர்.