PlexTraktSync 项目中的重播标记问题解析

问题背景

在使用PlexTraktSync的watch模式进行媒体播放同步时，用户发现当重新观看已标记为观看的剧集时，系统会返回"Conflict - resource already created"的错误信息。这个问题主要出现在Docker容器环境下运行PlexTraktSync的watch模式时。

技术分析

PlexTraktSync的watch模式通过持续监听Plex媒体服务器的播放状态变化，将观看进度同步到Trakt.tv平台。当用户重新观看已标记为观看的内容时，系统会尝试再次向Trakt.tv发送观看记录。

错误机制

1. 冲突检测：Trakt.tv API设计上会防止重复创建相同的观看记录，当检测到重复提交时会返回409 Conflict状态码
2. 缓存机制：PlexTraktSync使用了请求缓存来优化API调用，缓存时间设置为1天
3. 同步频率：watch模式下，系统会每秒检查并同步播放状态

日志解读

从日志中可以观察到：

• 系统首先通过TMDB ID查询剧集信息
• 确认播放进度达到阈值(95.35%)后尝试标记为已观看
• 向Trakt.tv发送stop请求时收到409冲突响应
• 错误信息表明资源已存在

解决方案

实际上，这个"Conflict"错误属于正常现象，不会影响功能实现：

1. 自动恢复：系统会在下一个同步周期(1秒后)重新尝试同步
2. 最终一致性：即使暂时出现冲突，最终观看状态仍会被正确同步
3. 性能优化：冲突响应避免了不必要的API调用

最佳实践建议

1. 单实例运行：确保只运行一个watch实例，避免多实例竞争
2. 合理配置：保持默认的同步阈值(90%)和同步频率
3. 错误处理：可以安全忽略此类冲突错误，它们不会影响最终同步结果
4. 测试验证：通过完整观看剧集而非快进测试，以获得更准确的结果

技术实现细节

PlexTraktSync的watch模式实现了几项关键技术：

1. 状态检测：持续监控Plex的播放状态变化
2. 进度计算：基于播放百分比触发同步
3. 幂等处理：优雅处理API冲突响应
4. 缓存策略：合理缓存API响应减轻服务器负担

这种设计确保了系统在保持高性能的同时，能够可靠地同步观看状态，即使用户频繁重播内容。