Deluge
I use several trackers, and I have to go through a bit of a pain to download a torrent from one, and then join another tracker to seed it on both of them. I have an idea to automate this.
This feature would first scan all the files in a folder or drive and keep a db of all the files-hashes (same hash algo as it stores in .torrent files). Then when ever a new .torrent file is added, the hashes in the .torrent file are checked against the db, and if found, it would simply start seeding the file from there (instead of downloading it from the network).
This would come in handy if someone already has a bunch of music/movies that they downloaded earlier, and joined a new tracker.. they would simply need to download the .torrent file and deluge would automatically start seeding the files, or if missing, will start downloading them.
Feature Request: Find already downloaded files using Hashes?
Re: Feature Request: Find already downloaded files using Hashes?
If you set the same download location for all of them then I belive this would already happen (it's what it's doing when the torrents status is "Checking", to see how much it needs to download).
Re: Feature Request: Find already downloaded files using Hashes?
That is only if the file name is exactly the same. Not if the file name is modified by the uploader or tracker upon serving. I like this idea, but I'm not sure if it is practical to include this check, I would think after the db storing these hashes collects after time, the delay in starting the torrents would be noticeable. No?damoxc wrote:If you set the same download location for all of them then I belive this would already happen (it's what it's doing when the torrents status is "Checking", to see how much it needs to download).
-
seth
Re: Feature Request: Find already downloaded files using Has
A use case for this would be if you want to organize your files after they're done downloading. There are auto renaming tools for deluge but they can't be as nice as using your file manager and/or bulk renaming tools that know nothing about deluge.
The cost of this would be that you'd need to hash the files after they're moved.
Implementation ideas:
1. The read-only (from the perspective of deluge) directories would need to be scanned and files hashed before deluge decided to download a file.
2. Deluge would have to mark a file as done downloading so that it wouldn't start re-downloading the file after you moved it.
3. On program start deluge would consult a map of (file_name) -> (file_size, file_modification_time). If the file_size or file_modification_time changed the file would get rehashed.
3. There'd probably also need to be a way to trigger rehash if the content of the file changed without it's size or modification time changing. Perhaps this could be lazily triggered when someone requests a block from us and it doesn't hash correctly.
If this was implemented I could imagine stuff like this.
1. Download for a TV show completes.
2. I use my bulk-renamer and put the TV show in a read-only directory the scanner looks at.
3. Requests for the files would result in an error. This would cause our client to temporarily leave the swarm for the tv show.
4. The read-only directory scanner would get triggered. It'd notice files which aren't in it's map and hash them.
5. The directory scanner would finish hashing one of the TV show episodes and ask deluge, "hey, do you need a file with hash 0xdeadbeef?". Deluge would then "relink" the file in the read-only directory to the torrent.
While the completed torrent had its files missing deluge would need to display an error for that torrent. There could be an option to trigger a re-download. Like if I accidently deleted the file from my read-only directory and needed to re-download it.
The cost of this would be that you'd need to hash the files after they're moved.
Implementation ideas:
1. The read-only (from the perspective of deluge) directories would need to be scanned and files hashed before deluge decided to download a file.
2. Deluge would have to mark a file as done downloading so that it wouldn't start re-downloading the file after you moved it.
3. On program start deluge would consult a map of (file_name) -> (file_size, file_modification_time). If the file_size or file_modification_time changed the file would get rehashed.
3. There'd probably also need to be a way to trigger rehash if the content of the file changed without it's size or modification time changing. Perhaps this could be lazily triggered when someone requests a block from us and it doesn't hash correctly.
If this was implemented I could imagine stuff like this.
1. Download for a TV show completes.
2. I use my bulk-renamer and put the TV show in a read-only directory the scanner looks at.
3. Requests for the files would result in an error. This would cause our client to temporarily leave the swarm for the tv show.
4. The read-only directory scanner would get triggered. It'd notice files which aren't in it's map and hash them.
5. The directory scanner would finish hashing one of the TV show episodes and ask deluge, "hey, do you need a file with hash 0xdeadbeef?". Deluge would then "relink" the file in the read-only directory to the torrent.
While the completed torrent had its files missing deluge would need to display an error for that torrent. There could be an option to trigger a re-download. Like if I accidently deleted the file from my read-only directory and needed to re-download it.