Show an estimated time-to-clear for the whole input queue on the dashboard, derived from the current encode speed.
Estimate (sequential queue): total ~= remaining-of-current-job + sum(queued file duration) / current_speed (realtime ratio). Reuses GetDuration (encoder) and the tracker's live speed.
Yes, this needs each queued file's video duration = one ffprobe per file (-show_entries format=duration, header-only, no decode, ~tens of ms). The cost concern is not the probe, it is re-running it: /status is polled every 1s, so probing the whole queue every poll is wasteful.
Approach:
Duration cache keyed by path + mtime; probe each file once when it first appears (or when the watcher marks it settled), memoize, invalidate on mtime change.
/status sums cached durations for the pending queue, divides by current speed, adds the current job's remaining; unprobed files show as 'estimating'.
UI: queue card shows '~Xh (N files)'.
Caveats:
Speed is content/resolution-dependent, so applying the current job's speed to all queued files is a rough heuristic (good for 'roughly when', not a promise).
When idle (no current speed) fall back to no ETA, or a configurable default speed.
Files still copying are excluded (watcher only counts settled files).
Show an estimated time-to-clear for the whole input queue on the dashboard, derived from the current encode speed.
Estimate (sequential queue): total ~= remaining-of-current-job + sum(queued file duration) / current_speed (realtime ratio). Reuses GetDuration (encoder) and the tracker's live speed.
Yes, this needs each queued file's video duration = one ffprobe per file (-show_entries format=duration, header-only, no decode, ~tens of ms). The cost concern is not the probe, it is re-running it: /status is polled every 1s, so probing the whole queue every poll is wasteful.
Approach:
- Duration cache keyed by path + mtime; probe each file once when it first appears (or when the watcher marks it settled), memoize, invalidate on mtime change.
- /status sums cached durations for the pending queue, divides by current speed, adds the current job's remaining; unprobed files show as 'estimating'.
- UI: queue card shows '~Xh (N files)'.
Caveats:
- Speed is content/resolution-dependent, so applying the current job's speed to all queued files is a rough heuristic (good for 'roughly when', not a promise).
- When idle (no current speed) fall back to no ETA, or a configurable default speed.
- Files still copying are excluded (watcher only counts settled files).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Show an estimated time-to-clear for the whole input queue on the dashboard, derived from the current encode speed.
Estimate (sequential queue): total ~= remaining-of-current-job + sum(queued file duration) / current_speed (realtime ratio). Reuses GetDuration (encoder) and the tracker's live speed.
Yes, this needs each queued file's video duration = one ffprobe per file (-show_entries format=duration, header-only, no decode, ~tens of ms). The cost concern is not the probe, it is re-running it: /status is polled every 1s, so probing the whole queue every poll is wasteful.
Approach:
Caveats: