群晖 NAS 自建 Navidrome 音乐服务,移动端首推音流

群晖 NAS 自建 Navidrome 音乐服务,移动端首推音流
Photo by Jefferson Santos / Unsplash

作为一名普通的 NAS 用户,我一直梦想拥有一个属于自己的本地音乐库,既能满足家庭影音需求,又能在移动设备上随时随地享受高品质音乐。在尝试过 Jellyfin、Emby 和 Plex 等媒体服务器后,我发现它们虽然功能强大且界面美观,但更适合视频播放,音乐功能显得有些“鸡肋”。为此,我一直在寻找一款专注于音乐的解决方案,直到发现了开源音乐服务器软件 Navidrome,并搭配国人开发的移动端播放器 音流,才真正实现了我的音乐库理想。以下是我在群晖 NAS(DS220+,DSM 7.2.1,Docker Compose 版本 2.25.0)上部署 Navidrome 的完整过程,以及使用音流的心得,分享给有同样需求的朋友。

为什么选择 Navidrome?

Navidrome 是一款轻量级的开源音乐服务器,支持 Subsonic/Madsonic/Airsonic 等音乐流媒体协议,可以轻松管理和播放你的音乐库。虽然它的网页端界面基于 Material Design,但在移动设备上的体验稍显不足,缺乏原生 App 支持,歌词功能也仅限于内嵌歌词,暂时不支持外挂 LRC 文件。此外,大部分支持 Subsonic 协议的播放器缺乏中文支持,使用起来不够友好。这些问题一度让我对 Navidrome 望而却步。

然而,最近在网上冲浪时,我被群友安利了一款国人开发的音乐播放器 音流。这款 App 界面简洁、符合国人审美,支持 Subsonic 协议,且能完美适配 Navidrome。更重要的是,音流解决了歌词显示和移动端操作的痛点,让 Navidrome 的体验大幅提升。因此,我决定在群晖 NAS 上部署 Navidrome,并搭配音流打造一个好用的本地音乐库。

部署 Navidrome

以下是具体的部署步骤,基于我的 DS220+ 和 DSM 7.2.1 系统。

1. 准备工作

首先,我在 NAS 的 docker 文件夹下创建了一个名为 navidrome 的文件夹,并在其中新建一个 data 子文件夹,用于存储 Navidrome 的配置文件和数据库。

接着,我整理好自己的音乐文件,上传到 NAS 的 /volume1/media/music 路径,并记下这个完整路径。确保你的音乐文件已经整理好,建议为音乐添加 ID3Tags(参考 MusicBrainz 相关指南),这样 Navidrome 能更好地识别和展示音乐信息。

为了安全起见,官方不建议使用 root 用户运行容器。我通过 SSH 登录 NAS,输入以下命令查询了我的群晖管理员用户 ID:id Fuuqiu

输出结果为:

uid=1026(Fuuqiu) gid=100(users) groups=100(users),101(administrators),65537(docker)

因此,我决定在 Docker 配置中使用 1026:100 作为运行用户。如果你不想查询,也可以直接使用默认的 1000:1000。

2. 创建 Docker Compose 文件

我在电脑上创建了一个名为 compose.yaml 的文件,内容如下:

docker-compose.yaml

services:
  navidrome:
    image: deluan/navidrome:latest
    container_name: navidrome
    user: 1026:100
    ports:
      - 4533:4533
    volumes:
      - ./data:/data
      - /volume1/media/music:/music:ro
    environment:
      - ND_DEFAULTLANGUAGE=zh-Hans
      - ND_ENABLEGRAVATAR=true
      - ND_ENABLETRANSCODINGCONFIG=false
    restart: unless-stopped

这份配置文件中,我设置了以下关键参数:

  • image: 使用官方最新的 Navidrome 镜像。
  • user: 指定运行用户为 1026:100。
  • ports: 映射 NAS 的 4533 端口到容器内的 4533 端口(可根据需要修改左侧端口,避免冲突)。
  • volumes: 挂载 NAS 的音乐文件夹 /volume1/media/music 到容器内的 /music(只读模式),并将 ./data 映射到 /data 用于存储配置。
  • environment: 设置默认语言为中文(zh-Hans),启用 Gravatar 头像,禁用转码以节省资源。

如果你希望 Navidrome 显示歌手头像或简介,可以进一步配置 Spotify 和 Last.fm 的环境变量。需要先注册 Spotify 和 Last.fm 账户,创建应用获取 API 密钥,并填入 ND_SPOTIFY_ID、ND_SPOTIFY_SECRET、ND_LASTFM_APIKEY 和 ND_LASTFM_SECRET。具体步骤可参考 Navidrome 官方文档。由于我的网络环境无需代理,我没有配置 HTTP_PROXY 和 HTTPS_PROXY。

3. 部署容器

