I was able to systematically reproduce the bug in stretch
(qbittorrent_3.3.7-3+deb9u1 / libtorrent-rasterbar9_1.1.1-1+b1).
I upgraded the latter to 1.1.4-1 (from snapshot.debian.org) and the bug
disappeared.
So likely the bug affected the package libtorrent-rasterbar and it is fixed
now.
Regards
On Tue, Feb 14, 2017 at 09:01:01AM +0500, Khurram Mahmood wrote:
> *HiIn my case I think the force recheck didnt do any good.
(Sorry for the delay.)
A recheck alone will not suffice; qBittorrent is no longer looking in
the right location, so it assumes all files are now missing.
> *Kindly explai
*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 wrote:
> Hi
>
>
> *Thanks for
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 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
> downloa
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 libt
Package: qbittorrent
Version: 3.3.7-2
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
On system rebooting, it has occurred 3rd time, that an already downloaded
torrent restarted from zero per
6 matches
Mail list logo
