วิธีทำ Self-hosted Music Streaming บน VPS ด้วย Navidrome

สิ่งที่ได้รับจากการทำ self-hosted music streaming บน VPS

การทำ self-hosted music streaming บน VPS หมายความว่าคุณเป็นผู้รันโปรแกรมเล่นเพลงและเป็นผู้จัดหาไฟล์เพลงด้วยตนเอง เซิร์ฟเวอร์จะทำหน้าที่เก็บไฟล์ที่คุณเป็นเจ้าของอยู่แล้ว และโทรศัพท์มือถือสามารถเข้าถึงไฟล์เหล่านั้นผ่านอินเทอร์เน็ตได้ด้วยการล็อกอินตามปกติ โปรดพิจารณาข้อเท็จจริงก่อนเริ่มใช้งาน: วิธีนี้เป็นการแทนที่โปรแกรมเล่นเพลงของบริการสตรีมมิง ไม่ใช่การแทนที่คลังเพลงของบริการเหล่านั้น จะไม่มีเพลงใหม่ปรากฏในคลังของคุณจนกว่าคุณจะซื้อหรือริปไฟล์เพลงนั้นแล้วคัดลอกไปยังเซิร์ฟเวอร์

ไฟล์เสียงใช้ทรัพยากรเซิร์ฟเวอร์น้อยกว่าไฟล์วิดีโอมาก ไฟล์มีขนาดเล็ก โทรศัพท์มือถือสามารถถอดรหัสรูปแบบไฟล์ทั่วไปได้โดยไม่ต้องพึ่งพาเซิร์ฟเวอร์ และผู้ฟังหนึ่งคนใช้แบนด์วิดท์น้อยกว่าการโทรแบบวิดีโอคอล ดังนั้นภาระของ CPU จึงไม่ใช่ปัญหาหลัก แต่พื้นที่จัดเก็บข้อมูล (disk space) คือข้อจำกัดที่แท้จริง ปัจจัยอีกสองประการที่จะตัดสินว่าระบบนี้ใช้งานได้ดีหรือไม่ คือคุณภาพของ metadata (tags) และความสามารถของแอปบนโทรศัพท์มือถือในการดาวน์โหลดเพลงเพื่อใช้งานแบบออฟไลน์

เลือกเซิร์ฟเวอร์เพลงตัวไหนดี: Navidrome, Jellyfin หรือ Funkwhale?

Navidrome เป็นตัวเลือกมาตรฐานหากคุณสนใจเฉพาะไฟล์เสียงเท่านั้น มันเป็นไฟล์ Go binary เดียวในคอนเทนเนอร์เดียว และเก็บสถานะทั้งหมดไว้ในฐานข้อมูล SQLite เพียงไฟล์เดียว มันรองรับ Subsonic API ซึ่งเป็นเหตุผลว่าทำไมจึงมีแอปพลิเคชันบนมือถือจากผู้พัฒนาภายนอกจำนวนมากให้เลือกใช้ เวอร์ชัน 0.63.2 เป็นเวอร์ชันปัจจุบันในเดือนสิงหาคม 2026 โครงการระบุว่าซอฟต์แวร์ทำงานได้ดีบนฮาร์ดแวร์ขนาดเล็กอย่าง Raspberry Pi Zero ดังนั้นซอฟต์แวร์เซิร์ฟเวอร์จึงไม่ใช่ส่วนที่คุณต้องเสียค่าใช้จ่าย

Jellyfin น่าใช้งานหากคุณรัน Jellyfin เป็นเซิร์ฟเวอร์สื่อบน VPS สำหรับวิดีโออยู่แล้ว คลังเพลงของมันทำงานได้ดี และ Finamp เป็นแอปเพลงสำหรับ Jellyfin บน Android และ iOS ที่สามารถดาวน์โหลดเพลงไว้ฟังแบบออฟไลน์ได้ ข้อจำกัดอยู่ที่ API โดย Jellyfin ไม่มี Subsonic endpoint ในตัว และปลั๊กอินจากชุมชนที่เคยเพิ่มฟีเจอร์นี้หยุดการอัปเดตไปตั้งแต่ปี 2022 ทำให้ระบบนิเวศของแอป Subsonic ไม่สามารถใช้งานกับ Jellyfin ได้ คุณต้องใช้แอปที่รองรับ Jellyfin API โดยตรงแทน ซึ่งมีตัวเลือกน้อยกว่า

