单曲下载不用Lidarr：自建音乐下载容器实战方案

引言：Arr 全家桶的最后一块拼图

在自托管（Self-hosted）媒体服务器的世界里，"Arr" 全家桶早已成为标准配置：Sonarr 管理剧集、Radarr 管理电影、Prowlarr 统一索引器。Arr 全家桶是指一系列以 'arr' 结尾命名的开源自动化媒体管理工具，它们共享相似的架构设计和 UI 风格，均基于 .NET 开发。这个生态的起源是 2012 年诞生的 Sonarr（最初名为 NzbDrone），随后社区成员 fork 出针对不同媒体类型的变体：Radarr（电影）、Lidarr（音乐）、Readarr（电子书）等。Prowlarr 则作为统一的索引器管理层，将 Torrent 和 Usenet 索引站点的配置集中管理，免去在每个 Arr 应用中重复配置的麻烦。这些工具通常运行在 Docker 容器中，通过 API 相互通信，配合下载客户端（如 qBittorrent、SABnzbd）形成完整的自动化媒体获取流水线。

然而当用户想要补齐音乐下载能力时，往往会遇到意想不到的阻力。

近期一位 Reddit 用户分享了自己的困境：他希望为 Arr 技术栈补齐音乐下载能力，但主流方案 Lidarr 并不能满足需求。他的核心诉求非常明确——只想下载单曲或精选曲目，而非整张专辑，同时需要支持印度语系歌曲，并且拒绝为某个歌手"订阅"全部作品。

这个看似简单的需求，触及了自建音乐库工具生态的一个痛点。本文将围绕这一真实案例，梳理当前可行的容器化单曲下载方案。

为什么 Lidarr 不适合单曲下载

Lidarr 的设计哲学：以艺术家为中心

Lidarr 作为 Arr 家族的音乐成员，其设计初衷是以艺术家为中心的音乐库管理。当你添加一位歌手后，它会持续监控该歌手的整个作品目录（Discography），自动抓取新专辑、补全缺失专辑。这种"全量订阅"模式非常适合建立完整的音乐收藏库。

但正如这位用户指出的，这恰恰是问题所在：

• 以专辑为最小下载单位，很难做到只下载某张专辑里的一两首歌
• 持续跟踪机制意味着你必须"关注"整个艺术家，而不是随手抓一首喜欢的歌
• 对非主流曲库支持有限，MusicBrainz 元数据库对印度等区域性音乐的覆盖存在盲区

Lidarr 深度依赖 MusicBrainz 来识别艺术家、专辑和曲目信息。MusicBrainz 是一个开放的音乐元数据数据库，类似于音乐界的维基百科，由社区志愿者维护。虽然 MusicBrainz 收录了超过 200 万名艺术家和 3000 万首录音，但其覆盖度存在明显的地域偏差：英语系和西欧音乐的元数据非常完善，而南亚（如印地语、泰米尔语、泰卢固语）、东南亚等地区的音乐条目则相对稀疏，许多区域性歌手和专辑缺乏完整的元数据记录。这直接导致 Lidarr 在处理这些地区的音乐时无法正确识别和匹配。

需求错配的本质

简单来说，Lidarr 解决的是"如何系统化建立音乐图书馆"，而该用户想要的是"如何快速抓取几首指定歌曲"。这是两种完全不同的使用场景，用管理专辑收藏的工具去做单曲抓取，自然处处受限。

已尝试方案的踩坑记录

Soulseek（slskd）：资源丰富但部署门槛高

用户提到尝试了 Soulseek（基于 P2P 的音乐分享网络），但体验不佳：

• 反向代理配置困难：将 slskd 部署在 Nginx 后面时配置过程繁琐
• 使用逻辑不直观：P2P 网络的下载方式与"搜索即下载"不同，容易报错
• 稳定性问题：各种操作频繁出错

Soulseek 是一个诞生于 2001 年的 P2P 文件共享协议，专注于音乐分享。与 BitTorrent 不同，Soulseek 采用中心化服务器协调 + 点对点直连传输的混合架构：用户通过中央服务器搜索其他用户共享的文件列表，但实际文件传输在两个客户端之间直接进行。slskd 是 Soulseek 协议的现代化 Docker 实现，提供 Web UI 和 REST API。然而由于 Soulseek 协议需要建立入站连接来接受下载请求，当部署在反向代理后面时需要额外配置端口转发和 WebSocket 支持，这正是用户遇到部署困难的技术根源。

Soulseek 的确是音乐爱好者眼中的宝库，尤其稀有曲目资源丰富，但学习曲线陡峭，不适合追求开箱即用的用户。

Spotiflac：移动端好用但 Docker 部署困难

另一个被提及的项目是 Spotiflac。用户对其移动应用赞誉有加，称"手机 App 体验非常好"，但在容器化部署上反复受挫。

这揭示了自托管领域的普遍现象：很多优秀的音乐下载工具在原生应用上打磨得很好，但 Docker 化的部署文档和镜像质量参差不齐，导致自建用户难以复现移动端的良好体验。造成这一现象的原因在于，许多音乐下载工具最初是为桌面或移动端设计的，容器化往往是社区后期添加的功能，缺乏与主项目同等的测试和维护投入。

