Tdarr项目中的Radarr通知流程问题分析与解决方案

问题背景

在Tdarr媒体处理流程中，用户报告了一个持续存在的问题：Sonarr通知功能工作正常，但Radarr通知功能始终无法正常工作。这导致Radarr无法正确识别经过Tdarr处理的文件，误认为它们是需要重新下载的"旧"文件。

技术分析

核心问题定位

经过深入调查，发现问题并非出在Tdarr插件本身，而是与Radarr API的"parse"端点有关。该端点负责通过文件名解析电影ID，但在某些特定环境下无法正常工作。值得注意的是：

1. 相同代码结构的Sonarr通知功能工作正常
2. 问题表现为Radarr API无法通过文件名正确识别电影
3. 即使简化文件名到最简形式，问题依然存在

潜在原因推测

经过多方测试和分析，可能的原因包括：

1. 特殊字符处理问题：文件名中包含的某些特殊字符可能影响API解析
2. 系统迁移历史：长期使用的Radarr实例经过多次版本升级可能导致兼容性问题
3. 大规模媒体库影响：包含大量内容的库可能影响API响应

解决方案探索

临时解决方案

目前可用的临时解决方案包括：

1. 使用修改版的notifyRadarrOrSonarr插件（2.0.0版本）
2. 尝试通过当前文件名而非原始文件名进行查询
3. 检查并确保API密钥和网络连接配置正确

长期改进方向

基于技术分析，建议从以下方面进行长期改进：

1. 实现多端点查询策略：

   • 优先尝试通过IMDb ID查询
   • 使用parse端点作为备用方案
   • 增加文件名编码处理确保特殊字符正确传递

2. 增强错误处理和日志记录：

   • 记录更详细的API交互信息
   • 提供更明确的错误提示
   • 实现多级重试机制

3. 文件处理流程优化：

   • 确保通知步骤是流程的最后一步
   • 考虑文件扩展名变更的影响
   • 验证文件锁定和0字节文件问题

最佳实践建议

对于遇到类似问题的用户，建议采取以下步骤：

1. 验证基础配置：

   • 确认Radarr版本（测试时使用5.3.6.8612）
   • 检查API密钥和网络连接
   • 确保通知插件是流程的最后一步

2. 测试流程：

   • 使用简化文件名进行测试
   • 在新安装环境中验证功能
   • 通过直接API调用确认端点行为

3. 监控和处理：

   • 关注Radarr和Tdarr日志
   • 考虑实现自定义命名策略
   • 定期验证通知功能是否正常工作

总结

Tdarr与Radarr的集成问题虽然表面表现为通知功能失效，但实际涉及API交互、文件处理流程和系统配置多个层面。通过系统化的分析和多角度的解决方案，用户可以逐步定位和解决问题，最终实现稳定的媒体处理流程。未来版本的插件将通过更健壮的查询策略和错误处理机制，进一步提升此类集成的可靠性。