在 DSM 的 Container Manager 中,我点击左侧的“项目”,选择“新建项目”,项目名称设置为 navidrome,并选择之前创建的 /docker/navidrome 文件夹作为路径。然后,我点击“创建 docker-compose.yml”,将上述 compose.yaml 内容粘贴进去,点击“完成”并启动容器。整个过程非常顺利,无需额外配置网页门户。

使用 Navidrome

容器启动后,我通过浏览器访问 http://<NAS_IP>:4533,Navidrome 提示我创建管理员账户。由于已经在环境变量中设置了默认语言为中文,界面直接显示为中文,省去了手动切换的麻烦。

Navidrome 的音乐管理非常简单,只要音乐文件有正确的 ID3Tags,它就能自动识别艺术家、专辑和歌曲信息。如果配置了 Spotify 和 Last.fm,艺术家页面会显示头像、简介和热门歌曲等信息。即使没有 Last.fm,也可以在个性化设置中启用“Last.fm 喜好记录”,通过授权 Last.fm 账户记录播放历史,实时查看正在播放的音乐。

不过,Navidrome 的歌词支持确实是个短板。目前它只支持内嵌歌词,且显示效果不佳(例如双语歌词无法分行显示)。这也是我强烈推荐搭配音流的原因。

音流:让 Navidrome 更好用

音流是一款由国人开发的音乐播放器,支持 Subsonic 协议,完美适配 Navidrome。它采用 Flutter 开发,界面简洁美观,以透明和高斯模糊为设计特色,布局类似网易云音乐,上手毫无门槛。目前音流支持 Android 和 iOS,未来可能推出 Windows 和 tvOS 版本。我在 iOS App Store 搜索“音流”直接下载安装,Android 用户可以访问音流官网获取安装包。

配置音流