Funkwhale เป็นตัวเลือกแบบ federated โดยเวอร์ชัน 2.0 ถูกปล่อยออกมาในเดือนมีนาคม 2026 เซิร์ฟเวอร์ Funkwhale เรียกว่า pod ซึ่งแต่ละ pod จะเชื่อมต่อกันผ่าน ActivityPub (โปรโตคอลเดียวกับที่ใช้ใน Mastodon) ทำให้ผู้ใช้บน pod หนึ่งสามารถติดตามคลังเพลงสาธารณะของอีก pod หนึ่งได้ มันรองรับ Subsonic API บางส่วนเช่นกัน โดยมีข้อแตกต่างที่ควรทราบคือ ผู้ใช้แต่ละคนต้องตั้งรหัสผ่าน Subsonic แยกต่างหากในการตั้งค่าส่วนตัว เนื่องจากโปรโตคอล Subsonic ต้องการรหัสผ่านที่เซิร์ฟเวอร์สามารถอ่านได้ Funkwhale เป็นการติดตั้งที่ซับซ้อนกว่า เนื่องจากต้องใช้ PostgreSQL และ task queue นอกเหนือจากตัวเว็บแอปพลิเคชัน

ให้เลือก Navidrome เว้นแต่คุณต้องการฟีเจอร์ federation หรือมี Jellyfin รันอยู่แล้ว ส่วนที่เหลือของคู่มือนี้จะอธิบายการตั้งค่า Navidrome ด้วย Docker

เหตุผลที่ Subsonic API เป็นตัวกำหนดว่าคุณจะใช้แอปมือถือตัวใด

Subsonic เคยเป็นเซิร์ฟเวอร์เพลงที่มี HTTP API ซึ่งกลายเป็นภาษากลางสำหรับบริการสตรีมเสียงแบบ self-hosted และ OpenSubsonic คือโครงการชุมชนที่คอยพัฒนาต่อยอด API ดังกล่าว ประวัติความเป็นมานี้เองที่เป็นเหตุผลว่าทำไมคุณถึงมีตัวเลือกบนโทรศัพท์ Navidrome ไม่ได้พัฒนาแอปมือถือของตนเองและไม่จำเป็นต้องมี เพราะไคลเอนต์ Subsonic ใดๆ ก็สามารถล็อกอินด้วยที่อยู่เซิร์ฟเวอร์และรายละเอียดบัญชีของคุณได้

เรื่องนี้มีความสำคัญที่สุดสำหรับการซิงค์แบบออฟไลน์ ซึ่งเป็นฟีเจอร์ที่ตัดสินว่าระบบของคุณจะใช้งานได้จริงในชีวิตประจำวันหรือไม่ โทรศัพท์ที่อยู่ในอุโมงค์จะไม่สามารถเข้าถึงเซิร์ฟเวอร์ของคุณได้ ดังนั้นไคลเอนต์จึงต้องคัดลอกไฟล์ลงในหน่วยความจำเครื่องไว้ล่วงหน้า ไคลเอนต์ทุกตัวรองรับการสตรีม แต่มีเพียงบางตัวเท่านั้นที่รองรับการดาวน์โหลด รายชื่อไคลเอนต์ที่ navidrome.org/apps จะระบุว่าตัวใดทำได้บ้าง ซึ่งมีตัวเลือกมากมายทั้งสองแพลตฟอร์ม ได้แก่ Substreamer และ Ultrasonic บน Android รวมถึง Amperfy และ play:Sub บน iOS ไคลเอนต์ที่มีประสิทธิภาพสูงหลายตัวเป็นแอปแบบเสียเงิน และ Symfonium บน Android คือแอปที่ผู้คนกล่าวถึงมากที่สุด ควรติดตั้งทดลองใช้สองตัวก่อนตัดสินใจ เพราะนี่คือส่วนของระบบที่คุณต้องใช้งานทุกวัน

คลังเพลงต้องการพื้นที่จัดเก็บข้อมูลเท่าใด

