Possible to move completed torrents and continue seeding instead of copying?

From reading the wiki I have come to understand that when your torrent client finishes downloading a file Sonarr leaves it in the default download directory so it can continue seeding and copies it to the final destination, ending with 2 copies for a while. Is there a way to just move it instead? After downloads complete I just move them to their final destination and continue seeing from there. I prefer that to copying and having to keep track of the two. I use utorrent btw.

If both directories are on the same drive, try enable the Hardlink option (Settings->Media Management iirc).

It’s not possible to ‘move’ it, it’s too complicated right now to implement that reliably for all supported download clients.

Any plans to add the option or is there already a request? It just seems unnecessarily expensive and inefficient to copy the files if you can move them and the hard links don’t seem to work most of the time for me. I mean, if you consider the fact that a lot of people have a dedicated machine for this and the program is effectively doubling all disk operation by copying everything then that can significantly reduce the life span of drives, especially if it is a solid state drive. Not to mention performance issues if someone has a lot of shows all the extra writing operations can bring your machine to a halt like it did for me yesterday when it copied 10 shows at once. And yeah, I can adjust things to mitigate that, but still. Anyway, just giving you my perspective. I love the program and keep up the good work.

It’s been requested, but it’s not as easy to implement and there are no plans atm to implement it.

A dedicated machine means the file would be moved away from that machine and thus, seeding would be impossible or hard to configure. If the file was kept on the same machine, then the ‘dedicated’ argument is moot.

‘doubling’ is hardly significant when talking about IO itself. A SSD has a significant lifespan in terms of writecycles.
and btw, if you move it across drives, you have the exact same number of writes as a copy.
Most ppl are concerned about disk space, not disk IO.

But as a real answer:

The point is that it’s not easy to implement.

  • It’s hard to reliabily implement ‘moving’ the seeding files for all torrent clients. (read: telling the download client to look at another location for file, esp when the filename changes).
  • Keep track and guard against unintended moves across a network, coz the torrent client wouldn’t be able to seed.
  • Also, we can’t tell the download client to download directly to the series folder, it would be odd, and the naming/numbering would be off, especially hazardous for series with theXem mappings.
  • Upon upgrade, episode files would be replaced, which would mean we have to tell the torrent client to delete or move the file to the recycle bin.

That all makes it a 1% feature that has a myriad of scenarios that end up in disaster that has to be dealt with one way or another.

In that sense it’s similar to the ‘symlink’ request. it’s hard to keep track of everything, especially considering upgrades.

That’s why we have no plans to implement this.

A dedicated machine means the file would be moved away from that machine and thus, seeding would be impossible or hard to configure. If the file was kept on the same machine, then the ‘dedicated’ argument is moot.

I don’t know what you mean by this. All I mean is that many people have a box dedicated to just Sonarr downloading and storing their media. That doesn’t mean files will be moved from it. In fact it means the opposite.

‘doubling’ is hardly significant when talking about IO itself.
Most ppl are concerned about disk space, not disk IO.

I would disagree about doubling being insignificant for IO. I had about 10 episodes download and finish at the same time the other day. Since it copied the files instead of moving them that means I had 10 simulations read operations and 10 simulations write operations on the same disc. I tried to watch something at that time but couldn’t because the disk could not keep up until the files had finished. That may seem like a lot but it’s not terribly uncommon that someone might download a whole season at once or they might have bunch of shows airing at the same time slot on the same night. Yeah, disk space is more of a priority for most people and that’s an even stronger point, taking up twice as much space.

A SSD has a significant lifespan in terms of writecycles.
and btw, if you move it across drives, you have the exact same number of writes as a copy.

SSD does have a significant lifespan but that doesn’t change the fact that writing the same data to it twice cuts that lifespan in half. Not everyone writes across drives.

Not trying to argue or anything, I understand the difficulty in implementing it and I’m sure I can probably find a creative solution. I just feel it’s a little more important than 1% and just giving my point of view.

My point is that the ‘dedicatedness’ of the box is irrelevant.
If you have a seedbox, you would be moving the content from the seedbox to some local system, in which case symlinks are useless.
If that box is local or shared by sonarr, then it doesn’t matter whether it’s dedicated or not.
All that matters is how you organize your physical disks into a filesystem.
Example, my home server has a zfs filesystem with multiple disks, I download and store my media in the same zfs filesystem, how the drives are organized in the zpool is transparent. Hardlinks give me a significant advantage here, coz I can delete stuff from my library and seed dir independently without ever having to worry about breaking symlinks.

Which means that on most filesystems hardlinking would work and you wouldn’t need to copy.

If you’re having problems with hardlinks not working on a single drive/filesystem then that’s something you should look into.

If you have the patients, try this Deluge & Sonarr - No Copies

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.