Opened 12 years ago

Closed 10 years ago

Last modified 10 years ago

#1408 closed Enhancement (fixed)

Remember total downloading and seeding time per torrent

Reported by: ameeps Owned by: Longinus00
Priority: Normal Milestone: 2.20
Component: libtransmission Version: 1.34
Severity: Normal Keywords: seeding
Cc: noone3@…

Description (last modified by livings124)

Display the total downloading and seeding time (per torrent) presumably in the dates section of the Activity section of the torrent inspector.

Attachments (4)

activetime.patch (4.3 KB) - added by Elbandi 10 years ago.
runTimes.patch (6.8 KB) - added by Longinus00 10 years ago.
minSeedTime.patch (12.3 KB) - added by Longinus00 10 years ago.
potential application for runtimes
times.diff (7.2 KB) - added by charles 10 years ago.
rough patch. a simpler implementation, but possibly too vulnerable to a blocked libtransmission thread?

Download all attachments as: .zip

Change History (29)

comment:1 Changed 12 years ago by ameeps

  • Milestone changed from 1.40 to None Set
  • Priority changed from High to Normal
  • Version changed from 1.34+ to 1.34

Display the total seeding time (per torrent) presumably in the dates section of the Activity section of the torrent inspector and also display downloading time.

comment:2 Changed 12 years ago by livings124

  • Description modified (diff)
  • Summary changed from Total seeding time per torrent to Total downloading and seeding time per torrent

comment:3 Changed 12 years ago by livings124

  • Component changed from Transmission to libtransmission

comment:4 Changed 11 years ago by charles

  • Resolution set to invalid
  • Status changed from new to closed

This was requested over a year ago (as a high priority no less ;) and nobody has seconded this request. Since this doesn't appear to be in demand, I'm closing this ticket.

comment:5 Changed 11 years ago by livings124

  • Resolution invalid deleted
  • Status changed from closed to reopened

I really like this idea, and remember closing other tickets as duplicates.

comment:6 Changed 11 years ago by charles

I don't remember that... but since you want it, I'll look into it.

comment:7 Changed 10 years ago by Longinus00

  • Milestone changed from None Set to 2.20
  • Owner changed from charles_ to Longinus00
  • Status changed from reopened to new

comment:8 Changed 10 years ago by dskchk

Once this is done, another (very) useful feature could be easily added: a more precise ETA based on the average speed, calculated using the total downloading/seeding time vs the actual downloaded/uploaded size. I don't mean to replace the current ETA with the new one, but to provide another (with a different name).

comment:9 Changed 10 years ago by dskchk

  • Cc noone3@… added

comment:10 Changed 10 years ago by charles

What is the use case for having two ETAs?

comment:11 Changed 10 years ago by livings124

What is the benefit of an ETA based on speeds from potentially days earlier?

comment:12 follow-up: Changed 10 years ago by dskchk

Given the fact that my connection has always the same bandwidth available and that it's unusual that the average download speed of a Torrent varies in a significant way while downloading, an ETA of this kind would be much more precise to estimate the time to completion. As of now, the ETA is calculated at every refresh, based on the current speed. Of course, this is quite useless, unless you have a Torrent which is downloading at an almost fixed rate (never happened to me). Actually, as of now I have no idea on how long it would take to download a file, especially if it's huge and if it's poorly shared.

Other P2P software have this function (e.g.: mldonkey/sancho) and it works.

Last edited 10 years ago by dskchk (previous) (diff)

comment:13 in reply to: ↑ 12 Changed 10 years ago by charles

I'm not following this reasoning. First you say it's unusual for your average download speed for a torrent to vary in a significant way. Then you say that you've never had a torrent download at a fixed rate. These two statements seem to contradict each other.

If download speeds vary and we can't use the past to predict the future, then weighing previous speeds more heavily will make the ETA less accurate. If download speeds don't vary in a significant way, then weighing the previous speeds more heavily shouldn't make any difference at all.

Lastly, the current ETA model is not solely based on the current speed. It uses an average speed from over the last few time slices.

comment:14 Changed 10 years ago by dskchk

I said the the average speed is quite constant (because 1. my available bandwidth is always the same and 2. it's unusual that a torrent changes its availability a lot while downloading... it may happen only for the just shared torrents), while the current speed varies continuously. This is not contradictory. In this situation the calculation of the average speed gives a good approximation of the remaining time. So, it's not completely true that you can't use the past to predict the future.

If I have spent 1 day to download 100 MB of a file and I am at 50%, it's more reasonable that it will take another day to download the remaining 100 MB, rather than expecting the average downloading speed (calculated on the remaining 100 MB) to be doubled or halved. And, even if it happened, if the average speed (and the new ETA) is calculated continuously, the new ETA will keep on quickly converging to the exact result over time, so it will still be pretty accurate (of course, you can't pretend the perfection for any method you try).

You said that the current ETA uses not only the current speed, but an average from over the last few time slices. I don't know what you mean by "few time slices", but I can state for sure that the current ETA is completely unreliable (except for seeding time, if you are uploading at an almost fixed - and maybe capped - rate).

I have used different P2P programs a lot and I always observed this behaviour. I'm not inventing anything.

Last edited 10 years ago by dskchk (previous) (diff)

comment:15 Changed 10 years ago by charles

I don't see the benefit to this. Of course, I don't see much benefit in the original enhancement request either... but even so I see less benefit to this new suggestion, and also think it's a separate feature that shouldn't be shoehorned into an already-milestoned ticket.

comment:16 Changed 10 years ago by dskchk

I'll open a new ticket then. However, I really can't understand the reason of your reluctance about this feature, which is absolutely reasonable to me and is already present in other P2P applications: isn't knowing a better estimate to complete enough benefit for you? Maybe you have an excellent Internet connection that guarantees you an almost fixed download rate (although it sounds strange to me, since the download rate depends on other's upload rate), so that your current ETA reported by Transmission is somewhat precise over time... lucky you!

Changed 10 years ago by Elbandi

comment:17 follow-up: Changed 10 years ago by Elbandi

I think, it should be updated more frequently, than torrent start/stop. (if the T is crashed, the last activ time is lost). But i dont know where: every 1/10/100 sec?

comment:18 in reply to: ↑ 17 Changed 10 years ago by Longinus00

Replying to Elbandi:

I think, it should be updated more frequently, than torrent start/stop. (if the T is crashed, the last activ time is lost). But i dont know where: every 1/10/100 sec?

Just to let you know I already have a working version of this. I'm sitting on it because #671 (and probably #2955) should go in first as the code touches the same things and refactoring the conflicts is a waste of time.

Changed 10 years ago by Longinus00

Changed 10 years ago by Longinus00

potential application for runtimes

Changed 10 years ago by charles

rough patch. a simpler implementation, but possibly too vulnerable to a blocked libtransmission thread?

comment:19 Changed 10 years ago by charles

r11583: times.diff added to trunk for testing

comment:20 Changed 10 years ago by livings124

r11584 display this in the Mac interface

comment:21 Changed 10 years ago by charles

  • Resolution set to fixed
  • Status changed from new to closed

comment:22 Changed 10 years ago by Elbandi

Charles, you forgot to document this at rpc spect. and the t remote isn't display this.

comment:23 Changed 10 years ago by livings124

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:24 Changed 10 years ago by charles

  • Resolution set to fixed
  • Status changed from reopened to closed

r11597: added to rpc spec and to transmission-remote --info

comment:25 Changed 10 years ago by jordan

  • Summary changed from Total downloading and seeding time per torrent to Remember total downloading and seeding time per torrent
Note: See TracTickets for help on using tickets.