autobrr团队推出Librrary：整合影视管理的Sonarr/Radarr替代方案

自助媒体服务器爱好者熟悉的Sonarr和Radarr，可能即将迎来一个强有力的竞争者。开发出autobrr和qui的团队近日在其Discord频道宣布了新项目——Librrary，一款将电影和电视剧管理整合到单一应用中的"arr"替代方案。项目目前尚未正式发布，但团队表示已经接近用户测试阶段。

为什么需要又一个媒体管理工具

Sonarr（电视剧）和Radarr（电影）长期以来是自动化媒体库管理的事实标准。但按官方说法，它们"在需求简单时工作良好"——问题恰恰出在需求变复杂之后。

团队指出了一个真实的痛点：一旦用户既想维护HD库又想维护4K库，就需要运行多个实例，还要处理它们之间的同步问题。现实中，不少用户为了满足需求会同时运行4到6个arr实例。这意味着更多的管理成本、更高的资源占用，以及对索引器（indexer）更频繁的请求。

考虑到这些实例之间存在大量重复功能，将电影和电视剧合并到一个应用中确实是合理的思路。这也是Librrary的核心出发点：用一个应用覆盖多种内容类型，减少冗余。

对不熟悉这个生态的读者来说，"arr"是一系列以"-arr"结尾命名的开源自动化工具的统称，起源于Sonarr（2014年）和Radarr，此后衍生出Lidarr（音乐）、Readarr（书籍）、Prowlarr（索引器管理）等。它们的共同工作方式是：监控用户设置的媒体愿望清单，自动在Torrent或Usenet索引器上搜索匹配的资源，调度下载客户端完成抓取，再将文件整理归档到媒体库目录。这套流程高度自动化，但每个arr实例只负责单一内容类型，且只能对应一套质量规则。当用户希望同时维护"普通1080p库"和"4K HDR库"时，由于无法在同一实例内区分存放路径和质量配置，唯一的解法就是运行两个独立实例，由此带来的配置同步和资源开销问题也就随之而来。

Librrary计划提供哪些功能

根据团队公布的信息，Librrary在架构设计上明显借鉴了Plex的多媒体库概念，同时保留了arr生态用户熟悉的工作流。

已确认构建中的核心特性

• 按内容类型划分的多媒体库：类似Plex，每个标题可拥有多个变体（1080p、2160p、remux、Dolby Vision），从根本上解决了HD/4K需要多实例的问题。
• arr风格的质量配置与发布评分规则：对应Sonarr/Radarr用户熟悉的Custom Formats机制。
• Torrent与Usenet双支持：通过Torznab/Newznab协议接入，仍需搭配Prowlarr或Jackett等索引器管理工具。
• 用户角色与OIDC登录：具备较完善的权限体系。
• 数据库灵活性：支持SQLite或PostgreSQL。
• 通知集成：兼容Notifiarr、Discord、Telegram等常用服务。
• 列表（Lists）支持。

技术栈方面，Librrary采用Go后端 + React前端，提供Docker镜像以及Linux、macOS、Windows的二进制文件，跨平台部署友好。

Torznab和Newznab是两种标准化的索引器查询协议。Newznab最初为Usenet NZB索引站设计，定义了一套通用的搜索API；Torznab则是由Jackett项目在此基础上扩展而来，将同样的接口规范适配到BitTorrent索引器。二者的存在使得下载管理工具无需为每个索引站单独开发对接代码——只要索引站或聚合工具（如Prowlarr、Jackett）暴露符合协议的端点，任何兼容客户端即可通用接入。Prowlarr在arr生态中承担的正是"索引器中枢"角色：统一管理所有索引器的认证和配置，再将其同步推送给Sonarr、Radarr等下游工具，避免每个arr实例都单独维护一份索引器列表。Librrary延续这一架构，意味着现有Prowlarr用户的索引器配置可以平滑复用。

路线图透露的野心

除了当前构建的功能，团队公布的路线图更能反映这个项目的定位——它不只想做一个"合并版arr"，而是希望覆盖更完整的媒体生命周期。

路线图中值得关注的几点：

• 内置请求功能：配合强大的用户角色访问系统，可能替代Overseerr/Jellyseerr一类的请求工具。
• 从Sonarr和Radarr导入：降低现有用户的迁移门槛，这是能否成功的关键一环。
• 可选的手动升级审批。
• "Trump handling"（被标记/nuke资源处理）：监控种子客户端的trumped/nuked tracker消息，并接收来自qui等外部工具的webhook——这体现了团队在私有Tracker场景下的经验。
• 潜在的Plex、Jellyfin等媒体服务器集成，甚至包括"观看后删除"的完整闭环（请求、下载、导入、观看、删除）。

团队特别强调Librrary采用模块化设计，未来可能扩展出专门的动漫处理、书籍和音乐支持，但当前阶段优先聚焦电影和电视剧。

"Trump handling"（国内有时译为"被trump/nuke处理"）是私有Tracker社区的特有概念。当一个已发布的资源被发现存在质量问题（如音轨错误、假冒格式标注、编码瑕疵），Tracker管理员会将其标记为"trumped"或"nuked"，表示该资源已被更高质量的版本取代或被判定不合规。对自动化下载工具而言，如果不能感知这类状态变更，就可能持续保留劣质资源或错过应当触发替换下载的时机。autobrr的前身工具在私有Tracker的IRC announce频道集成方面有深厚积累，qui同样聚焦于Tracker交互自动化，因此Librrary将这一功能纳入路线图，体现了团队针对重度私有Tracker用户的差异化定位。

值得关注但仍需观望

Librrary的思路切中了arr生态多年积累的实际痛点，尤其是多实例管理的复杂性。有autobrr和qui的开发经验背书，团队在自动化下载和Tracker交互方面有一定积累，这让项目的可信度高于普通的"造轮子"尝试。

不过需要冷静看待的是，项目目前尚无发布日期，甚至还没进入公开用户测试。Sonarr和Radarr经过多年迭代，拥有庞大的社区、成熟的生态和海量的边缘案例处理能力，新工具要真正撼动它们的地位并不容易。从Sonarr/Radarr导入的兼容性、长期维护的可持续性，都将是决定成败的关键。

感兴趣的用户可以前往官网 librrary.app 订阅最新消息。项目采用赞助模式支持开发，这也是自托管开源软件常见的运作方式。至于它能否成为下一个自建媒体库标配，还需要等待实际的测试版本来验证。