starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

Torrents disappear and reappear #5027

New issue

Closed

opened 2026-02-21 17:37:47 -05:00 by deekerman · 18 comments

deekerman commented

2026-02-21 17:37:47 -05:00

Owner

Originally created by @ahmedtds on GitHub (Dec 21, 2016).

I think this started to happen in last 1-2 releases. I'm using 3.3.10 now. And I'm using Windows 7 32bit.

For example I had a torrent in %60 downloaded status, and one day I open qbittorrent and it's not there. It's not on the list. It didn't appear in download list whole day but another day I open qbitorrent ta-da it's there. My %60 downloaded torrent is on the list again and I can continue to download it. But then I realize it came back but another torrent disappeared from list. I close and reopen and that comes back too but another one disappears.

I'm using qbittorrent for a long time and didn't have such a problem until recently.

It's just weird and annoying. Why this is happening?

Originally created by @ahmedtds on GitHub (Dec 21, 2016). I think this started to happen in last 1-2 releases. I'm using 3.3.10 now. And I'm using Windows 7 32bit. For example I had a torrent in %60 downloaded status, and one day I open qbittorrent and it's not there. It's not on the list. It didn't appear in download list whole day but another day I open qbitorrent ta-da it's there. My %60 downloaded torrent is on the list again and I can continue to download it. But then I realize it came back but another torrent disappeared from list. I close and reopen and that comes back too but another one disappears. I'm using qbittorrent for a long time and didn't have such a problem until recently. It's just weird and annoying. Why this is happening?

deekerman closed this issue

2026-02-21 17:37:50 -05:00

deekerman commented

2026-02-21 17:37:51 -05:00

Author

Owner

@zeule commented on GitHub (Dec 21, 2016):

Have this problem since May. As far as I know, qBt finds all my torrent and fastresume files and submit all of them to libtorrent. Did not trace it further. As a workaround, it you see missing torrent, you can wait for a few minutes after starting qBt, then kill it (I use SIGKILL), relaunch, and the number of loaded torrents will increase with quite high probability.

@zeule commented on GitHub (Dec 21, 2016): Have this problem since May. As far as I know, qBt finds all my torrent and fastresume files and submit all of them to libtorrent. Did not trace it further. As a workaround, it you see missing torrent, you can wait for a few minutes after starting qBt, then kill it (I use SIGKILL), relaunch, and the number of loaded torrents will increase with quite high probability.

deekerman commented

2026-02-21 17:37:51 -05:00

Author

Owner

@tempaccount102 commented on GitHub (Dec 21, 2016):

PLEASE PLEASE PLEASE add an option to save all config and resume data etc to a custom backup file, including search engines configs etc. This would make QBittorrent bulletproof! THANK YOU SO MUCH! I had to reconfigure everything from scratch about 10 times now and it's ridiculously frustrating.

@tempaccount102 commented on GitHub (Dec 21, 2016): PLEASE PLEASE PLEASE add an option to save all config and resume data etc to a custom backup file, including search engines configs etc. This would make QBittorrent bulletproof! THANK YOU SO MUCH! I had to reconfigure everything from scratch about 10 times now and it's ridiculously frustrating.

deekerman commented

2026-02-21 17:37:51 -05:00

Author

Owner

@magma1447 commented on GitHub (Dec 22, 2016):

Related to #5950 ? I have had that issue since 3.3.6 I think. Never tested 3.3.5 and I have downgraded to 3.3.4 where I have no issues at all.

@magma1447 commented on GitHub (Dec 22, 2016): Related to #5950 ? I have had that issue since 3.3.6 I think. Never tested 3.3.5 and I have downgraded to 3.3.4 where I have no issues at all.

deekerman commented

2026-02-21 17:37:51 -05:00

Author

Owner

@ahmedtds commented on GitHub (Dec 22, 2016):

@evsh I tried your method but it doesn't help it just happens randomly. Doesn't matter you kill process or close it properly, at least for me. Just randomly things disappear.

