Files
metube/ui
Alex Shnitman 1251613f45 fix: show the post-download processing phase in the UI (closes #424)
yt-dlp reports a download 'finished' as soon as the media bytes have
landed, but the ffmpeg work that follows -- merging, re-encoding, chapter
splitting, sponsor removal -- routinely takes longer than the download
itself. The postprocessor hook only ever looked at MoveFiles and
SplitChapters finishing, so that whole phase said nothing: the row sat in
the Downloading table on a full, frozen progress bar, and the item counted
as neither active nor queued in the header stats.

Report a 'postprocessing' status when a postprocessor starts, and reuse
the indeterminate bar the UI already runs for 'preparing', labelled so a
long re-encode is distinguishable from a stall.

Measured on a real download re-encoded with the reporter's FFmpegCopyStream
config, the UI now receives:

    [ 0.27s] downloading      moving bar
    [ 0.28s] finished         <- yt-dlp, bytes are down
    [ 0.28s] postprocessing   animated "Post-processing"
    [13.18s] finished         done

i.e. 12.9s that used to render as a static 100% bar.

The hook is latched off once MoveFiles reports finished, since that branch
announces the finished file: a 'postprocessing' arriving afterwards would
flip the row back out of its completed state for no reason. It cannot fail
the download -- _download puts an unconditional 'finished' once download()
returns, so the terminal status is settled either way -- but the flicker
and the extra broadcast are both pointless. yt-dlp does run an 'after_move'
stage after MoveFiles, though every postprocessor MeTube configures is
'after_filter' or 'post_process', both of which precede it.

update_status drops a repeated 'postprocessing': yt-dlp's metaclass wraps
run() once per class in a postprocessor's MRO, so one whose subclass
overrides run reports started twice -- FFmpegCopyStream did exactly that in
the live run, three queued statuses collapsing to a single broadcast.

Extracted to _make_postprocessor_hook, mirroring _make_progress_hook, so
the ordering above is testable; every new regression test was confirmed to
fail with the fix backed out.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 16:12:39 +02:00
..
2026-03-15 20:53:13 +02:00
2026-04-12 23:07:22 +03:00
2026-06-28 21:12:20 +03:00