[
  {
    "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 วินาที ให้นำ bitrate ในหน่วย kilobits ต่อวินาทีคูณด้วย 2,700 แล้วหารด้วย 8,000 เพื่อให้ได้หน่วยเป็น megabytes ที่ 320 kbps จะได้ 108 MB ต่อหนึ่งอัลบั้ม ดังนั้นอัลบั้มจำนวนหนึ่งพันอัลบั้มจะใช้พื้นที่ประมาณ 108 GB

รูปแบบ Lossless จะทำให้คำตอบเปลี่ยนไป โดยปกติไฟล์ FLAC คุณภาพระดับ CD จะมีค่าเฉลี่ยอยู่ที่ประมาณ 900 kbps ดังนั้นอัลบั้มจำนวนหนึ่งพันอัลบั้มเท่าเดิมจะต้องการพื้นที่ประมาณ 304 GB สำหรับคลังเพลงระดับ 24 bit, 96 kHz จะใช้พื้นที่ประมาณ 1,013 GB หรือหนึ่ง terabyte เต็มๆ สำหรับคลังเพลงที่คุณสามารถจดรายชื่อลงบนกระดาษได้ ส่วนไฟล์ Opus ที่เหมาะสำหรับโทรศัพท์มือถือที่ 128 kbps จะสามารถบรรจุอัลบั้มจำนวนหนึ่งพันอัลบั้มนั้นลงในพื้นที่เพียง 43 GB ให้รันคำสั่ง du -sh /path/to/music บนคลังเพลงที่คุณมีอยู่แล้ว เพราะค่าเฉลี่ย bitrate ของคุณเองคือตัวเลขเดียวที่สำคัญเมื่อคุณต้องเลือกแผนการใช้งาน

Bandwidth เป็นส่วนที่มีผลต่อค่าใช้จ่ายน้อยกว่า การสตรีมที่ 320 kbps จะใช้ข้อมูล 40 kilobytes ต่อวินาที ดังนั้นการฟังเพลงหนึ่งชั่วโมงจะใช้ข้อมูลประมาณ 144 MB หากฟังเดือนละหนึ่งร้อยชั่วโมงจะใช้ข้อมูลประมาณ 14 GB ซึ่งไม่มี VPS รายใดตรวจพบการใช้งานในระดับนี้ ข้อยกเว้นคือการซิงค์ข้อมูลแบบ offline ครั้งแรกของโทรศัพท์ ซึ่งอาจมีการรับส่งข้อมูลหลายสิบ gigabytes ในคืนเดียว

Storage tier หรือ compute tier?

Music server เป็นแหล่งเก็บข้อมูลขนาดใหญ่ที่แทบไม่มีการประมวลผล การอ่านไฟล์ที่ความเร็ว 40 kilobytes ต่อวินาทีทำให้ disk แทบไม่ได้ทำงาน และ CPU จะทำงานหนักเฉพาะตอนสแกนคลังเพลงหรือตอน transcoding ซึ่งคุณแทบไม่ได้ใช้งาน ดังนั้น NVMe ความเร็วสูงในแผน compute จึงไม่มีประโยชน์ในกรณีนี้ ในขณะที่ราคาต่อ gigabyte ของมันคืออุปสรรคที่ทำให้คุณไม่สามารถอัปโหลดไฟล์ FLAC ได้ นี่คือกรณีที่ a storage VPS beats a regular VPS เพราะแผนเหล่านี้คิดราคาตาม terabyte ไม่ใช่ตามจำนวน core

หน่วยความจำที่ใช้มีเพียงเล็กน้อย Navidrome ใช้ RAM เพียงไม่กี่ร้อย megabytes ในการให้บริการคลังเพลงส่วนตัว และช่วงที่ใช้ทรัพยากรสูงสุดคือตอนสแกน ไม่ใช่ตอนเล่นเพลง ให้จัดสรร RAM ให้เครื่อง 1 GB หรือ 2 GB ก็เพียงพอ แล้วนำงบประมาณที่เหลือไปลงกับ disk จะคุ้มค่ากว่า

การติดตั้ง Navidrome ด้วย Docker Compose

สร้างไดเรกทอรีขึ้นมาก่อน โดยกำหนดให้ผู้ใช้ที่มี ID เดียวกับที่จะรันคอนเทนเนอร์เป็นเจ้าของ หากคุณยังไม่คุ้นเคยกับ Compose เนื้อหาใน Docker Compose บน VPS จะอธิบายถึงสิ่งที่ไฟล์นี้กำหนดไว้

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 ควรแสดงสถานะว่าบริการกำลังทำงานอยู่ ไม่ใช่กำลังรีสตาร์ท คอนเทนเนอร์ที่รีสตาร์ทวนลูปมักเกิดจากปัญหาเรื่องสิทธิ์การเข้าถึงบน /srv/navidrome และ docker compose logs navidrome จะระบุชื่อไฟล์ที่ระบบไม่สามารถเขียนข้อมูลลงไปได้

มีรายละเอียด 4 จุดในไฟล์ดังกล่าวที่ควรทำความเข้าใจ พอร์ตถูกเปิดใช้งานบน 127.0.0.1 เท่านั้น เพื่อให้สามารถเข้าถึงเซิร์ฟเวอร์ผ่าน reverse proxy ได้ และไม่สามารถเข้าถึงผ่านพอร์ต 4533 จากอินเทอร์เน็ตสาธารณะโดยตรง เนื่องจาก Docker จะเขียนกฎ firewall ของตัวเอง ดังนั้นการตั้งค่า 4533:4533 แบบปกติจะยังคงเปิดเผยต่อสาธารณะ แม้บนเครื่องที่ ufw รายงานว่าปฏิเสธการเชื่อมต่อทั้งหมดแล้วก็ตาม โวลุ่มเพลงถูกตั้งค่าเป็นแบบอ่านอย่างเดียว (read only) เพื่อป้องกันไม่ให้บั๊กของตัวสแกนลบไฟล์ต้นฉบับของคุณ ND_SCANNER_SCHEDULE ถูกปิดใช้งานโดยค่าเริ่มต้น และคู่มือที่เขียนก่อน Navidrome 0.55 จะเรียกมันว่า ND_SCANSCHEDULE ซึ่งเป็นชื่อที่ไม่มีอยู่แล้วในปัจจุบัน การตั้งค่าสำรองข้อมูลทั้ง 3 รายการจะเปิดใช้งานระบบสำรองข้อมูลฐานข้อมูลในตัว ซึ่งส่วนการสำรองข้อมูลด้านล่างนี้จะใช้งานต่อไป

การนำเพลงเข้าสู่เซิร์ฟเวอร์

ให้คัดลอกคลังเพลงขึ้นไปยังเซิร์ฟเวอร์ด้วย rsync ซึ่งสามารถดำเนินการต่อได้หากการเชื่อมต่อหลุด แทนที่จะต้องเริ่มใหม่ทั้งหมด

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

การใส่เครื่องหมาย slash ปิดท้ายที่ source นั้นสำคัญ หากไม่มีเครื่องหมายดังกล่าว คุณจะได้ /srv/music/Music เมื่อการคัดลอกเสร็จสิ้น ให้แก้ไขสิทธิ์ความเป็นเจ้าของไฟล์:

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

คอนเทนเนอร์ทำงานด้วย user id 1000 และ mount เป็นแบบอ่านได้อย่างเดียว ดังนั้นทุกไฟล์จะต้องถูกตั้งค่าให้ user id นี้สามารถอ่านได้ หากบัญชี SSH ของคุณไม่ใช่ uid 1000 บน VPS ไฟล์ที่คัดลอกไปจะมีเจ้าของเป็นผู้อื่น ทำให้การสแกนไม่พบเพลงใดๆ และหน้าเว็บอินเทอร์เฟซจะว่างเปล่า id -u จะแสดง id จริงของคุณ และ วิธีการทำงานของ PUID และ PGID ใน Docker containers จะอธิบายการแมปข้อมูลทั้งหมดไว้อย่างละเอียด

การใช้ reverse proxy และ TLS เพื่อให้ใช้งานผ่านมือถือได้จากทุกที่

ชี้ DNS A record ไปยัง VPS จากนั้นกำหนดค่า Caddy ด้วย 3 บรรทัดดังนี้:

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 ให้เพิ่ม proxy_buffering off; ลงในบล็อก location: Navidrome จะส่งข้อมูลความคืบหน้าไปยังหน้าเว็บผ่านการเชื่อมต่อแบบ long-lived หากเปิดใช้งาน buffering ไว้ หน้าเว็บจะค้างและรอการตอบกลับที่ nginx ยังคงถือค้างไว้อยู่ หากคุณให้บริการผ่าน path เช่น /music แทนที่จะใช้ subdomain แยกต่างหาก ให้ตั้งค่า ND_BASEURL ให้เป็น path เดียวกัน มิฉะนั้นหน้าเว็บจะแสดงผลเป็นหน้าว่าง คุณสามารถเปรียบเทียบ proxy ยอดนิยมทั้ง 3 รายการได้ที่ Nginx, Caddy และ Traefik บน 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" และรหัสข้อผิดพลาด 40 แสดงว่า proxy ทำงานปกติแต่ข้อมูลการเข้าสู่ระบบไม่ถูกต้อง หากพบข้อผิดพลาดเกี่ยวกับใบรับรองในขั้นตอนนี้ ให้แก้ไขเป็นอันดับแรก เนื่องจากแอปพลิเคชันบนมือถือส่วนใหญ่จะปฏิเสธใบรับรองที่ไม่ถูกต้องโดยแสดงข้อความแจ้งเตือนที่ไม่ระบุรายละเอียดใดๆ ให้ผู้ใช้ทราบ

เหตุใดคลังเพลงของคุณจึงแสดงผลไม่ถูกต้องหลังจากการสแกนครั้งแรก

Navidrome เรียกดูเพลงตามแท็ก (tags) แทนที่จะเป็นโฟลเดอร์ ดังนั้นแท็กจึงเป็นตัวกำหนดสิ่งที่คุณเห็น เพลงที่ไม่มีแท็ก album artist จะถูกจัดเก็บไว้ภายใต้ชื่อศิลปินของเพลงนั้น ซึ่งเป็นสาเหตุที่ทำให้เพลงรวม (compilation) ที่มีศิลปินต่างกันในแต่ละเพลง กลายเป็นอัลบั้มที่มีเพลงเดียวจำนวน 20 อัลบั้ม คุณควรแก้ไขปัญหานี้ที่ตัวไฟล์โดยตรง ไม่ใช่ใน Navidrome โดยใช้เครื่องมืออย่าง MusicBrainz Picard หรือ beets เพื่อค้นหาข้อมูลอัลบั้มในฐานข้อมูล MusicBrainz และเขียนแท็กมาตรฐานกลับลงไปในไฟล์

นอกจากนี้ Navidrome จะแยกแท็กที่มีศิลปินหลายคนออกจากกัน ดังนั้นชื่อวงดนตรีที่มีตัวคั่นจะถูกแยกออกโดยไม่ตั้งใจ เช่น กรณีของ AC/DC ที่ทุกคนมักจะพบเจอ ND_SCANNER_ARTISTSPLITEXCEPTIONS คือส่วนที่ใช้ระบุชื่อที่ไม่ควรถูกแยกออก

ไฟล์ใหม่จะถูกตรวจพบโดยตัวเฝ้าติดตามไฟล์ (file watcher) ภายในไม่กี่วินาทีหลังจากถูกเพิ่มเข้ามา ตัวเฝ้าติดตามนี้อาศัยการแจ้งเตือนการเปลี่ยนแปลงจากเคอร์เนล ซึ่งการแจ้งเตือนดังกล่าวจะไม่เกิดขึ้นกับไฟล์ที่เขียนลงบน network share ที่ mount มาจากเครื่องอื่น ดังนั้นในการตั้งค่าลักษณะนี้ การใช้ ND_SCANNER_SCHEDULE ตามรอบเวลาจึงเป็นสิ่งที่ช่วยให้คลังเพลงเป็นปัจจุบันอยู่เสมอ การสแกนใหม่ทั้งหมด (full rescan) จะเป็นการอ่านแท็กของทุกไฟล์ ซึ่งจะทำงานช้าหากคลังเพลงมีขนาดใหญ่ และนั่นคือเหตุผลหนึ่งที่ฐานข้อมูลที่อยู่เบื้องล่างควรได้รับการปกป้องดูแล

ผู้ใช้ เพลย์ลิสต์ และการแชร์

ผู้ดูแลระบบเป็นผู้สร้างบัญชีอื่นผ่านทางเว็บอินเทอร์เฟซ โดยไม่มีระบบให้ผู้ใช้สมัครสมาชิกเอง ผู้ใช้แต่ละรายจะมีจำนวนการเล่น เพลย์ลิสต์ รายการโปรด และการให้คะแนนแยกจากกัน เพื่อไม่ให้สมาชิกในบ้านต้องใช้โปรไฟล์รสนิยมเดียวกัน

เพลย์ลิสต์สามารถมาจากสองช่องทาง เพลย์ลิสต์ที่สร้างในไคลเอนต์จะถูกเก็บไว้ในฐานข้อมูล ส่วนไฟล์ .m3u ที่วางไว้ในโฟลเดอร์คลังเพลงจะถูกนำเข้าในระหว่างการสแกน ซึ่งเป็นวิธีที่ง่ายในการย้ายเพลย์ลิสต์จากโปรแกรมเล่นเพลงบนเดสก์ท็อปมาใช้งาน ส่วนสมาร์ทเพลย์ลิสต์คือไฟล์ .nsp ซึ่งเป็นไฟล์กฎขนาดเล็กในรูปแบบ JSON ที่นำเข้าด้วยวิธีเดียวกันและจะอัปเดตตัวเองโดยอัตโนมัติเมื่อคลังเพลงมีการเปลี่ยนแปลง

การแชร์ถูกเปิดใช้งานเป็นค่าเริ่มต้นตั้งแต่เวอร์ชัน 0.63.0 ซึ่งปล่อยออกมาในเดือนกรกฎาคม 2026 ฟีเจอร์นี้ช่วยให้ผู้ใช้สร้างลิงก์สาธารณะสำหรับอัลบั้มเพื่อให้บุคคลอื่นเปิดดูได้โดยไม่ต้องเข้าสู่ระบบ สำหรับเซิร์ฟเวอร์ที่เก็บคลังเพลงทั้งหมดของคุณ ฟีเจอร์นี้อาจไม่ใช่สิ่งที่คุณต้องการ การตั้งค่า ND_ENABLESHARING ให้เป็น false จะเป็นการปิดใช้งานฟีเจอร์ดังกล่าว

สำรองข้อมูลฐานข้อมูลแยกจากไฟล์เพลง

การสำรองข้อมูลของ Navidrome ครอบคลุมเฉพาะฐานข้อมูลเท่านั้น เอกสารระบุไว้อย่างชัดเจนว่ากระบวนการสำรองข้อมูลจะสำรองเฉพาะฐานข้อมูล ซึ่งหมายถึงข้อมูลผู้ใช้ จำนวนการเล่น และข้อมูลอื่นๆ แต่ไม่ได้สำรองไฟล์เพลงหรือไฟล์ตั้งค่า การแยกส่วนนี้เป็นแนวคิดที่ถูกต้องเนื่องจากข้อมูลทั้งสองส่วนมีความเสี่ยงต่อความเสียหายที่ต่างกัน ไฟล์เพลงสามารถคัดลอกใหม่ได้จากดิสก์ต้นฉบับที่คุณใช้ริปเพลง แต่จำนวนการเล่น การให้คะแนน รายการโปรด และเพลย์ลิสต์ไม่มีอยู่ที่อื่น และการสแกนใหม่ (rescan) ไม่สามารถกู้คืนข้อมูลเหล่านี้ได้

ไฟล์ compose ได้ตั้งค่าให้คัดลอกข้อมูลสำรองรายวันไว้ใน /data/backup โดยเก็บไว้จำนวน 7 ชุด คุณควรสำรองข้อมูลด้วยตนเองหนึ่งชุดก่อนทำการอัปเกรด:

sudo docker compose run --rm navidrome backup create

การกู้คืนข้อมูลจะลบฐานข้อมูลปัจจุบันและคัดลอกไฟล์สำรองไปแทนที่ ดังนั้นจึงต้องดำเนินการในขณะที่ Navidrome หยุดทำงานเท่านั้น การกู้คืนข้อมูลในขณะที่เซิร์ฟเวอร์กำลังทำงานอยู่มีความเสี่ยง

ไฟล์เหล่านี้ยังคงอยู่บน VPS เครื่องเดิม ดังนั้นหาก VPS เกิดความเสียหาย ข้อมูลเหล่านี้จะไม่รอด ให้ส่งข้อมูลใน /srv/navidrome ไปยังเครื่องอื่นหรือที่เก็บข้อมูลแบบ object storage ตามกำหนดเวลา ซึ่งเป็นหน้าที่หลักของ restic และ BorgBackup ไดเรกทอรีทั้งหมดมีขนาดเล็ก โดยปกติจะมีขนาดไม่ถึง 1 กิกะไบต์ ดังนั้นการสำรองข้อมูลที่เข้ารหัสไว้ภายนอกเซิร์ฟเวอร์เป็นประจำทุกวันจึงมีค่าใช้จ่ายเกือบเป็นศูนย์ แต่ช่วยให้คุณกู้คืนข้อมูลทุกอย่างที่การสแกนใหม่ไม่สามารถทำได้กลับคืนมา

FAQ

ฉันจำเป็นต้องแปลงไฟล์เพลงบน VPS หรือไม่?

แทบไม่จำเป็นเลย โทรศัพท์และเบราว์เซอร์สามารถถอดรหัสไฟล์ MP3, AAC, Opus และ FLAC ได้ด้วยตัวเอง เซิร์ฟเวอร์จึงเพียงแค่ส่งไฟล์ไปตามสภาพเดิมโดยแทบไม่ใช้ CPU เลย กรณีเดียวที่ควรเปิดใช้งานคือการสตรีมคลังเพลง FLAC ผ่านเครือข่ายมือถือ ซึ่งการแปลงจากประมาณ 900 kbps ลงมาเป็น Opus ที่ 128 kbps จะช่วยลดปริมาณการใช้ข้อมูลลงได้ประมาณ 7 เท่า Navidrome สามารถตั้งค่านี้แยกตามผู้ใช้และอุปกรณ์ได้ และจะปิดการทำงานไว้จนกว่าคุณจะเปิดใช้งานเอง

ทำไมแอปบนโทรศัพท์ของฉันถึงดาวน์โหลดเพลงเพื่อฟังแบบออฟไลน์ไม่ได้?

เพราะการจัดเก็บข้อมูลแบบออฟไลน์เป็นฟีเจอร์ของฝั่งไคลเอนต์ ไม่ใช่ฟีเจอร์ของเซิร์ฟเวอร์ Subsonic API อนุญาตให้ไคลเอนต์ดึงไฟล์ทั้งไฟล์ได้ แต่ตัวแอปจะเป็นผู้ตัดสินใจว่าจะเก็บสำเนาไว้ในโทรศัพท์หรือไม่ ให้ตรวจสอบรายชื่อไคลเอนต์ที่ navidrome.org/apps แล้วเลือกแอปที่มีคำอธิบายระบุถึงการดาวน์โหลดแบบออฟไลน์หรือการทำแคช ไคลเอนต์บางตัวจะทำแคชเฉพาะเพลงที่คุณเคยเล่นไปแล้วเท่านั้น ซึ่งไม่เหมือนกับการซิงค์อัลบั้มไว้ล่วงหน้าก่อนการเดินทาง

ทำไมอัลบั้มหนึ่งถึงถูกแยกออกเป็นหลายอัลบั้มหลังจากสแกน?

แท็ก album artist หายไปหรือไม่ตรงกันในแต่ละเพลง Navidrome จัดกลุ่มตามแท็กแทนที่จะจัดตามโฟลเดอร์ ดังนั้นเพลง 12 เพลงที่มีค่า artist ต่างกัน 12 ค่าและไม่มีค่า album artist ที่เหมือนกัน จะถูกมองว่าเป็น 12 อัลบั้ม ให้ตั้งค่าแท็ก album artist ให้ครบทุกเพลงในอัลบั้ม โดยปกติจะใช้ค่า Various Artists สำหรับอัลบั้มรวมเพลง แล้วจึงสั่งให้สแกนใหม่ คุณสามารถใช้ MusicBrainz Picard หรือ beets เพื่อจัดการเรื่องนี้ทั้งโฟลเดอร์ในครั้งเดียว

การสตรีมเพลงแบบ self-hosted สามารถแทนที่ Spotify ได้หรือไม่?

มันแทนที่ได้เฉพาะเครื่องเล่นและคลังเพลง แต่ไม่ใช่ตัวแคตตาล็อก คุณจะได้เป็นเจ้าของคอลเลกชันเพลงบนทุกอุปกรณ์ พร้อมด้วยเพลย์ลิสต์และจำนวนครั้งที่เล่น ซึ่งไม่มีการเปลี่ยนแปลงด้านลิขสิทธิ์ใดๆ มาพรากไปจากคุณได้ แต่คุณจะไม่ได้รับเพลงออกใหม่ และไม่ได้รับคำแนะนำเพลงที่สร้างจากพฤติกรรมการฟังของผู้อื่น คนส่วนใหญ่ที่รันระบบนี้มักจะซื้อเพลงของตัวเองและยังคงสมัครบัญชีสตรีมมิ่งราคาประหยัดไว้เพื่อค้นหาเพลงใหม่ๆ