Is there any chance this would be fixed soon? Otherwise I'll downgrade or switch to another client. Because this is so annoying.

@ahmedtds commented on GitHub (Dec 22, 2016): @evsh I tried your method but it doesn't help it just happens randomly. Doesn't matter you kill process or close it properly, at least for me. Just randomly things disappear. Is there any chance this would be fixed soon? Otherwise I'll downgrade or switch to another client. Because this is so annoying.

deekerman commented

2026-02-21 17:37:51 -05:00

Author

Owner

@zeule commented on GitHub (Dec 22, 2016):

I plan to investigate the problem on these holidays.

@zeule commented on GitHub (Dec 22, 2016): I plan to investigate the problem on these holidays.

deekerman commented

2026-02-21 17:37:52 -05:00

Author

Owner

@zeule commented on GitHub (Dec 23, 2016):

@nxd4: Does your fix mean that the problem is that qBt fails to read queue position from a .fastresume file, does not detect this situation and silently replaces element with key 0 in the queue of resumed files?

@zeule commented on GitHub (Dec 23, 2016): @nxd4: Does your fix mean that the problem is that qBt fails to read queue position from a .fastresume file, does not detect this situation and silently replaces element with key 0 in the queue of resumed files?

deekerman commented

2026-02-21 17:37:52 -05:00

Author

Owner

@zeule commented on GitHub (Dec 23, 2016):

thanks!

@zeule commented on GitHub (Dec 23, 2016): thanks!

deekerman commented

2026-02-21 17:37:52 -05:00

Author

Owner

@zeule commented on GitHub (Dec 29, 2016):

@nxd4: when we fix resume data generation, your fix will be needed to load already corrupted files. Will you open a PR yourself, please?

@zeule commented on GitHub (Dec 29, 2016): @nxd4: when we fix resume data generation, your fix will be needed to load already corrupted files. Will you open a PR yourself, please?

deekerman commented

2026-02-21 17:37:52 -05:00

Author

Owner

@Forceflow commented on GitHub (Jan 1, 2017):

Definitely experiencing this on a fresh 3.3.7 install on Ubuntu 16.10 as well. Only using qbittorrent-nox, and re-starting that does not "remember" the torrents I already had running.

Compiling from source to see if it is present in more recent versions as well.

@Forceflow commented on GitHub (Jan 1, 2017): Definitely experiencing this on a fresh 3.3.7 install on Ubuntu 16.10 as well. Only using qbittorrent-nox, and re-starting that does not "remember" the torrents I already had running. Compiling from source to see if it is present in more recent versions as well.

deekerman commented

2026-02-21 17:37:52 -05:00

Author

Owner

@Quantum00 commented on GitHub (Jan 7, 2017):

#5936 looks to be the same! Finally! This should really be high priority!

@Quantum00 commented on GitHub (Jan 7, 2017): #5936 looks to be the same! Finally! This should really be high priority!

deekerman commented

2026-02-21 17:37:52 -05:00

Author

Owner

@ghost commented on GitHub (Jan 16, 2017):

I'm also experiencing this problem. I have 3.3.7 on Xubuntu 16.10.

Torrents added after upgrading to 3.3.7 disappear, while old torrents added in 3.3.6 remain. I even tried downgrading to 3.3.6, added some torrents, and then upgraded back to 3.3.7. All the torrents added with 3.3.6 remained, while new torrents under 3.3.7 disappears.

It seems to me that 3.3.7 (and above) is not able to save torrent data on exit, but it can resume torrents added with 3.3.6 (and lower).

@ghost commented on GitHub (Jan 16, 2017): I'm also experiencing this problem. I have 3.3.7 on Xubuntu 16.10. Torrents added after upgrading to 3.3.7 disappear, while old torrents added in 3.3.6 remain. I even tried downgrading to 3.3.6, added some torrents, and then upgraded back to 3.3.7. All the torrents added with 3.3.6 remained, while new torrents under 3.3.7 disappears. It seems to me that 3.3.7 (and above) is not able to save torrent data on exit, but it can resume torrents added with 3.3.6 (and lower).

