大量下载

[will1211]

欢迎

• 是的，我正在使用最新的主要版本。只有这种安装才受支持。
• 是的，我正在使用受支持的系统。只有这种系统才受支持。
• 是的，我已经阅读了所有 WIKI 文档，但仍然无法解决我的问题。
• 是的，我已经在 GitHub 上搜索过类似问题，但没有找到。
• 是的，我已经在下面提供了所有信息（版本、配置、日志等）。

问题描述（最好附上截图）

从日志来看，服务在处理 /live.m3u8 时出现了大量 500 错误，并且耗时都在 20 秒左右。结合后面的日志，核心问题是：多个并发请求同时触发了对同一个 YouTube 视频的 yt-dlp 外部调用，导致大量重复“下载”（其实是获取流地址），并且由于某些资源竞争或超时，最终全部返回 500。

具体分析如下：

1. 现象：高并发请求同一视频，全部超时 500
   text
   [GIN] ... | 500 | 20.38s | GET "/live.m3u8?c=3"
   [GIN] ... | 500 | 20.62s | GET "/live.m3u8?c=4"
   ...
   请求几乎同时到达（时间戳都是 04:55:46），处理时间全部超过 20 秒。

返回 500，说明处理过程中发生了致命错误。

2. 根因：缓存未命中，并发调用 yt-dlp，缺少互斥
   关键日志：

text
m3u8cache.go:31: caching https://www.youtube.com/watch?v=quwqlazU-c8
youtubedl.go:64: cache miss https://www.youtube.com/watch?v=quwqlazU-c8
youtubedl.go:134: yt-dlp [-f b -g https://www.youtube.com/watch?v=quwqlazU-c8]
多个请求访问的是同一个视频 quwqlazU-c8（尽管 ?c=数字 参数不同，但底层视频 ID 可能相同）。

当第一个请求到达时，缓存未命中（cache miss），于是执行 yt-dlp -f b -g ... 来获取直播流地址。

该外部命令通常需要数秒甚至十几秒才能返回。

在这段时间内，其他请求也纷纷到来，由于缓存尚未就绪，每个请求都判断为 miss，各自启动独立的 yt-dlp 进程，造成大量重复调用（即你看到的“大量下载”错觉——其实是在并发获取流地址）。

20 秒左右统一超时/失败（可能是因为 yt-dlp 进程过多导致资源耗尽、端口占用、文件锁冲突，或者服务内部超时控制），最终返回 500。

live.go:90: read |0: file already closed 这条错误进一步印证了存在资源并发争用的问题：可能在多个 goroutine 间共享了某个已被关闭的文件或管道。

3. 为什么会“大量下载”？
   因为 yt-dlp -g 虽然只是获取流 URL，但在高并发场景下，每个请求都独立启动一个 yt-dlp 进程。如果瞬间涌入几十个请求，就会看到几十个 yt-dlp 进程同时运行，消耗大量 CPU/内存/网络资源，给人“大量下载”的观感。如果 yt-dlp 命令实际上还包含下载意图（或后续步骤），情况会更糟。

操作系统版本

Details

# 例如: Ubuntu 22.04 / Debian 12 / CentOS 7

LiveTV 的版本

Details

# 请在此粘贴

LiveTV 的日志

Details

# 请在此粘贴日志

[qist]

更新最新版本