音流的配置非常简单:

  1. 打开音流 App,输入 Navidrome 的地址(例如 http://<NAS_IP>:4533)、用户名和密码。
  2. 登录后,音流会自动扫描音乐库(如果音乐较多,可能需要稍等片刻)。
  3. 扫描完成后,首页会展示最新专辑、每日推荐、最近播放、最常播放和随机专辑等内容。

音流的亮点

音流让我最惊喜的功能是 主备线路切换。我将内网地址(http://<NAS_IP>:4533)设为主线路,外网地址(通过 DDNS 或反向代理配置)设为备用线路。音流会根据网络环境自动切换,出门时用外网,回家后切回内网,切换过程中音乐播放不会中断,体验非常流畅。

此外,音流的播放页面支持左滑查看推荐歌曲,右滑显示歌词。它能正确解析内嵌歌词,并以双语上下两行显示,弥补了 Navidrome 歌词显示的不足。首页的“每日推荐”功能会随机提供 50 首歌曲,还可以一键刷新,非常适合发现新歌或切换心情。

缺点

  • 1.无法通过 Web 界面上传歌曲:Navidrome 不提供内置的上传功能,用户无法通过其 Web 界面或客户端直接上传音乐文件。必须手动将歌曲复制到指定的音乐文件夹(如 /music),或使用第三方工具(如 Filebrowser、SMB、FTP)进行上传。这种额外的步骤增加了操作复杂性,尤其是对非技术用户不友好。
  • 2.不支持直接删除歌曲:Navidrome 无法通过 Web 界面或 API 删除音乐文件。用户需要手动进入主机文件系统或通过第三方文件管理工具删除音乐文件夹中的文件,之后还需触发库扫描以更新数据库。这种分离的文件管理流程不够直观,且可能导致库与实际文件不一致的风险。
  • 3.文件管理依赖外部工具:由于缺乏内置文件管理功能,用户需依赖外部工具(如 Filebrowser、Miniserve 或 NAS 文件管理)来完成上传、删除或重命名等操作。这不仅增加了部署复杂性,还可能引入额外的安全配置需求(如权限管理、端口暴露)。
  • 4.库扫描效率问题:文件添加或删除后,Navidrome 需要扫描音乐文件夹以更新库。扫描过程可能较慢,尤其当音乐库较大或文件元数据复杂时。自动扫描(通过 ND_SCANSCHEDULE)可能导致资源占用过高,而手动扫描又需用户主动操作,影响体验。
  • 5.不支持动态文件夹分配:Navidrome 的音乐文件夹路径在配置文件中固定,无法为不同用户分配不同的音乐文件夹。这限制了多用户场景下的灵活性,所有用户共享同一库,难以实现个性化的文件管理。
  • 6.对文件系统权限敏感:Navidrome 要求音乐文件夹具有正确的读写权限(尤其是上传/删除时需 :rw 挂载)。若权限配置错误(如只读挂载或用户权限不足),可能导致扫描失败或文件无法更新,增加了维护难度。
  • 7.缺乏批量文件管理功能:Navidrome 不支持批量编辑或整理音乐文件(如批量重命名、移动或删除)。用户必须依赖外部工具处理文件结构或元数据(如使用 music-tag),这对于大规模音乐库的管理效率较低。
  • 8.有限的客户端支持:虽然 Navidrome 兼容 Subsonic API,但部分客户端(如某些移动端应用)可能无法完全利用 Navidrome 的功能,且客户端本身也无法直接上传或删除歌曲,进一步限制了文件管理的便捷性。

总结

通过在群晖 NAS 上部署 Navidrome,我成功搭建了一个功能强大的本地音乐库。Navidrome 轻量、开源,支持多用户和流媒体协议,管理音乐简单高效。虽然它的网页端和歌词支持有一定局限,但搭配音流后,这些问题都迎刃而解。音流不仅界面美观、操作便捷,还通过主备线路切换和完善的歌词显示提升了移动端体验。

如果你也有一台群晖 NAS,并且希望打造一个专属的音乐库,我强烈推荐尝试 Navidrome + 音流的组合。无论是家中还是外出,你都能随时享受高品质的音乐,真正实现“我的音乐,随身携带”。

Read more

Cloudflare Shared Dictionaries 现在值得试吗?我按官方 demo 跑了一次,先给频繁发版团队一个判断

Cloudflare Shared Dictionaries 现在值得试吗?我按官方 demo 跑了一次,先给频繁发版团队一个判断

Cloudflare Shared Dictionaries 现在值得试吗?我按官方 demo 跑了一次,先给频繁发版团队一个判断 如果你的网站或 Web 应用每天会发很多次前端 bundle,而且每次改动都不大,那么截至 2026-04-29,Cloudflare Shared Dictionaries 已经值得进测试名单,但还不值得当成“所有站点都该立刻上的通用优化项”。它真正解决的不是传统 gzip / Brotli 不够强,而是“你明明只改了一小段配置,用户却要重新下载整包”的高频发版浪费。 我这轮没有只看 Cloudflare 的发布文。我直接按官方 demo 给的 curl 流程跑了一次 canicompress.com:同一类约 93KB 的 JavaScript 资源,普通 gzip 传输了 22,423B,带共享字典的

By One AI
OpenAI Privacy Filter 适不适合拿来做脱敏 Web 应用?我实测后给出的判断

OpenAI Privacy Filter 适不适合拿来做脱敏 Web 应用?我实测后给出的判断

OpenAI Privacy Filter 适不适合拿来做脱敏 Web 应用?我实测后给出的判断 Article type: take 我先说结论:如果你要做的是文档高亮审阅、截图脱敏,或者“把一段敏感文本变成可分享的脱敏版本”这类入口,OpenAI Privacy Filter 已经值得拿来做原型;但如果你要的是可审计、字段级强约束、对中文或行业术语有稳定召回的生产脱敏链路,先别把它当成“一接就上”的成品。 这里说的 OpenAI Privacy Filter,当前准确指的是 Hugging Face Hub 上的 openai/privacy-filter 模型卡 和围绕它做的公开 demo,不是一个“在 OpenAI 控制台里点一下就开的 API 开关”。这个命名边界要先讲清,否则后面的部署、成本和数据路径都会判断错。 我这轮没有只看发布文。

By One AI
Telegram 无代码做 AI Bot?Managed Bots、BotFather 和真实门槛一次讲清

Telegram 无代码做 AI Bot?Managed Bots、BotFather 和真实门槛一次讲清

Telegram 无代码做 AI Bot?Managed Bots、BotFather 和真实门槛一次讲清 Article type: tutorial Voice: operator 如果你在 X 上看到“Telegram 现在支持无代码做 AI Bot”的说法,先别急着把它理解成“一键生成完整 AI Agent”。Telegram 这次真正开放的是 Managed Bots:它让一个管理 bot 可以替用户创建、接管并后续管理新的 bot。 这篇只讲 Managed Bots 这条官方创建与接管链路怎么跑通,不把“模型、知识库、状态管理、计费和运维”混进来。换句话说:这不是“AI bot 全栈教程”,而是“

By One AI
GitHub 的 Python dependency graph 现在更完整了?先按这份清单判断你的 SBOM 盲区还剩多少

GitHub 的 Python dependency graph 现在更完整了?先按这份清单判断你的 SBOM 盲区还剩多少

GitHub 的 Python dependency graph 现在更完整了?先按这份清单判断你的 SBOM 盲区还剩多少 Article type: tutorial Voice: operator 我先拿一个最小 Python 项目跑了一遍:requirements.txt 里只有一行 requests==2.32.3,但实际解析出来的安装树里,除了 requests,还会带出 charset-normalizer、idna、urllib3、certifi 这 4 个间接依赖。也就是说,如果你的视角还停在 manifest 层,SBOM 往往从第一步就已经不完整了。 先说结论 如果你的团队主要维护 Python 服务、内部工具或自动化脚本库,现在值得重新看一眼 GitHub 的 Python

By One AI
Follow @Fuuqius