deekerman commented

2026-02-21 17:37:52 -05:00

Author

Owner

@WaterSibilantFalling commented on GitHub (Jan 16, 2017):

I have the same problem. I have been investigating with the GUI, the web interface and via the python-qbittorrent API.

To me, it seems that if you quit qBittorrent, all the torrents added since the last Save Resume are lost.

The fix would be for qBittorrent to always do a Save Resume before quitting.

Libtorrent 1.0.10.0
boost 1.62.0
Linux 4.8.0-2-686-pae #1 SMP Debian 4.8.15-2 (2017-01-04) i686 GNU/Linux

@WaterSibilantFalling commented on GitHub (Jan 16, 2017): I have the same problem. I have been investigating with the GUI, the web interface and via the python-qbittorrent API. To me, it seems that if you quit qBittorrent, all the torrents added since the last Save Resume are lost. The fix would be for qBittorrent to always do a Save Resume before quitting. Libtorrent 1.0.10.0 boost 1.62.0 Linux 4.8.0-2-686-pae #1 SMP Debian 4.8.15-2 (2017-01-04) i686 GNU/Linux

deekerman commented

2026-02-21 17:37:52 -05:00

Author

Owner

@ghost commented on GitHub (Jan 16, 2017):

@RichardWilliamPearse
Thanks for the tip! Is this only possible with the python api?

@ghost commented on GitHub (Jan 16, 2017): @RichardWilliamPearse Thanks for the tip! Is this only possible with the python api?

deekerman commented

2026-02-21 17:37:52 -05:00

Author

Owner

@WaterSibilantFalling commented on GitHub (Jan 17, 2017):

Ah, I just lost(*) a torrent that was at 90-something %, and had definitely been Save Resumed, so what I observed - which is right, I tried "add torrent+quickly quit+restart--> torrent gone" many times - is only part of the 'torrent missing' story.

So, I think that there are two (or more) components:

newly added torrents that haven't been Resume Saved disappear
another process that lead to torrents disappearing
and maybe another too...

In answer to your question, I tried this (add, quickly delete, restart, inspect) via the Web Interface, the Qt Gui and via the python-qbittorrent API (qb.shutdown()), and newly added torrents were always missing if I quit straight away after adding a torrent.

* this is interesting: When I say "lost", the 90% downloaded *.!qB files were - are - still in my torrenting 'tmp' directory, the torrent had just disappeared from the displayed list. When I then re-added the *.torrent file again, qBittorrent (the Qt GUI) popped up the dialog "this torrent is already in your download list, merging trackers". So, qBittorrent remains aware of the torrent in one way, perhaps by looking for it via the fingerprint of its hash in my torrenting tmp dir, but does not display it. When I added a different *.torrent file with actually the same hash (you know, sometimes there are multiple differently-named torrents that are actually for the same file(s)/torrent), that differently-named torrent (that is, actually, the same torrent as one already in my torrenting tmp dir) DID get added to qBittorrent's GUI's torrent download list. Unfortunately, this new copy (same hash as 'lost' torrent, different name) hasn't connected with any sources yet, still "Downloading Metatdata', so I can't "Force Recheck" to see if qBittorrent really sees this new copy torrent as the same as the existing "lost" torrent.

