自托管音乐服务器的选择，往往不是看功能列表有多长，而是看它是否贴合你的实际使用方式。Meelo 是一个专注于界面和元数据整合的音乐服务器，近期更新到 v3.12.0，带来了一些新变化。但真正让用户反复讨论的，是多用户个人库、推荐系统以及元数据细节。

Meelo v3.12.0 更新了什么

Meelo 的定位很明确：强调 UI 和元数据整合。它支持重复曲目、歌曲分组（混音、伴奏等）、专辑类型（现场、翻唱、合辑）、音乐视频等。相比一年前的 v3.1.0，这次更新主要带来这些能力：

• 跨平台移动应用，Android APK 可从发布页下载，iOS 通过 TestFlight 公测链接安装；
• 支持本地歌词（内嵌或 .lrc 文件）；
• 使用 OpenCV 人脸检测为视频生成更合理的缩略图；
• 支持唱片公司和地区信息，数据来自 MusicBrainz。

开发者还提到未来会改进非 ASCII 字符名支持、离线下载、Crossfade、Chromecast 以及更多元数据。对于家里有大量音乐档案的用户来说，这些功能仍然是在为“整理”和“发现”服务。

多用户个人库：每个人都想只看自己的部分

不少自托管用户并不是只为自己服务。比如有的用户为妻子、孩子、母亲和几个朋友托管音乐，虽然曲库里没有自己讨厌的歌，但有时只想随机播放自己挑选的部分；有些音乐只是作为归档，不需要出现在智能播放列表或整个曲库随机里。因此，一个被反复提到的需求是：每个用户能够查看完整曲库，但可以单独添加专辑、曲目或艺术家到自己的个人库。

有用户认为这是所有音乐服务器都应该有的基础功能，甚至表示“虽然我很喜欢开源软件，但为了这个功能我愿意付费”。另一个被拿来对比的例子是 Navidrome：管理员可以授予用户只读部分库或全部库的权限，同时支持按库过滤。这意味着“个人库”并不一定需要系统层面拆分，权限控制加客户端过滤就能实现类似效果。

推荐系统：小体量项目最现实的路径是 scrobble

有用户问 Meelo 是否会像 Spotify 或 Plex 那样生成“Discover”或“Library”播放列表。开发者的回答很直接：还没有推荐系统，但支持将收听记录 scrobble 到 ListenBrainz 和 Last.fm，这些服务已经能提供类似推荐。

也有用户从可行性角度分析：像 Meelo 这样的用户量级，很难自己构建音乐推荐。推荐引擎通常依赖数百万用户的收听偏好，提取共性再反馈给个人。如果只从自己的曲库里做选择，数据量远不足以支撑所谓的“智能推荐”。所以 scrobble 到第三方平台，再拿推荐结果回来，反而是更务实的方式。

另一个开发者（来自 mStream 音乐服务器）正在尝试 P2P 音乐发现，让不同服务器之间交换推荐数据。这种跨服务器协作听上去很酷，但离规模化还有距离。

元数据与多艺术家：Meelo 的拿手好戏

元数据整合是 Meelo 的强项之一。开发者强调，只要文件标签正确，一首歌有多个艺术家时，它会出现在所有相关艺术家的页面。官方 wiki 上有关于 “Featuring Artists” 的标签示例。这意味着如果你经常听合作单曲，Meelo 能更好地帮你维持浏览视图的一致性。

这一点对于那些以音乐归档为主的人尤其重要。很多播放器对 multiple artists 的处理很粗暴，只会取第一个；Meelo 的做法更像是数据图，而不是平铺列表。

API 与扩展：Subsonic 兼容的需求仍然存在

讨论中有用户问 Meelo 未来是否会支持 Subsonic API。这很常见，因为客户端生态（如 DSub、Symfonia 等）已经成熟，支持 Subsonic API 意味着可以直接复用很多现有客户端。从开发角度看，这可能需要重新设计很多内部接口，短期内未必能排上日程。

另外，还有别的项目主动提出合作——mStream 的开发者正在开发一个 P2P 音乐发现功能，希望实现跨服务器推荐。这说明不同自托管项目之间的协作与互操作，正在成为新的探索方向。

选择建议

如果你是个人使用或小团队分享，Meelo 的界面和元数据细节会给你很好的体验，但需要准确打标签。如果是家庭多用户场景，而且对“各自收藏”有强烈需求，可以先试试 Navidrome 的权限和库过滤。如果你离不开成熟的客户端生态，那么 Subsonic 兼容可能是优先考虑项。

最后，不管选哪个，音乐服务器都应该以你如何管理和听音乐为核心，而不是为了功能全而全。第三方 scrobble 服务补足推荐，权限过滤补足个人空间，元数据打磨补足发现体验——先想清楚你需要哪一块，再决定上哪辆车。