更新3.11版本后，回看出现问题，部分节目无法回看

[ninggu2008]

更新3.11.0版本后，回看出现问题，同一个频道，同一天，部分节目完全无法回看，黑屏卡住（反复尝试、更换播放器均无法回看），部分节目起播时间较长，部分节目又正常，没有发现规律。
降级为3.10.1后，3.11.0版本不能正常回看的节目可以正常回看，所有节目回看起播速度正常，试了好几个节目均完全正常。

3.10.1版本正常回看debug日志.txt
3.11.0版本无法正常回看debug日志.txt

[ninggu2008]

分析可能是3.11.0版本新增的rewrite模块有问题，正常情况下：
11:01:40 DEBUG [Worker 0] HTTP Proxy: Sent headers 431 bytes (431/431)
11:01:40 DEBUG [Worker 0] HTTP Proxy: Request sent (431 headers + 0 body bytes)
11:01:41 DEBUG [Worker 0] HTTP Proxy: Response status: 200
11:01:41 DEBUG [Worker 0] HTTP Proxy: Content-Type: application/vnd.apple.mpegurl
11:01:41 DEBUG [Worker 0] HTTP Proxy: Content-Length: 126224
11:01:41 DEBUG [Worker 0] HTTP Proxy: M3U content detected, will rewrite body
11:01:41 DEBUG [Worker 0] HTTP Proxy: Saved 212 bytes of response headers for rewrite
11:01:41 DEBUG [Worker 0] M3U rewrite: 126224 bytes -> 132398 bytes
11:01:41 DEBUG [Worker 0] HTTP Proxy: Sent rewritten M3U (132398 bytes body)
11:01:41 DEBUG [Worker 0] HTTP Proxy: Transfer complete
异常情况：没有触发M3U rewrite: 126224 bytes -> 132398 bytes
11:01:41 DEBUG [Worker 0] HTTP Proxy: M3U content detected, will rewrite body
11:01:41 DEBUG [Worker 0] HTTP Proxy: Saved 212 bytes of response headers for rewrite
11:02:41 DEBUG [Worker 0] Client disconnected（手动终止播放）
11:02:41 DEBUG [Worker 0] HTTP Proxy: Cleaning up session (socket=15)

[ninggu2008]

用gemini分析日志和http_proxy.c 源码，回复如下：

结合您提供的 http_proxy.c 源码，可以非常明确地锁定 3.11.0 版本无法回看的具体代码逻辑缺陷。

问题出在 M3U8 重写模式下的数据读取循环与 Content-Length 的处理逻辑冲突。

1. 核心 Bug 逻辑：http_proxy_try_receive_response 函数
   在源码中，程序针对 M3U8（needs_body_rewrite 为 true）采用的是全缓存模式：

为什么 3.11.0 会“卡死”？
根据 3.11.0 的日志 ：

识别成功：检测到 Content-Type: application/vnd.apple.mpegurl，设置 needs_body_rewrite = 1。

长度已知：日志记录 Content-Length: 193126 。

解析头部后剩余数据：在 http_proxy_parse_response_headers 结束后，如果第一个数据包（response_buffer）中已经包含了部分 body，代码会将其移动到 rewrite_body_buffer。

死循环/停滞原因：

如果第一个包没读完整个 193KB 的 M3U8，代码返回 0（Keep buffering），等待下一次 POLLER_IN 事件。

但是，日志显示在 Saved 212 bytes of response headers 后就再也没有 Recv 记录了 。

根本原因：在 http_proxy_handle_socket_event 中，POLLER_IN 触发后，程序进入 while 循环调用 http_proxy_try_receive_response。一旦该函数返回 0，循环就会 break。如果此时内核缓冲区内仍有剩余数据，但在**边缘触发（Edge-Triggered）**模式下，如果没有新的数据到达，POLLER_IN 不会再次触发，导致剩余的 190KB 数据永远留在 Socket 缓冲区中，程序进入死等状态。

2. 与 3.10.1 版本的差异
   虽然没看到 3.10.1 的源码，但从日志 可以推断：

3.10.1 不进行 Body 重写：它直接使用 buffer_pool_alloc() 进行零拷贝转发（Zero-copy streaming），数据随读随发，不会因为等待“接收完整个文件”而阻塞。

3.11.0 引入了复杂的重写逻辑：为了修改 M3U8 里的链接，它必须先“攒齐”整个文件才能调用 rewrite_m3u_content。

3. 修复建议
   方案 A：修正逻辑判断（最快）
   在 http_proxy_try_receive_response 的 M3U8 处理分支中，即使返回 0（继续缓存），也应该确保 while 循环能继续从 Socket 读取数据，直到 recv 返回 EAGAIN。

方案 B：解决边缘触发（ET）下的读取不彻底
当前的 http_proxy_handle_socket_event 逻辑如下：

改进建议：
在重写模式下，http_proxy_try_receive_response 应该在读取到数据但未收全时返回一个正值（例如 1），迫使 handle_socket_event 里的 while 循环继续 recv，直到把内核缓冲区读空（返回 EAGAIN）。

总结
3.11.0 的 M3U8 重写功能在处理较大文件时（如本例 193KB），由于一次 recv 无法读完且未正确处理后续读取触发，导致请求卡死在“等待完整 Body”的阶段，最终因 60 秒超时断开 。

您可以尝试修改 http_proxy.c 第 611 行附近，让 needs_body_rewrite 模式在成功 recv 到数据后返回 received 的字节数而不是 0。

[CGG888]

反正我 http 的单播回看的时候，有时候成功有时候不成功，单播我就没走这过了，直接走 iptv 线路！就是外网稍微麻烦些！需要代理软件才能在外网观看单播和回看！