Splitting multi-file .torrent to one .torrent for each file

[byu43]

Hello everyone,

There are frequent requests on this forum to add functionality to uTorrent to automatically have a torrent with many files in it be downloaded one, or a few, files at a time. Such functionality can already be had by manipulating the priorities of the files by hand, but even so, the uTorrent writers are unwilling to add functionality to automate this.

I'm wondering if a possible workaround would be to write a small app that takes a single .torrent file and splits it into one .torrent file for each file in the original torrent. That way, individual files could be automatically queued by the torrent queuing system that is already present in uTorrent.

I have briefly looked at the .torrent file format and found that it is block based instead of file based, so I realize that there would be some overhead in downloading the split up torrents since blocks from the other files would have to be downloaded to complete the file in question.

Any input on this idea would be much appreciated.

Thanks.

[jewelisheaven]

Yeah bittorrent is block-based or for a better term "item" based. You get whatever item is described in the INFO dictionary, hence INFOHASH. it may be one file, or thousands of files --of which the former could be http://slackware.com/torrents/slackware-12.2-install-dvd.torrent (3.3 GiB, 1 file) and the latter could be http://media.xiph.org/ED/ED-360-png.torrent (3.3 GiB, ~15K files) What is irrelevant is how many files are present in the item downloaded, what is relevant is size/name/hash

That uTorrent downloads/manipulates .TORRENT files only you likely won't see anything which would be files-based.

Edit: Clarified Files- and Block- based

[byu43]

Thank you for your reply.

If I understand you correctly, each of the generated .torrent files would have to have the same infohash as the original file. Would this cause a problem for the client?

Would the parts of the block that contains data for other files have to be assigned "junk" filenames, or could that data be silently ignored?

[jewelisheaven]

It is HIGHLY unlikely an individual file as a subset of a larger filebase would have an identical INFOHASH as the data is hashed, not only the filename, but the hashes of the individual blocks which make up the files as well. Therefore, if the block data matches the files match, not if the filenames match. This is the reason the ability to change specific filenames to suit your on-disk filenames was added, to eliminate the tedium of having to rename your files to match what's in the INFO dictionary.

As far as identical infohashes' handling in uT, well if you've ever seen "This torrent appears to be loaded, would you like to add the trackers from this torrent?" dialog you'd know ... it wouldn't cause a problem except in the exceptionally rare case I described above where two disparate blocks of data with the same INFOHASH existed.

[byu43]

The client uses the infohash for finding the matching torrents on the network, right? So if a correct infohash was generated for the new .torrent files, I'm guessing that the client would just conclude that there were no other torrents with that file.

So I guess that it means that the idea of splitting .torrent files up won't work. The infohash can't be changed, and when it's not changed, the client will not handle the torrents as separate torrents...