可行的单曲下载替代方案

基于流媒体元数据的下载工具

针对"只要单曲、支持多语种"这一需求，以下方案值得重点关注：

• spotDL 等 Spotify 元数据下载器：允许直接粘贴单曲或歌单链接，按需下载指定曲目，天然支持全球曲库（包括印度歌曲）。多数提供命令行接口，也有社区维护的 Docker 镜像。

spotDL 的工作原理是将 Spotify 作为元数据源、YouTube Music 作为实际音频源的"桥接"策略。具体流程为：首先通过 Spotify Web API 获取歌曲的元数据（标题、艺术家、专辑、时长等），然后利用这些信息在 YouTube Music 上搜索匹配的音频，最后使用 yt-dlp 下载音频并用 mutagen 库嵌入正确的 ID3 标签和封面。由于 Spotify 的曲库覆盖全球 184 个市场（包括印度），其元数据对区域性音乐的支持远优于 MusicBrainz。spotDL 支持单曲链接、歌单链接、专辑链接等多种输入格式，天然适合按需下载场景。

• 基于 Deezer 的抓取方案：类似思路，利用 Deezer API 获取元数据并匹配音源，对多语种音乐覆盖较好。Deezer 在印度和中东等市场有较强的本地化曲库，某些工具可以直接从 Deezer CDN 获取 FLAC 质量的音频流，音质上限高于 YouTube 音频提取方案。

YouTube 音频提取方案

借助 yt-dlp 类工具，可以从视频平台精准抓取单首歌曲的音频。yt-dlp 是 youtube-dl 的活跃分支（fork），由社区持续维护，支持从 YouTube、Bilibili 等上千个视频平台提取媒体内容。在音乐下载场景中，yt-dlp 通过 '--extract-audio' 参数可以直接提取视频中的音频流，并借助 FFmpeg 转码为 MP3、FLAC、Opus 等格式。

对于区域性音乐（如印地语、泰米尔语歌曲），视频平台的覆盖度往往比专业音乐数据库更全。以印度市场为例，T-Series（印度最大音乐厂牌）是 YouTube 全球订阅量最高的频道之一，几乎所有宝莱坞和区域语言歌曲都有官方音频/MV上传。配合 '--embed-metadata' 和 '--embed-thumbnail' 参数，yt-dlp 还能自动嵌入元数据和封面，使下载的音频文件在播放器中呈现完整的信息展示。配合 Web UI 封装项目使用，体验更佳。

轻量级 Web UI 封装项目

一些开源项目为上述命令行工具套上了简洁的网页界面，支持搜索、点选、下载单曲，更贴近"只下我要的"使用体验，同时容器化部署也相对成熟。这类项目通常采用前后端分离架构：前端提供搜索和队列管理界面，后端封装 spotDL 或 yt-dlp 的命令行调用，并通过 Docker Compose 一键部署，大幅降低了非技术用户的使用门槛。

容器化部署的关键考量

对于希望完善 Arr 栈的用户，选择音乐下载工具时应重点关注以下维度：

1. 下载粒度：确认工具支持单曲级别抓取，而非强制整专辑下载
2. 元数据来源：选择依托全球流媒体元数据（而非仅 MusicBrainz）的方案，保证印度等区域音乐覆盖
3. Docker 镜像成熟度：优先选择有官方或高质量社区 Docker 镜像、文档完善的项目
4. 反向代理兼容性：提前确认工具对 Nginx subpath 或子域名的支持情况
5. 与现有栈的集成：考虑下载后的文件组织是否能与 Navidrome、Jellyfin 等播放器无缝衔接

关于反向代理兼容性，这是自托管场景中的核心考量点。反向代理（通常由 Nginx、Caddy 或 Traefik 承担）负责 SSL 终止、路径路由和访问控制。许多自托管应用在反向代理后运行时会出现问题，常见原因包括：WebSocket 连接未正确转发（导致实时状态更新失败）、应用硬编码了根路径 '/' 导致 subpath 部署时资源加载 404、CORS 头未正确传递等。评估一个 Docker 化应用是否适合自托管时，成熟的项目通常提供 BASE_URL 或 SUBFOLDER 环境变量，并在文档中给出 Nginx/Caddy 的示例配置片段。

总结：选对工具比硬凑技术栈更重要

这个案例给自托管爱好者的最大启示是：不要为了统一技术栈而强行使用不匹配的工具。Lidarr 是优秀的音乐库管理器，但它不是单曲下载器。

当核心需求是"精准抓取单首歌曲、支持多语种、无需长期订阅艺术家"时，与其在 Lidarr 上苦苦调试，不如转向 spotDL、yt-dlp 等专门为单曲下载设计的工具。同时在评估方案时，容器化部署的成熟度应当作为硬指标——一个再好用的应用，如果 Docker 镜像难以驯服，对自托管场景就是巨大的隐性成本。

完善 Arr 全家桶不是目的，满足实际听歌需求才是。选对那块拼图，整个自建媒体技术栈才算真正跑通。