Skip to content

DLManager: fix ETA dropping whole hours from time left display - #788

Merged
loathingKernel merged 1 commit into
RareDevs:mainfrom
Burningflames86:fix_eta_time_left_hours
Oct 1, 2026
Merged

loathingKernel merged 1 commit into
RareDevs:mainfrom
Burningflames86:fix_eta_time_left_hours

Conversation

@Burningflames86

Copy link
Copy Markdown
Contributor

Problem

The "Time left:" display during downloads under-reports the remaining time
by whole hours, and periodically jumps backwards.

estimate was reused when splitting the ETA into its parts:

hours, estimate = int(estimate // 3600), estimate % 3600

Python evaluates the whole right-hand side first, then binds left to right,
so estimate was overwritten with the sub-hour remainder. The value later
passed to the UI as estimated_time_left was therefore always
estimate % 3600 — the whole-hours component was silently discarded.

Effect

true remaining displayed
2:45:00 0:45:00
1:30:00 0:30:00
1:02:05 0:02:05
0:59:55 0:59:55
  • Always renders as 0:MM:SS, under-reporting by whole hours
  • Jumps back up to 0:00:0x each time the estimate crosses an hour
    boundary, so a multi-hour download looks like several sub-hour countdowns
  • Only correct during the final hour of a download

The ETA log line was unaffected, because it formats from the separate
hours/minutes/seconds variables. That disagreement between the logged
ETA: and the on-screen label is the easiest way to observe this.

Fix

Keep the total in its own variable and pass that through to UIUpdate.
The logged ETA is unchanged.

Scope

rare/lgndr/downloader/mp/manager.py only (+6/-5). No changes to the ETA
log format, to get_time, or to any UI code — the existing formatting is
left as-is.

Verification

  • The value sent to the UI now reconstructs the logged HH:MM:SS exactly:
    eta_total == hours * 3600 + minutes * 60 + seconds
  • Confirmed against a live download — the label matches the logged ETA:
    and counts down monotonically across hour boundaries
  • ruff clean; pylint reports no new issues

@loathingKernel

Copy link
Copy Markdown
Contributor

Shouldn't this PR be made to https://github.com/legendary-gl/legendary too?

Comment thread rare/lgndr/downloader/mp/manager.py Outdated
The value sent to the UI was the remainder left over after splitting the
estimate into hours, minutes and seconds, so the whole-hours component was
discarded. The label therefore always read as 0:MM:SS, under-reported the
remaining time by whole hours, and jumped back up to 0:00:0x each time the
estimate crossed an hour boundary. The log line was unaffected because it
formats from the separate variables, which is what made the UI/log
disagreement visible. Keep the total in its own variable and pass that
through instead.
@Burningflames86
Burningflames86 force-pushed the fix_eta_time_left_hours branch from 2cfd9d3 to 0af58a0 Compare October 1, 2026 16:17
@Burningflames86

Copy link
Copy Markdown
Contributor Author

Shouldn't this PR be made to https://github.com/legendary-gl/legendary too?
Legendary repository does not use the estimate variable once the hours, minutes and seconds are calculated from it. Meanwhile in the Rare repository it is dependent on this variable still for UI. (estimated_time_left=round(estimate) on line 164)

@loathingKernel
loathingKernel merged commit 7123739 into RareDevs:main Oct 1, 2026
17 checks passed
@loathingKernel

Copy link
Copy Markdown
Contributor

Thank you for figuring this one out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants