Create global start torrent/stop torrent key

[anonymous]

In some cases you want to halt all downloads and uploads for a period of time, say when you want to play Quake 3 online and need all your bandwith to get you a lower ping time. In these cases it would come in handy to be able to stop (or actually pause in this case) all the torrents in order to get all your bandwidth.

[rakshasa]

I'll propably add something like this when the download scheduler gets implemented.

[R3Ce]

It would be also useful an option to stop all downloads exept a selected one.

[Bruno]

Unrelated, but as a note to op: Q3 has rather moderate bandwidth requirements. Don't recall the exact figures (measured them once with iptraf), but 40kbit in either direction, up and down, should be ample enough. With regard to ping times, only upstream really matters, since modems generally buffer when the the line is saturated, which is deadly for ping times. So upstream throttling in rtorrent should already suffice to get reasonable gameplay.

If that's not good enough, maybe traffic shaping helps. I'm doing that, and although it affects the overall ping a little (about +5ms), it gives me reasonable gameplay even with rtorrent running at full throttle. All this of course only as long as the ISP download buffers don't kick in, what they generally do if download rates get huge. Depends on the ISP of course.

Finally, just turning off rtorrent during gameplay is of course an option either :)

[a.harrison503@ntlworld.com]

Replying to anonymous:

In some cases you want to halt all downloads and uploads for a period of time, say when you want to play Quake 3 online and need all your bandwith to get you a lower ping time. In these cases it would come in handy to be able to stop (or actually pause in this case) all the torrents in order to get all your bandwidth.

[a.harrison503@ntlworld.com]

Replying to Bruno:

Unrelated, but as a note to op: Q3 has rather moderate bandwidth requirements. Don't recall the exact figures (measured them once with iptraf), but 40kbit in either direction, up and down, should be ample enough. With regard to ping times, only upstream really matters, since modems generally buffer when the the line is saturated, which is deadly for ping times. So upstream throttling in rtorrent should already suffice to get reasonable gameplay.

If that's not good enough, maybe traffic shaping helps. I'm doing that, and although it affects the overall ping a little (about +5ms), it gives me reasonable gameplay even with rtorrent running at full throttle. All this of course only as long as the ISP download buffers don't kick in, what they generally do if download rates get huge. Depends on the ISP of course.

Finally, just turning off rtorrent during gameplay is of course an option either :)

[hangfire@obviouslies.net]

<bump>

I'd love a start/stop all key

[sj26@sj26.com]

Is there even a command that does this? I would like to schedule all torrents to start/stop daily at certain times...

[anonymous]

Please!

Even a Ctrl-X command would be enough. Stop_all_torrents, start_all_torrents, stop_all_but_current if one is selected... something.

Scenario: Site has new release, one may want to have all bandwidth on the new torrent to share, stopping all the others until a later time when they can be restarted. (Perhaps even labled ones, if running multiple private sites on one instance) A way to automate with new torrents from RSS feed would be interesting. Perhaps scheduling incomplete torrents from RSS feed to be only active torrents until specified time or ratio to resume other torrents. Complete with move to specified directory as well.

Might be hard to setup, but would be a pretty nice setup. I'd be pretty happy for a stop_all/start_all command (with or without keybinding) of some kind and just do the rest by hand.

[anonymous]

stop all started downloads:

^X d.multicall=started,d.stop=

start all stopped downloads:

^X d.multicall=stopped,d.start=

limit it to downloads whose custom3 string is not empty:

^X d.multicall=started,"branch=d.get_custom3=,d.stop="

etc. etc.

[nzjamo@gmail.com]

Im not sure what is meant by the above commands - I cant seem to get them to work.

I would _very_ much like a start_all / stop_all downloads command - for people who have an internet plan with an "offpeak" that starts at inconvenient times, it becomes impractical to use anything that doesn't have this feature. As far as I can see theres no CLI torrent downloader that has this support which is a bit frustrating.

[rakshasa]

They work for me.

[anonymous]

You simply press Ctrl-X and then enter the command. Or you could put them in a schedule to automatically execute them at a given time.

[shtirlic@shtirlic.com]

Nice tip about "d.multicall" and so on. Exactly what I need, thanks! I guess it should be described in manpages.

[anonymous]

The commands only seem to get a bunch of them at a time. I have ~785 torrents loaded up with 3 separate watch directories, and I have to issue the d.multicall stop 5-6 times to get all the torrents to stop. Still faster than each one by hand...

libtorrent-devel-0.12.0 BitTorrent Library written in C++ (development version) rtorrent-devel-0.8.0 BitTorrent Client written in C++ (development version)

[mo]

Same as anonymus on debian, v0.8.4/0.12.5

[Alex]

Problem with the commands given in the example above is that they would interfere with the current status of ones torrents. If you have 5 stopped and 4 running torrents, you'd like to have the same 5 stopped and the same 4 running after having performed a global stop/start sequence.

Thus, there should be a "global override" start/stop value that when set to "stop" will stop all torrents, even those that are running, but once set back to "start", the running torrents will still be running, and the ones not running won't be started.

[pyroscope <pyroscope.project@gmail.com>]

What is the problem with simply setting the global throttle to whichever reduced bandwidth that is desired?

Similarly, you can put certain download items into a "choked" throttle group (set to 1 K/s) and back, which also solves the "don't mess with the basic start/stopped state" requirement.

Also, if you REALLY need full start/stop:
rtcontrol --from-view started --to-view hibernated --tee-view --stop -qo- \*
# some time later
rtcontrol --from-view hibernated --start -qo- \*

The above (using a custom view to save the original state) can be done with native rTorrent commands too, and defined as two methods, if someone cares to write up the syntax.

BTW, support's usually in the mailing list, not in Trac.