Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Estimate properly or not show ETA for uploaded files using the web UI. #25053

Closed
SergioBertolinSG opened this issue Jun 10, 2016 · 14 comments · Fixed by #37053
Closed

Estimate properly or not show ETA for uploaded files using the web UI. #25053

SergioBertolinSG opened this issue Jun 10, 2016 · 14 comments · Fixed by #37053

Comments

@SergioBertolinSG
Copy link
Contributor

SergioBertolinSG commented Jun 10, 2016

Steps to reproduce:

  1. Upload a file with a size of several megabytes.

Expected behaviour:

Time left written in the progress bar decreases per second.

Actual behaviour

Time left is variable, it can increase a lot, decrease, increase again.

I recommend to remove this text from progress bar or improve the estimation.

cc: @luckydonald

@SergioBertolinSG SergioBertolinSG added this to the 9.1-current milestone Jun 10, 2016
@guruz
Copy link
Contributor

guruz commented Jun 10, 2016

FYI @ckamm

@PVince81
Copy link
Contributor

Or at least remove the message "Any time soon..." which is likely to appear when the upload is short.

@PVince81 PVince81 modified the milestones: 9.1-current, 9.2-next Jun 15, 2016
@PVince81 PVince81 modified the milestones: 9.2, backlog Oct 14, 2016
@hodyroff hodyroff removed the Type:Bug label Nov 30, 2016
@hodyroff
Copy link
Contributor

This has changed from 9.0 to 9.1
There are Pro's and Con's. I think its fine as it is now, some people like the text. I guess only other option would be to have an option in personal settings to show time/text in the progress bar or show nothing (like 9.0 seems to behave).
Not a bug as it was clearly designed this way ;)

@luckydonald
Copy link
Contributor

Maybe the algorithm calculating the remaining time can be improved, so there is less jumping in the values.
As I am not good in the related mathematics, someone else have to come up with a better formula.

@ownclouders
Copy link
Contributor

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.

@ownclouders
Copy link
Contributor

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

@ownclouders
Copy link
Contributor

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

@pmaier1
Copy link
Contributor

pmaier1 commented Apr 9, 2018

Moving to planned. We should tackle this in the next dev iteration depending on effort. Either
a) improve the estimation for that it really works reliably (and don't display e.g. "Infinite") or
b) remove the estimation and only show percentage completed

@pmaier1 pmaier1 modified the milestones: backlog, planned Apr 9, 2018
@PVince81
Copy link
Contributor

PVince81 commented Apr 9, 2018

The "Infinite" and "Invalid Date" problems will be solved already in 10.0.8, I touched that bit when fixing "retry chunks" in #30776

@felixboehm
Copy link
Contributor

Decision for this depends very much on the use case and requirements.
Please provide these, then concept work, then effort and planning.
@pmaier1

@felixboehm
Copy link
Contributor

@pmaier1

@felixboehm felixboehm modified the milestones: development, triage Apr 19, 2018
@hodyroff
Copy link
Contributor

https://github.com/websanova/vue-upload -> 11.0 -> Phoenix hope this is sufficient for most users from a timeframe perspective.

@PVince81
Copy link
Contributor

if this is a full fledge uploader we'll likely need to hack it to make chunking work

if this is just an indicator that we can plug into our own upload code then this is better

@hodyroff
Copy link
Contributor

hodyroff commented Apr 19, 2018

I guess what I wanted to say: There is proper code for frontends around which we can reuse in the future. Not a prio for today.

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

Successfully merging a pull request may close this issue.

9 participants