ETA based on average download speed

[GoogleCodeExporter]

It would be very very useful if Transmission Remote GUI could provide a
"real" ETA, i.e. based on the average downloading speed (instead of the
current one).

It means that Transmission Remote GUI should track for each file the amount
of data completed/uploaded (depending if it's in downloading or seeding
state) since program start and calculate the remaining time given the
remaining size to complete.

The current ETA column is almost useless in fact...

Original issue reported on code.google.com by mauro...@tiscali.it on 18 Feb 2010 at 6:33

[GoogleCodeExporter]

You should request such feature from the Transmission.

Original comment by j...@cp-lab.com on 26 Mar 2010 at 1:48

• Changed state: NoChange

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This feature could be implemented on top of Transmission. The GUI should simply 
track
the total byte transferred for each file during the current session (that is: 
from
the GUI application start time), then calculate the average speed rate and
consequently the ETA.

This wouldn't use a *perfect* average speed (that is, calculated from the file
transfer start), but a very good and acceptable approximation.

Original comment by mauro...@tiscali.it on 31 Mar 2010 at 1:29

[GoogleCodeExporter]

Now that Transmission 2.20 has added the total downloading and seeding time per 
torrent (see https://trac.transmissionbt.com/wiki/Changes#version-2.20b1) it 
would be straightforward to implement such a feature. Could you please 
reconsider your decision?

Thanks in advance.

Original comment by mauro...@tiscali.it on 24 Jan 2011 at 10:06

[GoogleCodeExporter]

I reopened this ticket

Original comment by j...@cp-lab.com on 24 Jan 2011 at 10:20

• Changed title: ETA based on average download speed
• Changed state: New
• Added labels: Type-Enhancement

[GoogleCodeExporter]

Thank you very much!

Original comment by mauro...@tiscali.it on 24 Jan 2011 at 10:29

[GoogleCodeExporter]

As much as this sounds like a good idea, it would be hard to give you what you 
are asking for -- though it depends how how transmission counts 
'download'/'upload' time.

Consider this:
1) DownloadTime as anytime you are 'asking' for more info (or need more 
info)...   
  (incomplete torrent and active)
2) DT as anytime time you've actually downloaded something within the past 5-10 
minutes (i.e. if seeders go away for 24 hours, only the first 5-10 minutes 
would be counted as DL time)
3) DT as anytime you have peers listed and are willing to download (whether or 
not they actually are at the moment; they may be busy with other clients, or 
your
connection may be too crowded with other connections).
   If you have clients you 'could' download from, listed as peers, but the have you
'Snubbed/Choked/Ignored', should that count as DL time?

All of the above can apply to UL time as well...since as soon as you have some 
content and begin offering it for upload, you are uploading  -- so uploading 
time should be considered anytime you have content available, at least, subject 
to same conditions above (snubbing/ignoring/you've choked them, etc...)...

Given all the odd conditions that can affect a download time (and I doubt its 
clearly spelled out in documentation anywhere if I know the transmission 
devs...(and I have had some experience w/them)... they would likely have gone 
with whatever definition they they thought was 'normal' (not thinking that all 
of the above might be considered by someone to be valid definitions...so if you 
don't spell out your  definitions, then what can any statistics based on those 
vague statements be worth?

Worse, what will user's expect them to mean?  

But it would be nice to have an overall indicator...but if transmission doesn't 
document what D/l and U/l time mean, (in light of the above conditions that 
some would argue you are downloading and some would argue that you are not), 
then what would the GUI be able to claim it is showing... (i.e. will users be 
expecting?)..

(They just wanna know when it will be done -- I know!...but it is not very 
simple with BT D/l's    I've seen odd downloads all over the map.  some which 
start fast, 
some which start with 0 seeders for days...then someone drops in for a few 
hours...
and a 20GB d/l finishes!...  and the opposite... starts fast ... goes down to 
trickle -- and either stops altogether (might come back after a week, but I 
didn't know that at the time) or just takes a few weeks (max was about 35 
days... )...

So what can the GUI display that would be meaninful under such circumstances?

I.e. what would you want it to display?   And does transmission gather the 
'right' info that would support such a display?

Just some (probably unwanted) observations/thoughts based reality (also usually 
unwanted! ;-)).

Original comment by astara.a...@gmail.com on 24 Nov 2011 at 12:55

[GoogleCodeExporter]

Hello!
Thanks for your comment.

I don't know how Transmission DT/UT is actually defined, but what I mean is 
that DT and UT should be measured from when the download started (i.e.: from 
when I pressed the "start" button, or I added it and it started automatically).

As a good approximation, it would be acceptable if the DT/UT is measured from 
when the GUI can start to count and now, so bypassing the DT/UT given by 
Transmission. I mean two use cases:
CASE 1:
- I open the GUI
- I start one download: DT and UT start to be counted by the GUI
- (after an hour - I kept the GUI always open): DT/UT is now 1 hour and the 
average download speed is measured as "downloaded size/1 hour" (similar for 
uploaded size)

CASE 2:
- I open the GUI and I find a download that is already running
- I start to count its DT and UT from when the GUI opened
- (after an hour - I kept the GUI always open): DT/UT is now 1 hour and the 
average download speed is measured as "downloaded size during the last hour/1 
hour"

I know they are approximation and I know there are cases (unusual "fast start" 
or "unusual stop", etc.) that throw in crisis even this method: on the other 
hand, we are always talking about an "ETA", so "estimated time" to completion. 
I know it's impossible to give an exact guess, but I think that such averages 
will always have more chance to be more interesting than an ETA based on the 
current speed, which changes significantly every 1 second.

Original comment by mauro...@tiscali.it on 24 Nov 2011 at 7:39

[GoogleCodeExporter]

Original comment by j...@cp-lab.com on 15 Oct 2013 at 2:59

• Changed state: Accepted

[GoogleCodeExporter]

Implemented in r909.
I've used other approach to fix ETA. Now transgui averages out transfer speeds 
using last 20 speeds. It gives correct transfer download speed. Then ETA is 
calculated using this speed. The result is very good :)

Original comment by j...@cp-lab.com on 17 Oct 2013 at 11:24

• Changed state: DevFixed

[GoogleCodeExporter]

Version 5.0 is available.

Original comment by j...@cp-lab.com on 5 Nov 2013 at 6:18

• Changed state: Fixed