ytdl-sub项目中多URL订阅与Only Recent预设的下载优化策略

问题背景

在使用ytdl-sub进行视频平台频道内容订阅下载时，用户可能会遇到一个特殊场景：当为同一订阅配置多个URL源，并启用"Only Recent"预设时，系统会出现重复下载并立即删除部分视频的情况。这种现象主要发生在以下配置条件下：

1. 订阅配置中包含多个URL（如主频道URL、直播流URL等）
2. 启用了"Only Recent"预设，设置了日期范围（如3个月）和最大文件数限制（如20个）
3. 不同URL源提供的视频数量差异较大

技术原理分析

ytdl-sub的工作机制在处理这种多URL场景时，会依次处理每个URL，而不是先获取所有URL的元数据再做统一筛选。这种设计带来了以下技术特点：

1. 顺序处理机制：系统会逐个URL处理，先下载第一个URL的内容，应用筛选条件，然后处理下一个URL
2. 独立筛选：每个URL的筛选过程是独立的，不知道其他URL的内容情况
3. 最终一致性：所有URL处理完成后，系统会应用全局的最大文件数限制

典型问题场景

假设我们有以下配置：

• 订阅包含三个URL源：
  • 主频道（近3个月有30个视频）
  • 直播流（近3个月有15个视频）
  • 子频道（近3个月有10个视频）
• 设置"Only Recent"参数为：
  • 日期范围：3个月
  • 最大文件数：20

在这种情况下，系统会：

1. 先处理主频道，下载30个视频
2. 应用最大文件数限制，保留最新的20个，删除10个
3. 处理直播流URL，下载15个视频
4. 此时总数已达35，超过20的限制，因此新下载的15个会被删除
5. 处理子频道URL，同样下载后立即删除

解决方案建议

针对这一技术限制，项目维护者建议采用以下优化策略：

1. 拆分订阅：为每个URL源创建独立的订阅项
2. 统一命名：通过设置相同的tv_show_name参数，将这些订阅的内容归入同一电视节目目录
3. 独立限制：为每个订阅设置适当的max_files值，确保总和不超过预期

例如：

视频平台 Live - Main:
  "Level1Techs Main":
    - "https://www.example.com/@Level1Techs"
  overrides:
    only_recent_max_files: 10

视频平台 Live - Streams:
  "Level1Techs Streams":
    - "https://www.example.com/@Level1Techs/streams"
  overrides:
    only_recent_max_files: 7

视频平台 Live - Linux:
  "Level1Linux":
    - "https://www.example.com/@Level1Linux"
  overrides:
    only_recent_max_files: 3

技术决策考量

项目维护者明确表示不会修改当前的行为模式，主要基于以下技术考量：

1. 性能因素：预先获取所有URL的元数据会显著增加初始处理时间
2. 实现复杂度：统一元数据收集机制会大幅增加代码复杂度
3. 使用场景：大多数用户使用单URL订阅，多URL场景相对边缘

最佳实践建议

对于需要使用多URL订阅的用户，建议：

1. 评估各URL源的视频发布频率
2. 根据频率合理分配max_files配额
3. 定期检查下载结果，调整配额分配
4. 考虑使用更宽松的日期范围来减少误删
5. 对于重要内容，可以创建不使用"Only Recent"的备份订阅

通过这种策略，用户可以在保持内容组织性的同时，避免不必要的重复下载和删除操作。