Hi, quick question. Is bittorrent sync compatibility considered in NzbDrone post-processing? SickRage pauses post-processing for folders containing !sync files (and also files syncing by lftp), because otherwise the first synced episode in a season gets detected and processed and the parent folder is ‘tidied’ (deleted) and BTSync detects the folder deletion and deletes it on the server.
This is mostly just relevant for seedbox setups with torrent/file blackhole roundtrips, that’s why I thought it may not have been raised.
I’m still reading up on NzbDrone post-processing logic, and I’m sure there are already some file-statuses that will pause post-processing, so maybe BTSync could be incorporated somehow?
Cheers,
Belriose
PS: Anyway, below is the latest (probably completely irrelevant) commit where lftp sync pausing was merged with the extant BTSync pausing. It’s in python for a completely different system, but it seemed possible in their case. (I broke the link because new users can’t post multiple links) https://github.com /echel0n/SickRage/commit/9cffbfe6ee488103618246922a4b7ff650818a22
I’ve moved the topic since this is something we will not support on the short term.
We’ve added Blackhole support merely as final-resort measure. But it’s limiting in so many ways.
CDH connects to the download client to determine if something is ready for import.
We developed CDH to move away from directory scanning, so I’m a bit reluctant to support those other scenarios. For one, why use BTSync, why not mount the remote storage and have drone copy it.
We can look at advanced use cases, but atm we’re looking at the basic use cases first.
Alternatively have a pp-script in the download client that triggers the btsync and not return until it’s finished. That’s likely more reliable than checking for ‘!sync’ files.
Thanks for replying Taloth. That’s a really helpful response.
I have tentatively set-up your suggested mount-system with Transmission. I was sticking to a directory scanning workflow because rtorrent isn’t supported yet (and BTN as well), and I could use my existing system as a stopgap.
There are advantages to BTSync over drive-mounting (speed, compatibility, ease-of-setup, and built-in error detection), but I understand that it’s not a priority.
Once more clients/sites are supported for CDH, then maybe I won’t even miss BTSync.
(Checking for !sync files does seem to work pretty well though)