Using load.start and load.raw_start will ensure torrents are always started automatically when using rTorrent.
Right now, using load.normal and load.raw could result in torrents not being started. I have experienced this (especially in Radarr) but is hard to reproduce.
load.normal and load.raw are used to set the location and other properties before starting the torrent. If there are torrents in the queue that were not started either the magnets for them didn't resolve or they failed to load in the time Sonarr waits after adding them.
Currently magnets wait up to 5 seconds (500ms delay, 10 times) and torrents up to one second (200ms delay, 5 times), the latter being a recent change.
Radarr uses different parameters unless they pulled our recent change across. I'm not sure that making this change makes sense, as the directory and other settings would still not have been applied an may not work for setting the directory after it starts (I'm not sure how rtorrent behaves with that).
I also have a problem of torrents not starting. I think start torrent should be more important that other parameters which can easily be set in rtorrent.
The technique you mention, polling the client for 5 seconds (magnet) or 1 second (torrents) seems to work for most clients. rTorrent is the trouble here because of its strange behavior. The risk of using this method is that if the torrent does not load in time, you mistakenly abandon that torrent in the client. I currently experience this even before the 5 or 1 second wait time, which makes me believe there is some inconsistency with this approach and rTorrent.
When adding a magnet link in rTorrent a temporary .meta file is added to rTorrent which is then later replaced by the actual torrent when the magnet link is resolved. Replacing means that the properties set on the temporary .meta torrent (such as the label) are deleted. Could this possibly lead to the problem described?
As @ne0ark said, I as well would gladly give up the option to define a label for new torrents for a more consistent and bullet proof approach using the load.start and load.raw_start method.
Since last Tuesday I've been investigating rTorrent after @Vaelek gave me some more information about the scenario in which he experienced issues.
Long story short: There is a timing issue in rtorrent's api that causes problems when a magnet resolves in a very short time (think < 1sec).
I've tweaked the logic to deal with that problem. But reproduction (and thus testing the fix) has been problematic.
I pushed the change to develop.
I also have problem sometimes with regular torrent.
Yes, we bumped the timeout for regular torrents a while back (from 200ms to 1sec), and now I bumped it to 5 sec.
No clue why rtorrent is still adding a torrent in stopped state and torrent name has .meta in it. I think it might have to do with how the torrent is loaded in rtorrent. It seems like you can specify directory in load.start https://github.com/rakshasa/rtorrent/issues/22 .
@ne0ark My initial thought was "that doesn't matter, doing two api calls, one to add, one to change the label doesn't behave differently than doing one api call that does both. It doesn't change what happens after the magnet resolves."
But I've been reading up what rakshasa said on the subject in various comments, and then checked the rtorrent's code, and it looks like the load.* (doesn't matter which) actually does more than just set those properties, it stores them in the meta so it gets automatically reapplied to the torrent after the meta resolves.
This is a big facepalm coz, although I could make the excuse that this behavior wasn't really obvious or documented, it would've saved @larsjohnsen (and me) a lot of headaches if we had noticed the fine print when we first start out.
So:
load.normal=magneturl
d.custom1.set=label
d.open=
d.start=
is different than
load.normal=magneturl,d.custom1.set=label
d.open=
d.start=
The second one preserves the label when the meta becomes a torrent.
Or better yet (here it comes):
load.start=magneturl,d.custom1.set=label
which preserves both the label AND the start condition, meaning the torrent will be started automatically. And we're back to exactly what you said.
Excellent work. Exactly what I was looking for 馃憤
Seem to work nicely thnx.
Most helpful comment
@ne0ark My initial thought was "that doesn't matter, doing two api calls, one to add, one to change the label doesn't behave differently than doing one api call that does both. It doesn't change what happens after the magnet resolves."
But I've been reading up what rakshasa said on the subject in various comments, and then checked the rtorrent's code, and it looks like the load.* (doesn't matter which) actually does more than just set those properties, it stores them in the meta so it gets automatically reapplied to the torrent after the meta resolves.
This is a big facepalm coz, although I could make the excuse that this behavior wasn't really obvious or documented, it would've saved @larsjohnsen (and me) a lot of headaches if we had noticed the fine print when we first start out.
So:
is different than
The second one preserves the label when the meta becomes a torrent.
Or better yet (here it comes):
which preserves both the label AND the start condition, meaning the torrent will be started automatically. And we're back to exactly what you said.