Open mschumacher69 opened 2 years ago
Additional context
No response
Have you really nothing to provide? At least have the affected torrents metadata or they are added using Magnet links?
Log(s) & preferences file(s)
No response
Well, your configuration file can hardly help me with anything, but here's a screenshot of the qBittorrent window with your torrents in it and a log for the last couple of app launches with your comments about where the re-added torrents are mentioned there would be very useful.
Every time I restart qB, it re-adds RSS downloads
qBittorrent cannot re-add existing torrent. Most likely the problem is in something else. Could you temporarily disable adding torrents from RSS and see what happens to the Added On Date of previously added torrents?
Have you really nothing to provide? At least have the affected torrents metadata or they are added using Magnet links?
The affected torrents are all auto added by RSS from the feeds below: https://rarbgunblock.com/rssdd.php?category=18;41 https://rarbgunblock.com/rssdd.php?category=54 I believe those feeds provide magnet links.
Well, your configuration file can hardly help me with anything, but here's a screenshot of the qBittorrent window with your torrents in it and a log for the last couple of app launches with your comments about where the re-added torrents are mentioned there would be very useful.
Here are the logs from the last time qB was started: qbittorrent.log.zip
Could you temporarily disable adding torrents from RSS and see what happens to the Added On Date of previously added torrents?
I will try that the next time I restart qB and let you know what happens.
I don't think the problem is RSS-related because i don't use RSS at all and the "added on" date problem happens to me too.
this happens with many magnet links that i add in paused mode and i leave them paused without ever starting to download.
My default settings is to never start downloads automatically and, when i add them, i wait for the torrent settings window to finish retrieving metadata from DHT and only then press the OK button to add the torrent to the queue, without ever ticking the checkbox that says "Start torrent".
The file will get added to the queue in 'paused' mode and sometimes i almost forget it there for a few days (and a few normal computer restarts during this time) until i look over the list and decide whether to start it or not. Then the 'added today' date issue becomes really annoying since i clearly remember i added it a few days before.
(edited a lot: re-ordered the list of issues below) this issue is a long time standing issue in qBittorrent ... i found similar problems described in
https://github.com/qbittorrent/qBittorrent/issues/929 (issue still open since 2013) https://github.com/qbittorrent/qBittorrent/issues/4234 https://github.com/qbittorrent/qBittorrent/issues/4405 https://github.com/qbittorrent/qBittorrent/issues/7605 https://github.com/qbittorrent/qBittorrent/issues/12940 https://github.com/qbittorrent/qBittorrent/issues/13228 https://github.com/qbittorrent/qBittorrent/issues/14942
and yes, i'm using the current official v4.3.8 64-bit build on Win 10 Pro, 21H2 edition.
Good point, thanks for your input. If it also happens to you and you don't use RSS, then yes it is not RSS related because it is indeed torrents that are added to the queue in the paused state that are having this issue. I thought it is RSS related because I thought they were being re-added from the RSS feed upon restart.
I think this started happening since the sort logic was changed in a recent qB release iirc.
@qbittorrent/bug-handlers Can someone test it? I have not been able to confirm it in my quick tests with the current master + latest libtorrent 2.0.x.
I can reproduce with 4.3.8. I can't with a 2 month old build from CI (1.2.x libtorrent).
I can reproduce with 4.3.8. I can't with a 2 month old build from CI (1.2.x libtorrent).
@thalieht, could you test the master as well (at least with libtorrent 1.2)?
Btw, this doesn't happen to older queued paused torrents, only to recent ones. That's why at first I thought they were being re-added from RSS because I thought it's the ones that are still in the RSS feed.
Btw, this doesn't happen to older queued paused torrents, only to recent ones
It would be useful to take a look at the .fastresume
files of both.
I can reproduce with 4.3.8. I can't with a 2 month old build from CI (1.2.x libtorrent).
@thalieht, could you test the master as well (at least with libtorrent 1.2)?
Can't reproduce with master either (libtorrent 1.2.x).
It would be useful to take a look at the .fastresume files of both.
Here are some samples (added .log to allow the files to be uploaded, just remove it from the end of the files):
A recently added torrent whose date added hasn't been modified yet because qB hasn't been restarted since the torrent was added but would certainly change once qB is restarted: 3a95563d0870bae8207e77ccfdb387d81021a693.fastresume.log
A torrent whose date added was changed when qB was last restarted on Oct 18: 135f91a3297646b0a82b9c0a10475f218b00a07d.fastresume.log
Some older torrents whose date added wasn't changed when qB was last restarted on Oct 18: 478c98ad6d8dc68b659de98247e73dc1eb0c017b.fastresume.log 55c58a69a0625e8239e8002ce54c540d6e2992df.fastresume.log
Hope this helps.
I have the same issue too on: qBittorrent: 4.3.5 x64 (latest in OS) Operating system: Fedora 33 Qt: 5.15.2 libtorrent: 1.2.13.0
The Added on
date get changed to current start time only for some (but every time the same) paused torrents in the list (with 0.0% downloaded).
Not sure if this was supposed to be fixed in 4.3.9, but just saying that it hasn't been fixed.
After updating, the Added Date of most recently added paused torrents that haven't been started yet has been changed to today.
@mschumacher69 the fix didn't make the cut-off for 4.3.9
release but it's in 4.4.0rc1
which is available to download, link on main site.
Thanks. Any known issues in 4.4.0rc1 I should be worried about or shall I just jump in?
OK so I installed 4.4.0rc1 and it doesn't seem to have fixed the issue.
When I started 4.4.0rc1 after installing it, it still changed the added on date of many torrents which are still in paused state.
Or would this be fixed the 2nd time I start 4.4.0rc1?
When I started 4.4.0rc1 after installing it, it still changed the added on date of many torrents which are still in paused state.
Yes, since they have no valid "added on date" stored.
Or would this be fixed the 2nd time I start 4.4.0rc1?
It's supposed to do.
Thanks. So what was causing this issue? Were paused torrents being added without a valid added on date? And why is it only affecting some paused torrents, but not all?
OK so this is still an issue on rc1.
I think torrents which were added on rc1 are OK now and aren't having their Date Added changed upon restart, but previous torrents that always had their Date Added changed upon restart are still having their Date Added changed.
OK so this is the second time I restart rc1 and there are still a large amount of torrents that get changed to today.
Is there a way to get their added date to stick? Would starting them and pausing them get it to stick?
Would starting them and pausing them get it to stick?
Looks like it should work. Or you can change some other property to force the torrent data to be overwritten (e.g. change torrent category to another one and then back).
This seems to have worked, I just started them and stopped them and the added on date seems to have stuck after the restart.
Thanks!
@mschumacher69 Thank you for your feedback.
I have the same issue on 4.3.9 Win10 1809. I can confirm this is mildy annoying. Thanks for the proposed fix mschumacher69!
qBittorrent & operating system versions
qBittorrent: 4.3.8 x64 Operating system: Windows 11 Pro 21H2 22000.258 x64 (10.0.22000)
What is the problem?
Every time I restart qB, the Added On date of recent torrents that were added in paused state and have never been started changes to today which messes up the order (I sort by Added On) and I wouldn't know which torrents are new anymore.
Steps to reproduce
Additional context
No response
Log(s) & preferences file(s)
No response