【宅鯖×音楽ストリーミング】いろいろ試してNavidromeに落ち着いた

「サーバーで動かしているツールを見直そう」プロジェクト第３弾として、今日は音楽ストリーミングサーバーを考えてみようと思います。

現在うちで動いているのは Jerryfin です。 Jerryfinは有名どころのメディアサーバーで、音楽だけでなく動画や電子書籍のストリーミングも可能だったりします。正直言って動画ストリーミングはいらないし、音楽再生までのステップが増えてしまうのでもっとシンプルで省リソースなやつがいいです。

そこでいくつかのセルフホスト音楽ストリーミングサービスを試した結果、結局２番目くらいに有名なNavidromeに落ち着きました。この記事にはそこに至るまでの過程をつづっておきます。

比較
セットアップ

比較

Jerryfin

クリックするとデモにとびます

C#製のメディアサーバーです。

音楽を再生するためにはホームページ→音楽→アルバム…みたいな感じで１個余分なステップが増えるところが気になります。アルバムアートを自動で取得してくれるところは便利でしたが…

CONTAINER ID   NAME              CPU %     MEM USAGE / LIMIT    MEM %     NET I/O           BLOCK I/O        PIDS
9b8bce54a518   jellyfin          0.57%     391.5MiB / 3.88GiB   9.85%     16.1MB / 29.7MB   612MB / 791MB    32

docker statsするとこんな感じ

機能モリモリなせいかメモリ消費がちょっと多めです。常時ちょっとCPUリソースを使ってるのもなんだかなぁといったところ

Koel

クリックするとデモにとびます

リソース消費が多いイメージのあるPHP製

UIがシックでカッコいいです。専用のモバイルクライアント（有料）もあり、開発に力が入っていることが伝わってきます。

CONTAINER ID   NAME              CPU %     MEM USAGE / LIMIT    MEM %     NET I/O           BLOCK I/O        PIDS
f398e655f937   koel              0.01%     58.96MiB / 3.88GiB   1.48%     11.8kB / 45.7kB   467MB / 135kB     9
4f749d1dcd10   koel-redis        0.15%     2.617MiB / 3.88GiB   0.07%     1.61kB / 0B       56.6MB / 0B       5
fc7280d8a128   koel-db           1.40%     357.9MiB / 3.88GiB   9.01%     1.61kB / 0B       137MB / 452MB     37

イメージ通りリソース消費はかなり大きめ。とはいっても大部分はデータベースのようですが。でもJerryfinより多いというのはさすがにちょっと…

Polaris

クリックするとデモにとびます（ユーザー:demo_user / パスワード:demo_password）

軽量かつ高速なイメージの強いRust製

フォルダベースで探せる点が非常に便利です。レスポンスも上々
ただレスポンシブデザインまわりの出来が悪く、スマホで開くと字が豆粒みたいにちっちゃくなり、さらにタップしてもなかなか音楽が再生されません。 Androidだと公式クライアントがあるのでどうにかなりますが、iPhone版は非公式のものしかなく、さらにこれは日本からはダウンロードできないようなのでどうしようもなし。 SubsonicAPI互換でもないのでそのへんのモバイルクライアントも使用できません。これはさすがに厳しい

CONTAINER ID   NAME              CPU %     MEM USAGE / LIMIT    MEM %     NET I/O           BLOCK I/O        PIDS
44840b5fdb94   polaris           0.11%     21.48MiB / 3.88GiB   0.54%     205kB / 52.6MB    392MB / 32.8kB    22

Rust製なだけあってとっても省リソースです。惜しいなぁ

gonic

Go製の音楽配信サーバー、ただしサーバサイドのみなのでブラウザからアクセスしたい場合は別でSubsonicAPI対応のwebクライアントを用意する必要があります。今回は Aonsoku を使用してみました。

使ってみた感想としては…
曲やアルバムの一覧を表示しようとするとワンテンポ遅れる点が気になります。初回だけ遅れるとかそういうわけでもなく、２回目以降も遅れているので普段使いはしたくないかなといった感じ。

CONTAINER ID   NAME              CPU %     MEM USAGE / LIMIT    MEM %     NET I/O           BLOCK I/O        PIDS
078cf6ff803d   gonic_aonsoku     0.00%     6.305MiB / 3.88GiB   0.16%     180kB / 8.04MB    15.3MB / 1.87MB   9
a4abff5f69d4   gonic_gonic       0.01%     17.1MiB / 3.88GiB    0.43%     291kB / 63.7MB    36.6MB / 0B       14

消費リソース自体は非常に軽量なんですがね…

Navidrome

クリックするとデモにとびます（ユーザー:demo / パスワード:demo）

同じくGo製の有名どころ、Navidromeです。

The マテリアルデザイン って感じであんまり趣味ではないですが、使いやすくはありました。

スマホでNavidromeをひらいたところ

スマホ用のレイアウトにも対応しており、バックグラウンド再生が可能なところもよし。

CONTAINER ID   NAME              CPU %     MEM USAGE / LIMIT    MEM %     NET I/O           BLOCK I/O        PIDS
23009210008a   navidrome         0.02%     21.6MiB / 3.88GiB    0.54%     302kB / 19.2MB    95.5MB / 8.19kB   15

リソース消費も文句なしですね。

全体

	CPU	RAM（MiB）
Jerryfin	0.57%	391.5
Koel	1.56%	419.4
Polaris	0.11%	21.5
gonic	0.01%	23.4
Navidrome	0.02%	21.6

全体のリソース消費をまとめるとこんな感じ。 gonicはwebクライアント（Aonsoku）も含めています。

結局、使いやすさと省リソースを両立しているNavidromeを使うことに決めました。

セットアップ

services:
  navidrome:
    image: deluan/navidrome:latest
    container_name: navidrome
    user: 1000:1000
    ports:
      - "50062:4533"
    restart: unless-stopped
    environment:
      - ND_ENABLEINSIGHTSCOLLECTOR=false
      - ND_ENABLESTARRATING=false
    volumes:
      - "./data:/data"
      - "/Volumes/HDD/public/music:/music:ro"

docker-compose.ymlを作成し、音楽フォルダへのパスをよしなに変更して
docker-compose up -d すれば完了です。

一部のmpp3で曲名や歌手の名前が文字化けする現象が起きたので、サクッと修正するための記事を書きました↓

mp3とm4aのメタデータの文字化けをPythonでちゃちゃっと直しちゃおう

アプリなどを作ったりしています! よかったらみていってください→ つくったもの
今のイチオシ↓

DVDプレーヤーの待機画面を再現するアプリをつくったよ