Would a last active sort column be useful to you?

peaveyman · Post by **peaveyman** » Sun Sep 14, 2014 1:36 pm

I was told to start this poll to see if this would be a useful addition to Qbittorrent.

Post by **Nemo** » Sun Sep 14, 2014 1:43 pm

I choosed maybe. In all these years I never needed it (and yes im a heavy user both public and private trackers). So if its there or not I wouldn't care that much about it, my opinion.

Post by **Peter** » Sun Sep 14, 2014 6:39 pm

Maybe with an option so you could enable it? Dunno.
I guess it would take a toll on CPU/IO. (Saving all that data, all the time.)

But FIXME.

ciaobaby · Post by **ciaobaby** » Sun Sep 14, 2014 7:00 pm

The Git "wishlist" thread https://github.com/qbittorrent/qBittorrent/issues/517

AsaRossoff · Post by **AsaRossoff** » Thu Sep 18, 2014 7:08 am

Another maybe

I would have to experience it I think to see if it helped me manage my torrent priorities.

I do not necessarily share the concern that it would generate too much I/O, though:
1. Turnover of my active torrent list even when seeding hundreds of torrents is not massive. The "Uploaded" data changes constantly for all the active torrents, but I get maybe at most an average of one or two torrents per second or two in and out of active state.
2. Torrent settings are or will be cached in memory as I understand, and presumably are not saved at every change, but periodically (e.g. once a second or two or less). I'm making assumptions here from my impression...

I know Windows operating systems long ago disabled updating "Last Accessed" in their filesystems (without changing a setting that is discoverable only to the advanced/very inquisitive users) for performance reasons. But in file systems and modern OS's, hundreds or thousands of files may be being continuously "accessed"... and those directory entries to update are spread throughout the drive. Very different level of disk activity involved in that case.

