I'm still getting the "Stuck checking" problem and I'm running the 1.2.0-rc5 version. I installed libTorrent via their SVN-trunk but I'm quite new to Ubuntu so I may have screwed something up. But isn't it supposed to be fixed in the version of Deluge I'm already running?
I fixed problem in 1.20-rc5 (on gentoo) by installing libtorrent (net-libs/libtorrent-0.12.6) and then rebuilding deluge. The "pause, unmanage, resume" trick then worked on 50 torrents stuck as mentioned above.
Hope that helps.
Looks like more than a few binary packages are compiled "solo" without the libtorrent being required as part of the system. That's fine I'm sure, but the re-install with libtorrent installed first worked like a charm.
I fixed problem in 1.20-rc5 (on gentoo) by installing libtorrent (net-libs/libtorrent-0.12.6) and then rebuilding deluge. The "pause, unmanage, resume" trick then worked on 50 torrents stuck as mentioned above.
Hope that helps.
Looks like more than a few binary packages are compiled "solo" without the libtorrent being required as part of the system. That's fine I'm sure, but the re-install with libtorrent installed first worked like a charm.
cheers,
andy
Deluge doesn't use that libtorrent, so I don't understand why this would change anything.
The checking bug should be fixed in libtorrent 0.14.8, which is what I suggest using with deluge 1.2.0.
Are you forced to compile deluge from the source code as well when you want to install another version of libtorrent? I installed deluge through apt-get, maybe that's why libtorrent didn't make any change to the problem before? Or am I wrong?
Zinom wrote:Are you forced to compile deluge from the source code as well when you want to install another version of libtorrent? I installed deluge through apt-get, maybe that's why libtorrent didn't make any change to the problem before? Or am I wrong?
You are not forced to compile libtorrent if your OS has a libtorrent package available.
I am using Deluge on an old PIII 700 using Ubuntu 9.10. This morning Ubuntu required an update. At the completion of the update the computer rebooted. Afterwards the 13 torrents which had been actively uploading prior to the update were shown as “Checking” and at 0%. They wouldn’t move off the 0%. The remaining torrents (21) were shown as “seeding”.
My downloads go to a directory on the pc and when completed the file is transferred to an attach 1TB external Hard Drive via a USB socket.
I tried removing the torrent file from within Deluge (but not the data file) and downloaded another copy of the original torrent file. All this did was restart the download from zero rather than recheck the existing data. Eventually I worked out how to fix the problem. This is how I did it.
STEP 1. Make a note of the names of all the affect torrent files STEP 2. Delete each of the torrent files by right clicking on them and selecting “Remove Torrent”. DO NOT delete the data file. Make sure you delete all of the ‘stuck’ torrent files before proceeding to the next step. STEP 3. Go to the external hard drive and copy the original downloaded files back into the directory on the pc where they were initially downloaded. Now do Steps 4-6 below individually for each torrent. STEP 4. Download the torrent file again. STEP 5. When Deluge opens the window ‘Add Torrents’ ensure the correct file to be downloaded is displayed. The click on the “Add” button. STEP 6. Deluge should now display the file being checked through to 100% before showing it as “seeding”. Note: Step 3 may not be required if you keep your downloaded files in the original directory.
upgraded to 1.2 from the PPA earlier this morning and ran into this problem...
i have Karmic launch the daemon on startup, but i realised today after doing a reboot that it's launching before the system mounts the drive that i keep my torrents on (an external firewire disk). so deluge checks for the torrents, finds nothing at the mountpoint and returns an error for each torrent.
when i select all the torrents and force a recheck, they all sit there at "Checking 0%", nothing happening. if i halt the daemon and fire it up again, they start up again just fine.
andar wrote:The checking bug should be fixed in libtorrent 0.14.8, which is what I suggest using with deluge 1.2.0.
You mean the 0.14.8 of libtorrent-rasterbar (currently installed) or libtorrent (not installed)?
Like others, I have upgraded to 1.2 from the PPA on a Ubuntu 9.10 machine, and I'm hit with this "checking" problem, which make using Deluge a real pain at the moment.
I currently have 0.14.6-1 of libtorrent-rasterbar5 installed, and have the karmic-backports repository registered with "main restricted universe multiverse" components, but 0.14.8 of libtorrent-rasterbar is not available as an update.
I am curious. How is this a libtorrent issue? In my case, I can keep the "Checking" going by never having more than 2 torrents being checked at a time.
Background: I tried out qtorrent because recently I have found that I am not getting many connections to peers. For example, I am looking at a torrent right now which shows 672 available seeds and 1729 available peers. Yet I am connected to a grand total of 2. I don't know if that has to do with the rumoured "ban" some trackers have for Deluge clients because of the libtorrent 15% over-reporting of download volume issue, or because I can't seem to get blocklists to load and thus other peers are banning my connections, or what. What I DO know is that about a month and a half ago I was able to connect to hundreds of peers and seeders at a time and regulary sustain download volumes between 100kB/s and 500kB/s. Now I'm lucky to get 50kB/s.
In any event, qtorrent was little better, so I moved back to Deluge again. As a result, I had over 200 torrents which had to be "checked" before being rolled back into the queue.
I have paused ALL my unchecked torrents so that they have status "paused". If I "resume" more than two torrents at a time, they will all go to the "Checking" group, and the first two will check just fine. However, all the remaining torrents get stuck at "0.00%", just like everyone here mentions.
I have found that this behaviour is not consistent. Rarely, I can put 4 or 5 torrents into "Checking" mode, and all of them will check just fine. But that is rare.
I presume (perhaps incorrectly) that the functions within libtorrent are being called in threads that are individual to each torrent depending on the torrents' status. That implies that the problem is more likely in the torrent management code, not the checking funtion itself.
Can a developer please weigh in and describe the issue in a little more detail for those of us who want to understand what's going on here?
Deluge
