深色模式
R4S 云盘音乐库补全实录：让 Navidrome 自动获取封面与歌词
我的 R4S 已经运行着 OpenList、rclone 和 Navidrome：云盘负责存储，Navidrome 管理曲库，手机用 Tempus 听歌。播放链路已经可用，但曲库里大量专辑没有封面，歌词也不完整。
这次没有重装音乐服务器，而是在现有环境里补齐在线封面和歌词能力。本文记录方案选择、实施过程、遇到的问题、自动运行方式，以及后续维护边界。
先看结果
截至 2026 年 11 月 6 日本轮处理完成时，曲库共有 558 张专辑、6581 条音频记录。已有封面的专辑从 7 张增加到 242 张，新增 235 张；仍有 316 张未匹配。这个数字是一次处理快照，不是每张图片发行版本都经人工确认的准确率。
歌词方面，服务端实测《Bad》《一场游戏一场梦》《晴天》均返回同步歌词。11 月 7 日，我又在 Tempus 实际确认《晴天》可以显示歌词。客户端显示已经验证，其他歌曲仍取决于标签、来源和匹配结果。
整个过程没有改写云盘原音乐，没有清空播放历史、收藏或歌单。原有封面保留，配置和数据库也都留了备份。
现有环境与整体流程
本次环境为 NanoPi R4S、ImmortalWrt 24.10.6、Docker 版 Navidrome 0.64.2，以及 OpenList v4.2.9-lite。音乐通过现有 rclone 挂载提供给 Navidrome，手机播放器为 Tempus。
音乐读取链路是：云盘 → OpenList 与现有 rclone 挂载 → Navidrome 曲库 → Tempus 播放。
封面和歌词是这条链路上的补充能力。它们不负责把音乐加入曲库，也不替代云盘挂载。音乐能否被扫描发现，与能否匹配到封面、歌词，要分别检查。
为什么没有只装 Apple Music 插件
Apple Music 有丰富的专辑资源，但不是唯一来源。中文曲库中存在简繁体、同名歌手、英文与拼音专辑名、唱片公司后缀、分碟编号，以及非标准精选集等情况。仅靠一个来源，覆盖率和匹配质量都会受限制。
最终采用三个封面来源互补，再使用独立的歌词插件。它们均运行在 Navidrome 内部，没有另建一套音乐服务。
| 插件 | 本次版本 | 用途 |
|---|---|---|
| Apple Music | 0.2.0 | 获取专辑封面，仅开启所需能力 |
| Cover Art Archive | 本地修正版 1.0.0+r4s.4 | 通过 MusicBrainz 与 CAA 补充封面 |
| netease-covers | 本地实现 1.0.1 | 补充网易中文专辑封面 |
| nd-lyrics | 8.1.0 | 按需获取和缓存歌词 |
这里要区分来源：netease-covers 是这次维护实现的本地插件，并非网易官方产品；CAA 是基于社区插件修正的本地版本，也不是上游正式发布版本。源码、许可证、构建说明和安装包均已保留。
第一步：检查现状，先备份
安装之前，先确认 Navidrome 版本、容器目录、音乐挂载权限、插件状态和封面统计。现场发现原插件目录为空；歌手图片有部分可用，但这不能证明专辑封面来源可用。
Navidrome 的数据目录需要可写，用来保存数据库、配置、插件与缓存；音乐目录则保持只读。宿主机的云盘挂载和容器内音乐挂载均核对为只读。
数据库使用 Navidrome 自带的在线备份能力创建一致性副本，同时保留原配置、容器定义、原有图片与插件目录。备份完成后检查数据库完整性，并把备份复制到电脑，核对压缩包哈希。
这一步避免了直接复制运行中的 SQLite 数据库可能遇到的一致性问题，也为后续回退保留了依据。
第二步：补全封面来源
Apple Music 插件仅开启专辑图片，关闭本次不需要的资料功能，配置查询地区为 cn、tw、hk、us，并拒绝音乐库写入权限。已有文件夹封面、内嵌封面的优先级保持不变。
CAA 的安装过程则暴露了两个实际问题。
第一，封面服务会跳转到 archive.org 及其存储子域名，原插件权限未包含这些地址，导致有图片也无法读取。修正版只补充必要域名，没有开放任意网络主机。
第二，原插件会把没有专辑、没有正面图等正常未命中当成错误。批量查询后，这会触发来源保护机制。修正版将正常未命中与真实网络故障区分开：找不到就继续尝试其他来源，超时、503 和解析失败仍作为故障处理。同时要求较高的 MusicBrainz 搜索评分，只选正面封面。
进一步处理剩余专辑时，又加入独立的网易封面插件。它同时核对专辑名与歌手名，仅接受网易音乐图片 CDN 地址；找不到就返回未命中，不直接采用第一条无关搜索结果。调试中一个搜索地址在批量运行时返回 405，最终改用实测可用的接口后才保留为安装版本。
CAA 与网易属于独立来源，因此一个来源的故障不会直接停掉另一个来源。
第三步：处理旧曲库，避免错误配图
为旧曲库增加来源后，不能假定重新打开页面就会重查所有缺图专辑。已经被 Navidrome 判定为“没有封面”的记录，需要主动刷新。
本次先筛选缺图候选，排除明显未知标签、混杂歌手以及高风险自制精选，再让后台任务批量查询。遇到唱片公司后缀、CD 编号和少量版本附注时，仅在搜索请求中做保守处理，不修改原文件或曲库显示标签。
例如，“七里香最新精选CD1”不能直接被当成正式专辑《七里香》。实际处理中曾出现这种近似匹配，随后撤回该单张缓存，并将其排除在后续候选之外。没有为了撤回一张图片而恢复整库。
后台处理采用单并发和限速，避免让 R4S 同时发起大量外部请求。第一阶段达到 118 张封面，第二阶段达到 242 张，并核对第一阶段已有的 118 张图片哈希和来源全部保留。
最终来源分布为：网易 57 张、Apple 106 张、CAA 68 张、内嵌 7 张、文件夹 4 张。它们说明多来源补充有效，但不能代表所有非标准专辑都已被准确识别。
第四步：启用按需歌词
歌词使用 nd-lyrics，优先读取已有本地或内嵌歌词，再依次尝试网易、LRCLIB、QQ。配置保留 3 秒的时长匹配范围，开启本机缓存，关闭歌词文件写入与覆盖，并拒绝音乐库写权限。
这意味着歌词可以显示在播放器里，却不会被写回云盘音频或自动在云盘旁生成歌词文件。获取失败的结果也有短期缓存，避免重复请求同一首没有结果的歌曲。
验证分为两步。先用临时普通账号调用真实 OpenSubsonic 接口，确认三首测试歌曲能得到同步歌词数据，测试后删除账号；再由手机上的 Tempus 实际验证。《晴天》已确认能显示歌词。
插件显示“已启用”只能证明安装状态，接口成功也不能直接替代手机显示验收，两层验证都需要考虑。
这些封面和歌词是手动获取的吗
不是逐张下载封面，也不是手工复制歌词。人工完成的是方案选择、插件配置、修复问题、给旧曲库启动补全任务，以及抽样核对结果。实际搜索、匹配、下载和缓存由 R4S 上的程序执行。
后续新增专辑被 Navidrome 扫描发现、进入封面处理流程后，会自动尝试配置好的来源并缓存结果。Tempus 请求歌词时，服务端自动读取本地歌词或查询在线来源，再把结果返回客户端。
这些能力不依赖维护电脑一直开机，也不依赖聊天窗口继续运行。正常听歌不需要每次找人操作。
不过，自动获取不等于无限重试。当前版本对已经确定没有封面的记录，需要主动刷新才会重新尝试；网络故障会按后台规则重试。反复打开页面不会可靠地重查所有旧缺图记录，本次也没有另装定时全库刷新任务。
新增音乐还必须先被曲库扫描发现。本次没有改变原来的扫描安排，“云盘新增歌曲到 Tempus 自动出现”的完整流程仍待单独验证，不能因为歌词成功就认为这一环也已确认。
为什么还有 316 张专辑没有封面
在线来源没有收录只是原因之一，剩余项目还包括标签不完整、整轨文件、非标准精选集，以及多个真实专辑被归入同一未知条目的情况。
曲库中一个未知专辑条目包含 711 条音频记录，抽样可见 WAV、APE 和 CDImage.wav。面对这种数据，目录名称可能提供线索，但不能给整个未知条目统一套一张封面，也不能把整轨直接当作普通单曲处理歌词。
这类问题应先恢复专辑和歌曲身份，再考虑匹配。为追求覆盖率强配图片，反而会降低曲库的可信度。
备份、回滚与维护
本次保留了修改前、第二阶段开始前以及最终安装状态的备份。最终备份包含一致性数据库、配置、插件包和本地插件源码，不包含全部音频，也不等于完整音乐库备份。
普通插件回退应先禁用新插件、恢复对应配置和插件包，再按需要重载或重启 Navidrome。已缓存的封面不一定会立刻消失，不应直接清空整个图片目录。
整库恢复只作为最后手段，因为它可能覆盖备份之后新增的播放记录、收藏和歌单修改。不能把“有备份”理解为可以随意覆盖运行中的数据库。
自动获取也不等于插件自动维护。本地修正版没有配置自动升级；外部接口变化或插件不再兼容时，仍可能需要维护。但这是偶发的软件维护，不是每首歌都要人工处理。
接下来最值得做的是验证新增歌曲的完整入库链路，再核实定期备份和恢复流程，最后逐类整理剩余缺图专辑。临时登录凭据也应结束使用，并在验证新登录方式可用后完成替换。这些属于后续事项，不作为本轮已完成成果。
参考资料
本文为特定环境下的实施记录。插件版本、接口行为和数量统计均对应本次维护时的状态；本地修正版不能视为上游原版直接安装后的效果。