edit: 3. There is no need to write the last active data to disk more frequently than disk writes are needed for other purposes. As to CPU, the calculation is very simple. All active torrents were last active Now() (calculate once), and inactive torrents do not need any calculation. So I see the only impact as a single global calculation for all active torrents per refresh cycle.
(though I'm entirely uncertain if it would be valuable, it seems like it could be implemented as in #3 and have negligible performance impact)

ciaobaby · Post by **ciaobaby** » Thu Sep 18, 2014 10:24 am

But in file systems and modern OS's, hundreds or thousands of files may be being continuously "accessed"... and those directory entries to update are spread throughout the drive.

Given M$ Windows ridiculous "optimistic cache" system even that causes "issues" (aka 'cache runaway')

So I see the only impact as a single global calculation for all active torrents per refresh cycle.

What of the case where many hundreds of tasks may be 'active' and require a file write? Such a scenario would be far from trivial.
The default is for a GUI refresh is 1000ms (1s) to write new data to more than a handful of files could take more that, a single open - read - write - close cycle happens in less than the blink of an eye in human time scales, in computer time scales, ... it is close to eternity, and I cannot imagine the impact on Windows caching having to reserve space for those files.

Think about this:
At one extreme end of this proposal lies exactly the same issues that uTorrent has, has no one actually considered that? uTorrent has such a 'feature' and has resource "hogging" problems that you want to get away from, yet here you are asking for a client that currently has no such issues to add a 'feature' that is very likely to lead to similar issues.

Does that actually make sense to anyone? It is the "If it ain't 'broke', ... ... Fix it until it is paradigm. Just because you can does not mean you should.

Post by **sledgehammer_999** » Thu Sep 18, 2014 7:41 pm

Skimmed through the last posts so I may misread them:

The user is asking for last active on the torrent not on the files, while in session.
This info by itself(as new column) adds the same miniscule overhead as any other column we support.
However if you have ALL columns active with 2000+ torrents then you should expect some CPU, although v3.2.0 contains huge optimizations on this part and you may still see minimal CPU usage for drawing the GUI. (unless you put <1s refresh interval)

peaveyman · Post by **peaveyman** » Thu Sep 18, 2014 8:58 pm

When I say last active I mean when a torrent is accessed on my computer and bytes are transfered I would like that torrent to jump to the top of the list so I know what was accessed. Hope this makes sense.

Post by **sledgehammer_999** » Fri Sep 19, 2014 11:49 am

That's the same I am talking about. The last time something was downloaded or uploaded from/to that torrent.

AsaRossoff · Post by **AsaRossoff** » Fri Sep 19, 2014 12:02 pm

Hi peaveyman - I think sledgehammer_999 is assuming you are only interested in this information during the current session (since you start qBittorrent), and that you don't care about older history. So I think that is the area you could clarify. Do you want it for the current session (only), or for all time?

Hi ciaobaby - if we want to preserve the data between sessions (as I think you and I were assuming), my suggestion was to write that data to disk at the same frequency that we would write data for those torrents to disk anyway, which I suspect is sufficient resolution. For example, we already preserve "Time Active" which changes at exactly the same frequency as Last Active would. Active torrents will have data transfer, and that will be recorded at some point.. I don't know the implementation details. I was saying we can avoid any additional disk writes. I don't think the resolution of this statistic between sessions needs to be higher than any other data.

peaveyman · Post by **peaveyman** » Fri Sep 19, 2014 1:27 pm

The current session would be fine, I'm sure. The time active column seems to act like a time added column to me. Is this correct?

ciaobaby · Post by **ciaobaby** » Fri Sep 19, 2014 2:15 pm

"time active" does not require any file writing other than the initial start time of the task, to store a 'last active' time requires processing and a file write each and every time the "activity state" changes from active to 'inactive' and when it changes from inactive to active.

Remember it is not how your particular client behaves that determines whether this will be excessive or not, you have to consider a worst case scenario where tasks maybe switching between active and inactive every minute, or worse. Sure, hysteresis could be built into the write trigger to avoid such fibrillation but this then makes the "past active" much less than accurate.

Then what happens at client close? It is another set of values that have to be committed to disk, thus exponentially increasing the delay before it is 'safe' to power down, (another uTorrent 'issue').

Do we really need to be turning qBT into uTorrent albeit minus the advertising?

AsaRossoff · Post by **AsaRossoff** » Fri Sep 19, 2014 4:28 pm

ciaobaby wrote: "time active" does not require any file writing other than the initial start time of the task, to store a 'last active' time requires processing and a file write each and every time the "activity state" changes from active to 'inactive' and when it changes from inactive to active.

My initial comment: {Time Active does not increment when the torrent is paused. However, I was in error in saying it would be equally volatile to the proposed column. It actually is a sum of time that the torrent is started and running (and obviously, qBittorrent is running). It is actually more volatile than the proposed column, because it applies to all unpaused torrents.}
edit: Ah, I see what you mean. It's possible to implement that by storing only the previous totals + the start time of the task, risking losing the most recent active time data if qBT is not shutdown properly or something goes wrong.

I doubt the technical issues you raise apply, for the reasons I already explained (i.e.: don't have this column trigger a disk write, one will occur soon enough anyway), but it's pointless to speculate. The answer is in the implementation.

Do we really need to be turning qBT into uTorrent albeit minus the advertising?

There I sympathize greatly.
I agree that we should not. At one time, uTorrent was known for it's simple elegance and efficiency. I agree we should be selective with features. I already cast my vote on this feature: maybe

and equally true: maybe not.

peavyman, can you elaborate on the value this information has to you? Does it help you in some way that you can explain?

peaveyman · Post by **peaveyman** » Fri Sep 19, 2014 4:37 pm

I have over 1000 torrents. I want to know which ones have been active and a last active column is the best way for me to do this.

AsaRossoff · Post by **AsaRossoff** » Fri Sep 19, 2014 4:44 pm

I have a large number of torrents as well.
I realize you want to know, but does the information help you in some way? For example, do you use it to manage your torrents?

If it serves a practical purpose you can explain, then it is much easier to convince the devs that it is important.

qBittorrent official forums