Bittorrent - Find file on disk protocol
Continued from: http://forum.vuze.com/message.jspa?messageID=220511#220511 (not really the same feature request)
Before searching the rest of the internets a client may look for the files on the local file system.
Trying to download something from the other side of the globe while the same file sits in the subfolder next to the download folder is not a very good way of doing things. It is like going to the store to get sugar every time you make a cup of coffee.
Say you have episode 1 to 100 on disk in separate torrents, now you want to download 1 torrent with episode 1 to 110. It is senseless to download 100 episodes you already have.
There are some nice big torrents with lots of huge files in them. Every single one of those is available as a separate torrent. Given the way multifile torrents work it is impossible to structure the pack to prevent duplicates.
Next week a new torrent appears containing episode 1 to 111. *shrug*
I'm currently using utorrent and I would like to load the same torrents into Vuze. Vuze (like any other client) wants everything in 1 folder but disks that size don't exist. I only use 2 folders and I'm already in deep cheese trying to do this.
This tool finds 7000 duplicate files on my 2 bittorrent folders. I have a total of 130 GB of duplicate file names.
I don't have a clue which ones are completed or which one of the 2 is currently being seeded. I suppose I now have to manually delete 7000 files?
But wait....
Simply looking in the designated folders on the file system if a file name already exists and hash checking the file names that are the same doesn't seem very hard to do? Or am I wrong about that? It seems a computer can do this a whole lot better than I could.
It could even find all .torrent files on the disks, add them to the client. If so desired by the user it could only add the .torrents of which the files are available. The torrent with episode 1 to 111 would quickly resolve to 92% complete without bothering the swarm.
The idea is so simple: If a file already exists it already exists, no need to 5 kB/s the GB's from the other side of the globe and fill the disk with duplicate entries. The file system is by far the best protocol to download from. Nothing even gets close.
For a hand full of files this can be done manually but not for thousands. I really don't keep a directory of files in my head that allows me to remember and resolve the file path every time I add a torrent. Why should I? It is like having a kitchen with 10000 cupboards not knowing if there is any sugar. There is an inventory list you know?
At first a good client may just find and copy the duplicate, later it may point more than one torrent to a single location and eventually it may match files in 2 running torrents.
Even if it was only to make migration to Vuze less of a pain it would be worth it. Just hash checking thousands of files is almost enough of an annoyance to make it not worth thinking about.
I did find this Vuze autorelocate plugin which installed nicely but doesn't offer a clue how to use it. The first box says !autorelocate.base! and allows me to browser the file system. Second box says !autorelocate.base.locations! I guess I'm suppose to type out file paths in those boxes separated by "unknown"? I don't have a clue, sorry.
All I know is that it seems to be something a client can do without having the user jump hoops.
What are your thoughts on this?
Discuss: Vuze Forums: find file on disk protocol ...
Before searching the rest of the internets a client may look for the files on the local file system.
Trying to download something from the other side of the globe while the same file sits in the subfolder next to the download folder is not a very good way of doing things. It is like going to the store to get sugar every time you make a cup of coffee.
Say you have episode 1 to 100 on disk in separate torrents, now you want to download 1 torrent with episode 1 to 110. It is senseless to download 100 episodes you already have.
There are some nice big torrents with lots of huge files in them. Every single one of those is available as a separate torrent. Given the way multifile torrents work it is impossible to structure the pack to prevent duplicates.
Next week a new torrent appears containing episode 1 to 111. *shrug*
I'm currently using utorrent and I would like to load the same torrents into Vuze. Vuze (like any other client) wants everything in 1 folder but disks that size don't exist. I only use 2 folders and I'm already in deep cheese trying to do this.
This tool finds 7000 duplicate files on my 2 bittorrent folders. I have a total of 130 GB of duplicate file names.
I don't have a clue which ones are completed or which one of the 2 is currently being seeded. I suppose I now have to manually delete 7000 files?But wait....
Simply looking in the designated folders on the file system if a file name already exists and hash checking the file names that are the same doesn't seem very hard to do? Or am I wrong about that? It seems a computer can do this a whole lot better than I could.
It could even find all .torrent files on the disks, add them to the client. If so desired by the user it could only add the .torrents of which the files are available. The torrent with episode 1 to 111 would quickly resolve to 92% complete without bothering the swarm.
The idea is so simple: If a file already exists it already exists, no need to 5 kB/s the GB's from the other side of the globe and fill the disk with duplicate entries. The file system is by far the best protocol to download from. Nothing even gets close.
For a hand full of files this can be done manually but not for thousands. I really don't keep a directory of files in my head that allows me to remember and resolve the file path every time I add a torrent. Why should I? It is like having a kitchen with 10000 cupboards not knowing if there is any sugar. There is an inventory list you know?
At first a good client may just find and copy the duplicate, later it may point more than one torrent to a single location and eventually it may match files in 2 running torrents.
Even if it was only to make migration to Vuze less of a pain it would be worth it. Just hash checking thousands of files is almost enough of an annoyance to make it not worth thinking about.
I did find this Vuze autorelocate plugin which installed nicely but doesn't offer a clue how to use it. The first box says !autorelocate.base! and allows me to browser the file system. Second box says !autorelocate.base.locations! I guess I'm suppose to type out file paths in those boxes separated by "unknown"? I don't have a clue, sorry.
All I know is that it seems to be something a client can do without having the user jump hoops.
What are your thoughts on this?
Discuss: Vuze Forums: find file on disk protocol ...