*HiIn my case I think the force recheck didnt do any good. *Kindly explain: "manually rename the directory to whatever libtorrent is expecting".
*I changed the location via set location, but to no avail.* *Thankyou* On 14 February 2017 at 08:25, Khurram Mahmood <makh...@gmail.com> wrote: > Hi > > > *Thanks for your response.* > > *Let me try it. I hope if this is the fix.* > > > *Kind Regards,* > > KM > > On 14 February 2017 at 05:28, Frédéric Brière <fbri...@fbriere.net> wrote: > >> On Tue, Feb 14, 2017 at 01:57:20AM +0500, Khurram Mahmood wrote: >> > On system rebooting, it has occurred 3rd time, that an already >> downloaded torrent restarted from zero percent. >> >> Yes, I've had a similar experience in the past with 3.3.6-1. From what >> I understand, this is due to a bug[1] in libtorrent-rasterbar 1.1.x, >> which typically manifests itself in two situations: >> >> - The directory of a torrent is renamed by adding a suffix; or >> - the directory name of a torrent acts as a prefix to the directory >> name of another torrent (see [2] for an example). >> >> Note that in either case, the downloaded files are still there; >> libtorrent is simply not looking at the right location. >> >> If I'm not mistaken, this has been fixed in the RC_1_1 branch, and >> should therefore be part of 1.1.2 when it comes out. >> >> In the meantime, a crude but simple fix is to manually rename the >> directory to whatever libtorrent is expecting. (You can pinpoint this >> by starting the download a little bit.) After a forced recheck, if all >> goes well, the torrent should be back to 100%. >> >> >> [1] https://github.com/arvidn/libtorrent/issues/1242 >> [2] https://github.com/qbittorrent/qBittorrent/issues/5820 >> >> >
