From 4e16330e87b4e61f963d59e7283a6ff447fca6a1 Mon Sep 17 00:00:00 2001 From: ericwyuan Date: Thu, 20 Aug 2026 18:11:43 +0800 Subject: [PATCH] =?UTF-8?q?docs:=20update=20PROGRESS.md=20-=20=E5=8E=8B?= =?UTF-8?q?=E7=BC=A9=E7=BC=93=E5=AD=98=E5=8E=9F=E5=AD=90=E6=80=A7=E4=BF=AE?= =?UTF-8?q?=E5=A4=8D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- PROGRESS.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/PROGRESS.md b/PROGRESS.md index d88c87f..8384fb6 100644 --- a/PROGRESS.md +++ b/PROGRESS.md @@ -1,6 +1,6 @@ # 项目进度追踪 -> 最后更新: 2026-08-20 18:05 +> 最后更新: 2026-08-20 18:25 ## 服务运行状态 @@ -161,6 +161,14 @@ 19. **chunk_size 变更防护** - Edge 端 upload_chunk 检测 total_chunks 变更（由 chunk_size 变化导致），自动清理旧分块防止混合不同大小分块导致 assemble 后文件损坏。NAS 端 _query_uploaded_chunks 比对 expected_total != edge_total 时跳过断点续传 20. **看门狗机制** - app.py 启动 daemon 看门狗线程，每 60s 检查 scheduler/dispatcher/poller 线程 is_alive()，崩溃自动 check_and_restart()。/api/status 改用 thread.is_alive() 替代 _running 标志，防止线程假死误报 +## 压缩缓存原子性修复 (2026-08-20 18:25, commit 1994de2) + +**根因**（task 300 损坏视频之谜的答案）：服务被 kill 时 dispatcher 死亡但其 ffmpeg 子进程成为**孤儿**（父进程转 init）继续写压缩产物。旧代码直接写最终路径，半成品文件 `size>0` 且 mtime 较新 → 缓存复用判断误判为有效 → 重试任务上传损坏视频。多次重启叠加多个孤儿 ffmpeg 争抢 NAS ARM CPU（本轮实测 3 个并行）。 + +**修复**：压缩输出写 `{out}.{pid}.tmp`（带 PID 防多进程冲突），成功后 `os.replace` 原子 rename——缓存目录只可能出现完整产物；`_cleanup_compress_cache` 顺带清理超 1h 的 .tmp 残留。 + +**运维**：已杀孤儿 ffmpeg×2（task 43/44）并清理缓存目录、重置任务状态；每次重启 NAS 服务后应检查 `ps aux | grep ffmpeg41` 是否有孤儿残留。 + ## 视频时间语义修正 (2026-08-20 18:05, commit 80b2fcc) 时区统一的延伸排查发现三处**时间语义** bug（时区对了但语义错）：