The features described here are unfinished and in an alpha or beta stage.
You can provide the
--fast-query option of
rtcontrol to set a level of optimization
to use when querying rTorrent for items. The default for that option is set via the
fast_query config parameter, and is
0 if not changed. That means optimization is normally
off, and can be activated via
-Q1. It is recommended to keep it that way for now, and
-Q1 explicitly in scripts and other background processing to reduce the load they generate.
Only activating it in scripts usually means the filters used don't change that much, i.e. you can be pretty
sure the optimization does what you expect it to do.
Level 1 is less aggressive and safe by definition (i.e. produces correct results in all cases, unless there's a bug),
-Q2 is highly experimental and in some circumstances
likely produces results that are too small or empty.
Optimization works by giving a pre-filter condition to rTorrent, to reduce the overhead involved in
sending items over XMLRPC and processing them, only to be then discarded in the
machinery. That pre-filter evaluation needs features of rTorrent-PS 1.1 or later, and will produce
errors when used with anything else.
This goal of reducing the number of items sent to
rtcontrol is best achieved if you put
a highly selective condition first in a series of conditions combined by
AND. For cron-type jobs,
this can often be achieved by looking at recent items only – older items should already be processed
by previous runs. Even a very lenient window like “last week” drastically reduces items
that need to be processed.
Consider this example:
$ rtcontrol loaded=-6w is_ignored=0 -o- -v -Q0 DEBUG Matcher is: loaded=-6w is_ignored=no DEBUG Got 131 items with 20 attributes … INFO Filtered 13 out of 131 torrents. DEBUG XMLRPC stats: 25 req, out 5.6 KiB [1.4 KiB max], in 104.9 KiB [101.5 KiB max], … INFO Total time: 0.056 seconds. $ rtcontrol loaded=-6w is_ignored=0 -o- -v -Q1 INFO !!! pre-filter: greater=value=$d.custom=tm_loaded,value=1488920876 DEBUG Got 17 items with 20 attributes … INFO Filtered 13 out of 131 torrents. DEBUG XMLRPC stats: 25 req, out 5.7 KiB [1.5 KiB max], in 16.6 KiB [13.2 KiB max], … INFO Total time: 0.028 seconds.
You can see that the 2nd command executes faster (the effect is larger with more overall items),
and only looks at 17 items to select the final 13 ones, while with
-Q0 all 131 items
need to be looked at, and thus transferred via XMLRPC. That means 105 KiB instead of only 16.6 KiB need
to be serialized, read, and parsed again.
Putting the right condition first is quite important, as you can see when the conditions are swapped and the less selective one is used for the pre-filter:
$ rtcontrol is_ignored=0 loaded=-6w -o- -v -Q1 INFO !!! pre-filter: equal=d.ignore_commands=,value=0 DEBUG Got 117 items with 20 attributes …
Be careful when mixing
--fast-query, since most of the post-processing steps also look
at deselected items, and produce unexpected results if they are missing due to pre-filtering. Put another way,
-Q0 when you use
--anneal, to be on the safe side.
Connecting via SSH
Starting with version 0.4.1, you can use URLs of the form
to connect securely to a remote rTorrent instance. For this to work, the following preconditions have to be met:
- the provided account has to have full permissions (
rwx) on the given socket.
- you have to use either public key authentication via
authorized_keys, or a SSH agent that holds your password.
- the remote host needs to have the
socatexecutable available (on Debian/Ubuntu, install the
You also need to extend the
rtorrent.rc of the remote instance with
# COMMAND: Return startup time (can be used to calculate uptime) method.insert = startup_time,value|const,$system.time=
For example, the following queries the remote instance ID using
rtxmlrpc -v -Dscgi_url=scgi+ssh://firstname.lastname@example.org/var/torrent/.scgi_local session.name
This typically takes several seconds due to the necessary authentication.
Using the Monitoring Web Service
TODO – see the old docs for anything not yet moved.
Queue Manager: Planned Features
These aren't implemented yet…
pyrocore.torrent.jobs:ExecCommand runs an external command
in a shell, i.e. it simply runs cron jobs. The reasons for not using
cron instead are these: 1. You can have all your rTorrent-related
background processing at one place, and the commands see the same
pyrotorque offers more flexible
scheduling, including the ability to run jobs at sub-minute intervals.
pyrocore.torrent.watch:RemoteWatch polls a (S)FTP source
.torrent files, creates a local copy, and loads that into
pyrocore.torrent.: maintains an updated copy of all
rTorrent items, as a service for the other jobs.
rtcontrol in form
of a house-keeping job, and using this is way more efficient than an
rtcontrol cron job; due to that, they can be run a lot
pyrocore.torrent.filter:TorrentMirror allows you to
transfer a torrent's data from the local client to other remote clients
using a specified tracker (at the start, a locally running "bttrack").
In a nutshell, it allows you to transfer any filtered item automatically
to a remote location via bittorrent.
pyrocore.torrent.: moves completed data to a target
directory, according to flexible rules.
pyrocore.torrent.: keeps a continuous archive of some
statistical values (like bandwidth) so they can later be rendered into
See RtorrentMonitoring for more details.