Ombi中Plex Watchlist重复请求机制的技术解析与优化方案

问题背景

在Ombi与Plex Watchlist的集成使用场景中，用户反馈存在一个关键性问题：当某个影视内容被完整删除后，系统无法通过Watchlist机制重新触发下载。具体表现为：

1. 用户A通过Ombi请求某部电影/剧集
2. 内容成功下载并添加到Plex媒体库
3. 后续该内容被从磁盘、Radarr/Sonarr及Ombi中完全删除
4. 数月后用户B通过Plex Watchlist重新请求相同内容时，Ombi未能触发下载流程

技术原理分析

当前Ombi的实现机制采用"内容级"记忆策略，其核心逻辑包含以下特点：

1. 一次性标记机制：当内容首次通过Watchlist被请求后，Ombi会在内部记录该内容ID
2. 防重复设计：系统会主动忽略已记录内容的后续Watchlist请求，防止因用户频繁操作导致的重复下载
3. 无状态检测：当前实现不检测内容在媒体服务器(Radarr/Sonarr)中的实际存在状态

这种设计在常规使用场景下能有效防止资源浪费，但在动态媒体管理场景中暴露出局限性。

根本原因定位

经过技术分析，问题的本质在于：

1. 缺乏用户上下文：当前实现未区分不同用户的请求行为，将内容标记全局化
2. 状态同步缺失：未建立与媒体服务器(Radarr/Sonarr)的实时状态校验机制
3. 生命周期管理：删除操作未触发Ombi内部记录的同步清理

解决方案设计

开发团队提出的优化方案采用"用户级"请求追踪策略，主要改进点包括：

1. 用户维度请求记录

• 为每个用户建立独立的请求历史记录
• 用户A的删除操作不会影响用户B的后续请求
• 保留全局内容ID的同时增加用户关联字段

2. 智能状态检测

graph TD
    A[Watchlist触发] --> B{内容存在检查}
    B -->|不存在| C[发起下载]
    B -->|存在| D{用户请求记录检查}
    D -->|新用户| C
    D -->|同一用户| E[跳过处理]

3. 混合验证机制

• 首次请求：仅检查内容存在性
• 重复请求：增加用户历史验证
• 管理员可配置全局防重复时间窗口

技术实现要点

1. 数据库改造：

   • 在现有请求记录表中增加user_id字段
   • 建立用户-内容复合索引
   • 实现软删除标记机制

2. Watchlist处理逻辑：

   def process_watchlist(item):
       if not media_exists(item):
           if not has_user_requested(current_user, item):
               create_request(item)
               mark_requested(current_user, item)
       elif is_different_user(current_user, item):
           if not recently_deleted(item):
               create_request(item)
   

3. 状态同步机制：

   • 定期与Radarr/Sonarr同步内容库状态
   • 实现删除操作的hook处理
   • 建立内容生命周期追踪

预期效果

该方案实施后将实现：

1. 多用户场景下的合理重复请求
2. 媒体库动态管理的支持
3. 保持原有防重复机制的优势
4. 管理员可配置的灵活策略

最佳实践建议

对于使用Ombi+Plex Watchlist的管理员，建议：

1. 保持Ombi与媒体服务器的版本同步
2. 定期审查请求历史记录
3. 对临时性内容采用特殊标签管理
4. 教育用户合理使用Watchlist功能

该优化方案已在Ombi v4.44.1后续版本中实现，用户升级后即可获得更灵活的Watchlist管理体验。