"Last Seen Complete" latch and remember

[a-raccoon]

Suggestion

This could possibly qualify as a bug report, but I didn't want to quibble.

We want the "Last Seen Complete" column to remember the timestamp for each torrent, and remember it real good.

Current behavior: A torrent's "Last Seen Complete" time increments steadily with the current time when it is active and well seeded (but ONLY if it is well seeded). This timestamp is not remembered between sessions and the whole column is blank when first starting the client. When an active torrent isn't very well seeded or only connected to a handful of peers, the "Last Seen Complete" column often shows a timestamp from one of the peers, and then it blanks when it gets nul information from another peer later on, or it might be replaced by an even older timestamp than had previously been there.

There is no REMEMBERING mechanism to make sure the last known timestamp is retained and persists over time and between sessions. There is no LATCHING mechanism to make sure that the timestamp never travels back in time and only marches on forward (min-max).

Use case

The ability to glance at a torrent's "Last Seen Complete" time and know that it hasn't time traveled or gotten lost. It was ACTUALLY seen completed on such-date at such-time, and we remember this without the need to take external notes on a pad of paper like cavemen.

Extra info/examples/attachments

8/20/2023 4:30 PM

P.S. The "Last Seen Complete" column is only very useful when dealing with torrents that are not well seeded. But this column only works when a torrent is well-seeded. So it is not very useful right now.

[a-raccoon]

Extra suggestion / bug report:

The "Last Seen Complete" column sorts empty (null) entries as "newest" instead of "oldest". This makes it very difficult to sort the column in any useful manner. Empty entries should either sort as "oldest", or they should always sort to the bottom of the page.

[DarkVoyage]

Agree with additional message and can't really confirm the main message. I have a long history of waiting for alive seed for some torrents and almost 6 year qBT history of torrents. Many of dead torrents show "Never" and I believe that this is true, they are dead for years. And some torrents show a date of several years ago. Of course torrents that once became active now show any current date, because I seed them and there are others too. So I don't understand the case at all...

You use a strange word "latch", while any info for each torrent is updated visually and stored in db inside its resume data. So if anything is lost - it is lost not because it is not "latched", it is lost because it is lost (damaged/not saved in timely manner/you guess...).

I understand your message that some more actual date is replaced by earlier date or "never" after... what? Restart of qBT? Some data is not saved well between sessions. There's a resume data save interval in settings. But how did you catch that at all? Do you remember that date yourself and why do you need it at all? The best way to fight dead torrents is to search alternative or to buy that content yourself. This is very rare situation, when there's no replacement at all, especially for something popular or currently available. There's a always a shorter way to simply forget about dead torrents and get that somewhere else...

[a-raccoon]

I use the word latch, because as different non-seed (under 100%) peers come and go, the Last Seen Complete date is replaced by whatever the most recently connected peer says they last saw. It's all very hearsay and word-of-mouth, but while other torrent clients try to remember the last time they saw a torrent completed, qBittorrent does not. It does NOT store it in the resume data, only temporary session data, and the time will swing up and down like a roller coaster because it doesn't attempt any min-max to latch onto the most recently seen time and march forward from there... never looking to the past.

Anyway, I'm an archivist of rare and dead things, and so having a more useful Last Seen Complete column would be rather swell.

[DarkVoyage]

By the way, last seen complete should update, if all peers together had all pieces, but not exactly any of them has whole torrent, they may be partial seeds. There's a counter near piece bar that shows how many copies of complete material you see at once.

As I told - this parameter updates normally and I see all variants - never, one year ago, one week ago, one day ago. When you have thousands of torrents, then you have some part that is seeded badly, because not supported by an archivist (special person, who keeps a torrent online 24/7). I'm an archivist myself, so I'm interested to get those and keep.

To get this fixed, you first need to prove with screenshots that new date was not saved and returned to previous state. But you will still get a recommendation to set this parameter to anything above 0 and not too high. I doubt it can be done any other way:

But I don't recommend to set this parameter at all, because it leads to situation, when qBt can stuck in memory after exit saving the resume data cyclically for thousands of torrents. Any info should be saved automatically on update or exit.

In fact qBt should save resume data only in case it changed in any significant field. But at same time "last seen complete" is updated all the time, while you seed it. And you get these useless updates... It is unsolvable.

Any resume data is not saved well only if qBt crashes during session.

[as-muncher]

I would like to add that I'd like to see the "Last Seen Complete" output something like "Now, 6 years ago" or something like that, not just "Now", when you've actually been waiting 6 years to finish that torrent. If I've been waiting a super long time for a torrent to complete, I'd want qbittorrent to prioritize getting that data as soon as possible, putting the more-available torrents on a lower priority.

[DarkVoyage]

You describe it like it is a very important field with information that needs to be saved for our descendants that should continue wait for seed no matter what. This is just working field that nobody cares for. Torrent that had no seed for 6 years is dead torrent, it is nearly impossible that it will ever be seeded again. And you should always make a decision that anything that was not seeded for more than a year is most likely dead and you should search for better source.

Also you tell about it like you have over 100k torrents and you will have too low priority for anything that suddenly became available. Anyway it needs to be online for long enough and have enough speed to be downloaded at all. But if it so important, it is you who should build special architecture around such torrents... The main focus of any client should be stability of what is normally seeded and seeding of it.

[a-raccoon]

@DarkVoyage, it is literally a very important field with information that needs to be saved for our descendants that should continue wait for seed no matter what. I have given instructions to my children.

There is no point in even having a Last Seen Complete column if it does not (A) retain data, and (B) only go forward; but never backwards. Eliminate this column if you must, but don't tease me.

[a-raccoon]

@as-muncher, Check out the Time Active column, I place them next to each other. And I would definitely go for a download priority where other torrents are throttled in order to allow maximum bandwidth priority to the oldest Time Active torrents. This usually covering the sort of scenarios you're talking about too.

[Jerfer02]

Was just about to report this bug.

I recently upgraded from 4.3.9 to 4.6.1.

The "Last Seen Complete" field worked perfectly in 4.3.9! What a shame.

The "Reannounce In" field is also broken, but I guess that's a different bug report.