Add random delay

[ArenaDruid]

在每个线程开始更新视频前添加一段上限为10分钟的随机延迟，以防止大量线程同时通过rsshub访问bilibili API 导致的可能的反爬限制。

之前发现当开启服务时，如果设置的较多的任务时会导致如下报错。

fail: AbortError: This operation was aborted

或者

TypeError: fetch failed

但是在减少任务后，不会出现以上报错，合理怀疑是因为并发设计会导致大量线程同时通过rsshub访问bilibili API并导致的可能的反爬限制。

因此通过增加随机延迟以规避掉短时间的大量访问。

[LJason77]

我这里从没有触发过反爬，并且有即时下载视频的需求，所以延迟并不是一个好的解决方案。
或许可以添加配置自行开关延迟。

[LJason77]

fail: AbortError: This operation was aborted

和

TypeError: fetch failed

两个报错是在哪里出现的。

是否被反爬并不需要怀疑，Rsshub 上会有明确的提示。

[ArenaDruid]

我设置了30个计划任务，并同时重启rsshub和该软件，就会出现部分甚至大量出现此类报错。
以下是夹杂着报错和成功的log文件：

1. bilibili-webhook_logs.txt
2. rsshub_logs.txt

[ArenaDruid]

我这里从没有触发过反爬，并且有即时下载视频的需求，所以延迟并不是一个好的解决方案。 或许可以添加配置自行开关延迟。

已经添加配置自行开关延迟

[LJason77]

1. Rsshub 从启动到可用需要一定时间，不适合与 webhook 一起启动。
   根据你的描述和日志文件 bilibili-webhook_logs.txt ，推测使用了 docker compose 类的编排工具。
   可以在编排工具中添加 HealthCheck 来避免 Rsshub 启动慢导致最初的请求失败。

2. Rsshub 触发反爬的特征是 This operation was aborted: target website might be blocking our access, you can host your own RSSHub instance for a better usability.
   然而这个特征也可能单纯是超时了，参见：Docker 部署 出现大量 [GET] "..." <no response> This operation was aborted DIYgod/RSSHub#15059
   我这边复现不出来。

3. https://api.bilibili.com/x/web-interface/nav 是 WBI 签名的接口，相关链接：

   • fix(route): 通过在配置中预添加大量 Cookie 来绕过 Bilibili 反爬 DIYgod/RSSHub#13365
   • 🔴 Bilibili UP 投稿报错：非法访问  DIYgod/RSSHub#13398
   • bilibili/user/video error code -352 while fetching: 风控校验失败 DIYgod/RSSHub#13985
     但我这边貌似并不会触发到这一步（请求里没有这个链接）。
     上面链接里有说 自建+添加 cookie 可以恢复正常，而我一开始就是手动提供了 cookie，所以这可能是我从始至终都没有这种问题，并且也触发不出来的原因。
     （这仅是猜测，我并不擅长前端语言，对 Rsshub 如何到这个接口的并不了解）

4. 如果上面都解决不了问题，我才会合并此 PR。
   在此之前，此 PR 将会闲置。

[ArenaDruid]

1. Rsshub 从启动到可用需要一定时间，不适合与 webhook 一起启动。
   根据你的描述和日志文件 ，推测使用了 docker compose 类的编排工具。
   可以在编排工具中添加 HealthCheck 来避免 Rsshub 启动慢导致最初的请求失败。

2. Rsshub 触发反爬的特征是 This operation was aborted: target website might be blocking our access, you can host your own RSSHub instance for a better usability.
   然而这个特征也可能单纯是超时了，参见：Docker 部署 出现大量 [GET] "..." This operation was aborted DIYgod/RSSHub#15059
   我这边复现不出来。

3. https://api.bilibili.com/x/web-interface/nav 是 WBI 签名的接口，相关链接：

   • fix(route): 通过在配置中预添加大量 Cookie 来绕过 Bilibili 反爬 DIYgod/RSSHub#13365
   • 🔴 Bilibili UP 投稿报错：非法访问  DIYgod/RSSHub#13398
   • bilibili/user/video error code -352 while fetching: 风控校验失败 DIYgod/RSSHub#13985
     但我这边貌似并不会触发到这一步（请求里没有这个链接）。
     上面链接里有说 自建+添加 cookie 可以恢复正常，而我一开始就是手动提供了 cookie，所以这可能是我从始至终都没有这种问题，并且也触发不出来的原因。
     （这仅是猜测，我并不擅长前端语言，对 Rsshub 如何到这个接口的并不了解）

4. 如果上面都解决不了问题，我才会合并此 PR。
   在此之前，此 PR 将会闲置。

关于第一个问题，我目前的docker-compose设计中已经采用了health-check和depends_on来规避，但是没有效果，以下是我的docker-compose文件：docker-compose.txt

关于第二个问题，我认为30个任务就造成网络单纯的阻塞的可能性是远小于被风控的可能性的，而且我认为也许rsshub并没有捕获到bilbili新的风控特征，因此没有报出风控的错误。即使真的是因为网络问题，那么通过延迟和排队设计来缓解网络原因导致的阻塞依然是有意义的。而且我在采用延迟的设计后，的确没有再出现过上面的报错，因此从结果上来说，这样的设计是有作用的。

关于第三个问题，同样的从docker-compose文件中可以看到，我已经使用了自建的rsshub和多个bilibili-cookies来尝试规避该问题，但是没有效果

[LJason77]

1. 容器编排问题不在本项目的范围内，在此仅是建议，还请自行解决，后续将不会在此讨论。

2. BILIBILI_COOKIE_{uid} 问题

   • uid 是用户的 uid（如果是由于隐私不在此暴露，那便忽略这条）
   • 在 Rsshub 中，部分路由只要求 SESSDATA 字段，部分路由则需要整段 Cookie

3. 网络或风控
   虽然从结果上看，PR 的确可以解决表面的问题，但实际上并没有从根本上解决，甚至连问题在哪都没有明确。
   不管是网络还是风控问题，都是属于上游的问题。
   上游的问题让下游解决不合适也不合理。

最后再说说我对这个 PR 乃至本项目的看法。之前便想说了，打了一半觉得不合适就删了：

使用自动化工具本身就已经超出 "正常用户的正常使用" 的范围。
本项目自认并不是一个 "合理" 的做法，但至少还在 "可用" 的范围。
30 个任务明显已经大大超出 "可用" 的范围，触发风控也非常可能，网站也肯定是禁止的。
我作为互联网从业人员，深知这种行为放在任何地方都是不讨喜的，所以有些禁区并不会去触碰。
某些做法会让官方加紧封锁，让项目彻底死亡，或者互相斗法，这并不是本项目的本意。

我没有批评你的意思，毕竟本项目本身就不 "合理"，我没有资格也没有必要批评，并且感谢你为本项目做出的贡献和尝试。
未来如果能证明以下两点，我依旧愿意处理此 PR：

1. 30 个的任务量不在网站的风控范围内；
2. 有明确并且合理的原因需要添加延迟。

[ArenaDruid]

行吧，我了解了