Bug 619125 - qBittorrent watch directory is often ignored
Summary: qBittorrent watch directory is often ignored
Alias: None
Product: Fedora
Classification: Fedora
Component: qbittorrent   
(Show other bugs)
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: leigh scott
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-28 15:55 UTC by Patrick O'Callaghan
Modified: 2010-12-04 09:15 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-12-04 09:15:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Patrick O'Callaghan 2010-07-28 15:55:58 UTC
Description of problem:
QBT doesn't reliably pick up torrent files from a watch directory

Version-Release number of selected component (if applicable):
Every version from 2.2.5 to 2.2.9, plus 2.30 (from Koji).

How reproducible:
Apparently random

Steps to Reproduce:
1.Place a torrent file in a QBT watch directory
2.QBT starts a torrent download, or maybe it doesn't ...
Actual results:
QBT doesn't notice the new file.

Expected results:
QBT should start to download the new torrent.

Additional info:

I reported this to the qBittorrent bug site some time ago (see https://bugs.launchpad.net/qbittorrent/+bug/435908 for a full description) and it appeared to be fixed for a while when the existing polling mechanism was replaced by inotify, then it broke again. Since I haven't had a response to my updated report I decided to report it here in case it's something specific to Fedora.

Comment 1 Patrick O'Callaghan 2010-07-28 22:06:32 UTC
I need to clear up a possible confusion. In the original bug report (to the Launchpad site) I said that QBT would remove the torrent file from the watch directory without starting the download process. That was true originally, but since the introduction of the inotify call it no longer happens, i.e. QBT now appears to completely ignore the watch directory on some occasions, while on others it proceeds to download the torrent. There is no evident pattern to this.

Furthermore, I checked that inotify is working correctly on my system by running a test example from the inotifywait(1) man page, using the same watch directory as I configured for QBT.

Comment 2 Patrick O'Callaghan 2010-07-29 02:46:06 UTC
I figured it out, and it has nothing to do with inotify. I had set the option to display a dialogue when adding a torrent. Doing this effectively prevents automatic downloading from working since with an unattended session the dialogue will not be answered (in fact it seems to time out though I'd need to confirm this), and the torrent file just stays in the watch directory.

I'll report this upstream because I think this design "feature" needs a rethink.

Comment 3 Patrick O'Callaghan 2010-08-09 13:54:26 UTC
Well, I'm sorry to say I was mistaken. 10 days after I turned off the dialogue options there's definitely something wrong. Whether an automatic download starts or not still appears to be essentially random. I haven't been able to correlate it with anything obvious.

So there's still a problem.

Currently using 2.3.0-1.fc13 from Koji. I've reported this upstream.

Comment 4 leigh scott 2010-12-03 18:20:49 UTC
Has this issue been resolved in future versions?

Comment 5 Patrick O'Callaghan 2010-12-03 18:35:48 UTC
(In reply to comment #4)
> Has this issue been resolved in future versions?

The maintainer says it's resolved as of version 2.4.10 (see the Launchpad URL given above) and I haven't had problems with this version so far.

Comment 6 leigh scott 2010-12-04 09:15:14 UTC
(In reply to comment #5)
> The maintainer says it's resolved as of version 2.4.10 (see the Launchpad URL
> given above) and I haven't had problems with this version so far.

Thanks, I will close this report.

Note You need to log in before you can comment on or make changes to this bug.