Open JDRIVO opened 5 years ago
A much more robust solution to prevent running out of disk space is only starting things you have room for, combined with close_low_diskspace as a backup mechanism
By robust do you mean better? The only task that script does which mine doesn't is the automatic resumption of torrents. My script does more than just stop torrents. In addition:
That script won't be useful to those who don't have pyrocore. That script won't be helpful to those who use autodl-irssi and need space cleared immediately. My script doesn't depend on the unreliable close_low_diskspace as a backup mechanism.
However, I can see the value in that script being a beneficial supplement to ratio groups. My script also functions as an alternative to ratio groups.
By robust do you mean better? The only task that script does which mine doesn't is the automatic resumption of torrents. My script does more than just stop torrents.
Yep, I meant better. It automatically discovers the scgi connection (and supports unix socket files), doesn't depend on new torrents being added constantly to function correctly, doesn't add execute
hooks that run in the foreground (which block rtorrent for the duration of the run), and is better documented. When it comes to actually preventing low disk space crashes, it doesn't assume that /
is the only partition that holds torrents, fails safely (e.g. if pyrotorque breaks for some reason, no new torrents are started) and doesn't wait for files to possibly pre-allocate space before stopping them.
That script won't be useful to those who don't have pyrocore.
pip install pyrocore; pyroadmin --create-config
, as opposed to a bash script that tries to kill rtorrent without any warning (in order to add events that you could insert on the fly, I might add) and assumes screen is the way it needs to be started back up.
That script won't be helpful to those who use autodl-irssi and need space cleared immediately.
Correct, that's a different use case than preventing crashes from full disks.
My script doesn't depend on the unreliable close_low_diskspace as a backup mechanism.
I wasn't recommending depending on close_low_diskspace at all, it's just a backup in case something goes horribly wrong (e.g. something other than rtorrent fills up the disk, which neither pyrotorque nor your script could prevent). I usually keep it in the .rtorrent.rc with a very low value. All of that is mentioned in the link I posted earlier.
It automatically discovers the scgi connection (and supports unix socket files),
Not a big deal.
doesn't depend on new torrents being added constantly to function correctly
My box is only used for torrenting so disk space is only consumed by the addition of a torrent. But fair enough, there are those who download via other means.
doesn't add
execute
hooks that run in the foreground (which block rtorrent for the duration of the run).
During/after this freeze period does it cause connection loss to peers or any other negative effects? I'm aware of this but it didn't bother me as the scripts execution time is very fast.
When it comes to actually preventing low disk space crashes, it doesn't assume that
/
is the only partition that holds torrents
Nice flaw detection. I'll investigate a solution.
doesn't wait for files to possibly pre-allocate space before stopping them.
Very nice.
pip install pyrocore; pyroadmin --create-config
So tough titties if you're with a seedbox provider that won't allow the installation of Python libraries.
kill rtorrent without any warning (in order to add events that you could insert on the fly, I might add)
The same can be said about 99% of the commands in that setup script lol. But thanks for the feedback, I'll add a warning.
Correct, that's a different use case than preventing crashes from full disks.
Not really. My script sets out to solve the problem of the cause of rtorrent crashes by clearing room for uninterrupted torrent downloading.
Think of these scripts as anal beads and strap ons. Both have their uses for pleasure but do so differently.
It automatically discovers the scgi connection (and supports unix socket files),
Not a big deal.
I have to disagree here, the auto-discovery is merely pretty nice, but supporting unix socket files is very important.
doesn't add
execute
hooks that run in the foreground (which block rtorrent for the duration of the run).During/after this freeze period does it cause connection loss to peers or any other negative effects? I'm aware of this but it didn't bother me as the scripts execution time is very fast.
If everything works fine you'll just get small blips and imperfect performance. However if, for instance, iMDB became unreachable and connections to it had to time out, it's a big problem.
pip install pyrocore; pyroadmin --create-config
So tough titties if you're with a seedbox provider that won't allow the installation of Python libraries.
There's a more involved method that uses a virtualenv to install everything if even pip isn't available, my main point is that it's pretty easy to install. (As an aside, I'd recommend replacing PTN with guessit, and adding whichever you go with to the documentation/install script)
Correct, that's a different use case than preventing crashes from full disks.
Not really. My script sets out to solve the problem of the cause of rtorrent crashes by clearing room for uninterrupted torrent downloading.
Think of these scripts as anal beads and strap ons. Both have their uses for pleasure but do so differently.
Let me be clear here, I'm not trying to be critical just to be a jerk about it. If it works for you, great! I always approve of scripting things to meet your own needs. If it's being presented as a potential solution to full-disk crashes for \
All good. I'm new to programming, this is my first project and I only bothered to learn how to do so due to being fed up with rtorrent crashing when my disk would become full. I'm not looking to steal your crown and I appreciate your constructive criticism.
In regards to scripts being run in the background. If for instance, two torrents are sent to rtorrent at the same time does rtorrent process each one by one or simultaneously? IE will two bg execute hooks be executed at the same time (one for each torrent) or will rtorrent trigger them one by one
And a 3rd solution, using pyrocore utils a bit, in a specific setup.
Nice. The more options, the better.
Is there a way to instruct rtorrent to not download torrents when they are added (force them into a stopped state)... through rtorrent.rc? Or do I need to hook into rtorrent somehow?
You can do this easily by specifying a different watch directory for these torrents and use load.normal
with them instead of load.start
, e.g. as here. (But probably it can be done via events as well.)
Cheers Chros. I'm aware of that solution for watch directories. Was hoping for a solution for torrents added remotely. I'll see if there's anything that can help in that link. Cheeers.
My current issue is if I use a background execute command which points to a script that will stop the torrent, the torrents files will be added to the download directory. This doesn't occur when I use a foreground execute command.
method.set_key = event.download.inserted_new,insert_stopped,"d.stop=,$d.hash="
seems to do the trick. Too easy.
Kannibalox can you critique my solution to partition support? Thanks.
supporting unix socket files is very important.
Can you explain why please ?
supporting unix socket files is very important.
Can you explain why please ?
Socket files are inherently more secure than exposing a network port, given that you can use basic files permission to limit access, unlike ports.
https://github.com/JDRIVO/rTorrent-Disk-Checker