v2.9.8 torrents aren't removed in Debian

Bug #1034504 reported by sledgehammer999
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

I am using Debian sid/unstable 64bit. The most recent available qbt is 2.9.8 from Debian testing. The most recent libtorrent is 0.15.10 (from testing also). And I think they use boost 1.49.0

Removing a torrent from the list isn't removed correctly. The torrent entry reappears when qbt is restarted. If you select to delete the files on harddisk they aren't deleted too. Since I am making the Windows build and have the sources around I tried to compile 3.0.0rc5 with libtorrent 0.16svn and boost 1.50(system). The resulting binary had the same problem.

After reading the qbt source a little I didn't find something obviously wrong. You seem to create the backup torrents in BT_backup using the torrent hash as a unique name for the torrent and the fastresume file. And then use the same hash to locate the files and remove them. This is where the problem lies. For some reason, the hash used for the name of the .torrent file is different than the actual hash. The .fastresume files use the correct hash, that's why it gets deleted when I remove the torrent from the list. I have no idea why you get a different hash for the torrent file. As far as I could tell your code doesn't do something strange(didn't read it very carefully though).

Possibly a libtorrent bug for linux? A debian specific bug?(but it appears in my build of libtorrent too). Can you test it under linux(preferably 64bit)?

Since I wasn't sure that this is a libtorrent bug I didn't report to them. You know your code a lot better than and maybe something slipped me when I was reading the code and following it's logic.

Revision history for this message
sledgehammer999 (sledgehammer-999) wrote :

I found a solution and I suspect where the problem lies.

In qbtsession.cpp change line 1167


const QString newFile = torrentBackup.absoluteFilePath(hash + ".torrent");


const QString newFile = torrentBackup.absoluteFilePath(h.hash() + ".torrent");

Now the torrent is correctly removed from the session and the files get deleted to if I check the checkbox. I suspect that when you do "const QString hash = misc::toQString(t->info_hash());" in 1032 the value is actually uninitialized.

But now there is another problem too. If I pause a torrent and restart qbt the torrent is active instead of paused. Where should I look in the source? How do you save/load the state of the torrent?

Revision history for this message
sledgehammer999 (sledgehammer-999) wrote :

Edit: The idea for using h.hash() I got it from the way you save the fast resume data...

Revision history for this message
sledgehammer999 (sledgehammer-999) wrote :

Also please refactor how you use the "const QString hash" in the QBtSession::addTorrent() method. Since it has wrong data it makes other functions fail, eg qbt fails to load correctly the fastresume data.

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

Could you check with v3.0.0? I remember I fixed a bug that may be related late in v2.9.x series.

Revision history for this message
sledgehammer999 (sledgehammer-999) wrote :

Actually all the above I did them on the 3.0.0 source. libtorrent 0.16svn and boos1.50(from debian)

I had a look in the torrent_info class and what the constructor you use does. It should fill the info_hash correctly. Actually it calls torrent_info::parse_torrent_file() which in turn calls torrent_info::parse_info_section() and in there the m_info_hash is populated. I have no experience in libtorrent code but could it be a bug for linux?

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

Well, I'm running qBittorrent v3.0.0 on latest Ubuntu 64bit and no problem.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.