@WaterSibilantFalling commented on GitHub (Jan 17, 2017): Ah, I just lost(*) a torrent that was at 90-something %, and had definitely been Save Resumed, so what I observed - which is right, I tried "add torrent+quickly quit+restart--> torrent gone" many times - is only part of the 'torrent missing' story. So, I think that there are two (or more) components: - newly added torrents that haven't been Resume Saved disappear - another process that lead to torrents disappearing - and maybe another too... In answer to your question, I tried this (add, quickly delete, restart, inspect) via the Web Interface, the Qt Gui and via the python-qbittorrent API (qb.shutdown()), and newly added torrents were always missing if I quit straight away after adding a torrent. ----- \* this is interesting: When I say "lost", the 90% downloaded *.!qB files were - are - still in my torrenting 'tmp' directory, the torrent had just disappeared from the displayed list. When I then re-added the *.torrent file again, qBittorrent (the Qt GUI) popped up the dialog "this torrent is already in your download list, merging trackers". So, qBittorrent remains aware of the torrent in one way, perhaps by looking for it via the fingerprint of its hash in my torrenting tmp dir, but does not display it. When I added a different *.torrent file with actually the same hash (you know, sometimes there are multiple differently-named torrents that are actually for the same file(s)/torrent), that differently-named torrent (that is, actually, the same torrent as one already in my torrenting tmp dir) DID get added to qBittorrent's GUI's torrent download list. Unfortunately, this new copy (same hash as 'lost' torrent, different name) hasn't connected with any sources yet, still "Downloading Metatdata', so I can't "Force Recheck" to see if qBittorrent really sees this new copy torrent as the same as the existing "lost" torrent.

deekerman commented

2026-02-21 17:37:52 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Jan 18, 2017):

Possible fix by #6262. Windows users can use my custom binary: https://github.com/qbittorrent/qBittorrent/pull/6262#issuecomment-273590172
Please report there if it was actually fixed.

@sledgehammer999 commented on GitHub (Jan 18, 2017): Possible fix by #6262. Windows users can use my custom binary: https://github.com/qbittorrent/qBittorrent/pull/6262#issuecomment-273590172 Please report there if it was actually fixed.

deekerman commented

2026-02-21 17:37:52 -05:00

Author

Owner

@msagebiel commented on GitHub (Feb 14, 2017):

/ @sledgehammer999 i had similar observations on windows 7, this binary v2 resurfaced torrents after short queue. bt_backup/ all files ok...

@msagebiel commented on GitHub (Feb 14, 2017): / @sledgehammer999 i had similar observations on windows 7, this binary v2 resurfaced torrents after short queue. bt_backup/ all files ok...

deekerman commented

2026-02-21 17:37:52 -05:00

Author

Owner

@WaterSibilantFalling commented on GitHub (Feb 15, 2017):

I built 3.4.0alpha and haven't noticed any lost torrents since. So.. hopefully all is good. I'll comment if 3.4.0alpha looses any torrents.

@WaterSibilantFalling commented on GitHub (Feb 15, 2017): I built 3.4.0alpha and haven't noticed any lost torrents since. So.. hopefully all is good. I'll comment if 3.4.0alpha looses any torrents.

deekerman commented

2026-02-21 17:37:52 -05:00

Author

Owner

@slrslr commented on GitHub (Jul 4, 2018):

I have noticed lost torrents today in my qbt 4.1.1 (Windows 10) after it was terminated by Windows unexpectedly. It is interesting it not worked upon next start, but i had to close it again and start it again, then it started working/showing torrents:

right click qbt icon in the system tray and select to "Exit", and then wait until qbittorrent.exe process disappear in Task/process manager application - can take half hour maybe, if not quit, help it by disconnecting internet maybe.

@slrslr commented on GitHub (Jul 4, 2018): I have noticed lost torrents today in my qbt 4.1.1 (Windows 10) after it was terminated by Windows unexpectedly. It is interesting it not worked upon next start, but i had to close it again and start it again, then **it started working**/showing torrents: right click qbt icon in the system tray and select to "Exit", and then wait until qbittorrent.exe process disappear in Task/process manager application - can take half hour maybe, if not quit, help it by disconnecting internet maybe.

deekerman referenced this issue

2026-02-21 18:38:21 -05:00

FIX Some Dialogs positioned wrong in HiDPI with scaling #6832