Repository navigation
[Bug]: 处理过程终止（不在这些状态：处理中、处理完、失败），无错误信息以及终止手段； #1342
Description
Activity
感谢反馈！麻烦上传从程序启动到出现问题的完整日志文件，上传前请隐藏 API Key 等敏感信息。另外，最后一条日志出现后大约等待了多久？当时任务管理器中的
ffmpeg.exe是否仍有 CPU 或 GPU 占用？我们先根据这些信息进一步定位。- 您好harry， 抱歉 由于是强制关闭，导致所有的信息都丢失了 。这个状态连续出现2次，都执行到50%，没有任何错误信息出现，整个功能屏幕全是灰色，不可操作, 直接停止的位置都正常执行，日志也正常；最后一次验证是否执行时间不够，等了12个小时，状态没有任何变化； 任务管理器中的 ffmpeg.exe 是否仍有 CPU 或 GPU 占用？--> 这个应该没有多少占用，系统其他操作都是正常的。 后面如果有复现，会把问题日志再提交给您。 Richard 在 2026-09-12 10:13:02，"Harry" ***@***.***> 写道： harry0703 left a comment (harry0703/MoneyPrinterTurbo#1342) 感谢反馈！麻烦上传从程序启动到出现问题的完整日志文件，上传前请隐藏 API Key 等敏感信息。另外，最后一条日志出现后大约等待了多久？当时任务管理器中的 ffmpeg.exe 是否仍有 CPU 或 GPU 占用？我们先根据这些信息进一步定位。 — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>
Richard 您好，感谢补充，也辛苦您等了这么久。连续两次停在 50%，并且等待 12 小时仍无变化，确实需要进一步排查，不必再等这么长时间。目前还无法确定 FFmpeg 卡住的具体原因。
下次方便复现时，可以按下面的步骤保存日志。以下适用于通过项目中的
webui.bat启动；如果您使用的是其他启动方式，请告诉我们。1. 用 CMD 启动并保存日志
先停止之前运行的程序，避免同时启动多个实例。打开 MoneyPrinterTurbo 项目文件夹，在资源管理器地址栏输入
cmd并回车，确认当前目录能看到webui.bat。依次执行：
set PYTHONUNBUFFERED=1 webui.bat > mpt-debug.log 2>&1
这会把终端的正常输出和错误输出保存到项目目录的
mpt-debug.log。CMD 窗口暂时没有文字输出是正常的，请先保持窗口打开。随后在浏览器打开 WebUI，按原来的参数生成视频。通常地址是
http://127.0.0.1:8501；如果打不开，请用记事本查看日志中显示的 WebUI 地址。注意：再次运行上面的命令会覆盖同名日志，下一次测试前请先把已有日志改名保存。
2. 再次卡住时记录现场
如果再次长时间停在 50%：
- 截图保存页面状态，并记下最后一次进度变化后等待了多久。
- 按
Ctrl + Shift + Esc打开任务管理器，找到ffmpeg.exe（有多个时请都记录），截图保存 CPU、内存和 GPU 占用；如果没有这个进程，也请说明。 - 请尽量保留该任务在
storage/tasks/下的文件，先不要清理缓存；暂时不需要上传整个任务文件夹。
记录完成后无需继续等待 12 小时。可以先回到启动程序的 CMD 窗口按
Ctrl + C尝试停止；如出现终止批处理的确认，输入Y。若仍无法停止，再按您之前的方式关闭，并保留日志文件。3. 在这里上传反馈
- 用记事本打开
mpt-debug.log，另存一份用于反馈的副本。 - 检查并隐藏 API Key、Token、Authorization、带签名的链接和其他私人信息。请保留错误堆栈、时间、任务 ID 等排查信息；不要上传
config.toml。 - 将脱敏后的日志改为
mpt-debug.txt，或压缩成 ZIP。 - 用浏览器打开本 issue，在底部评论输入框中拖入日志文件和截图，等附件上传完成、出现链接后再提交评论。建议直接在 GitHub 页面上传，不要通过邮件附件回复。
- 顺便注明这次视频的目标时长、分辨率，以及大约卡住了多久。
日志落盘后，即使页面关闭，已写入的内容通常也还在。不过目前拼接阶段没有实时输出 FFmpeg 进度，日志仍可能停在同一行，因此任务管理器截图也很有帮助。我们先保持这个 issue 开放，收到后继续定位。
- added a commit that references this issue
on Sep 13, 2026 Saw harry0703's logging instructions above — the contract point below is complementary: before root-causing the hang, the UI needs a definite stage state. I've hit this class of bug in my own video pipelines: the step neither fails nor finishes, it just sits there. What helped was wrapping every pipeline stage in a three-state outcome contract — SUCCESS carries the artifact, EXPLICIT_FAILURE carries the reason, and anything silent past a deadline is recorded as SILENT_TIMEOUT, i.e. failure. That alone doesn't fix the ffmpeg concat hang, but it turns "the app froze" into "stage X timed out at N minutes with these inputs" — if the next repro confirms a stalled ffmpeg subprocess, the record captures exactly the inputs harry0703 asked for. Happy to share the contract shape if useful.
建议引入三态结果契约，静默超时记为失败，让界面显示明确的阶段状态。
Thank you, @chenhz01, for the thoughtful suggestion and for sharing your experience. We agree that a stalled subprocess should eventually produce an actionable failure rather than leave the task waiting indefinitely.
The pipeline already records failure states, stages, and error details. Version 1.3.7 also added periodic FFmpeg concatenation logs with elapsed time and output file size (#1351). These logs improve diagnosis, but they are not proof that encoding is progressing, and they do not fix a hung subprocess.
A focused follow-up would be timeout handling and subprocess cleanup around FFmpeg concatenation, using the existing task failure reporting rather than introducing a new outcome contract across the entire pipeline immediately. Any timeout policy needs to account for slow machines and long videos; lack of log output alone should not trigger failure. We have not yet confirmed the cause of the original hang.
@qianlima-c Richard 您好，也感谢您之前的反馈。如果方便，请先升级到 v1.3.7 或更新版本，再使用前面说明的日志保存方式重试。若仍卡住，请上传脱敏后的完整日志，并注明任务 ID、视频分辨率、目标时长和已等待时间，附上 FFmpeg 的 CPU／内存／GPU 占用截图。新版日志会记录拼接等待时间及输出文件大小，有助于判断是否仍在处理；请保留任务文件，不必再等待 12 小时，也不要上传 config.toml 或 API Key。
这个 issue 会继续保持开放。目前只是增加了排查信息，尚不能确认原来的卡住问题已经解决。
Thanks for the kind words — glad the diagnosis matched what you were seeing. Since you've confirmed the stalled-subprocess behavior, the smallest safe increment would be: wrap the concat step in a bounded wait (poll the ffmpeg pipe with a timeout, capture stderr on kill), and emit an explicit failed state instead of hanging the UI thread. Happy to open that PR against your current structure — just point me at the module you'd want it in.
问题描述 | Current Behavior
运行多次，在这个环节就停止了，应用没有反应：既不报错、也不继续进行、也不退出（时间足够长），必须强制关闭。
| INFO | "./app/services/video.py:805": combine_videos - starting clip merging process
| INFO | "./app/services/video.py:811": combine_videos - concatenating 32 clips with ffmpeg
重现步骤 | Steps to Reproduce
| INFO | "./app/services/video.py:805": combine_videos - starting clip merging process
| INFO | "./app/services/video.py:811": combine_videos - concatenating 32 clips with ffmpeg
错误日志 | Error Logs
| INFO | "./app/services/video.py:805": combine_videos - starting clip merging process
| INFO | "./app/services/video.py:811": combine_videos - concatenating 32 clips with ffmpeg 后面就没有内容了。
Python 版本 | Python Version
v3.14
操作系统 | Operating System
window11
MoneyPrinterTurbo 版本 | Version
v1.3.6
补充信息 | Additional Information
No response