Merge two torrent files

[OJNSim]

Hi,

I am trying to download two files, with differnt names, which supposed to be same.

Appeantly they are rare so they are being downloaded very slow and actually most of the time nothing is being downloaded.

I thought about somehow "merge" them to one that hopefully will have more leechers-seeders.

After reading about that it looks it is impossible - but I am didn't realize why now.

What makes these files different for uTorrent? Is it the hash code? Is it something else?

tx

OJ

[ciaobaby]

What makes these files different for uTorrent? Is it the hash code? Is it something else?

The binary data that the piece hashsums are created from.

[OJNSim]

Tx

Sorry mate, but I am not sure I got it.

Can you please elaborate a bit more? What does it mean, or can you please refer me to some explanations online?

Also, maybe the following example will help me understand.

Assuming a scenario in which two different seeds upload the exact same file, meaning the the exact same bytes sequence, only each file have a different name. My assumption is that this is the case here.

How the bitTorrent network will handle these files?

[ciaobaby]

https://wiki.theory.org/BitTorrentSpecification

http://lifehacker.com/285489/a-beginners-guide-to-bittorrent

http://en.wikipedia.org/wiki/Torrent_file

http://en.wikipedia.org/wiki/BitTorrent

http://en.wikipedia.org/wiki/Glossary_of_BitTorrent_terms

Assuming a scenario in which two different seeds upload the exact same file, meaning the the exact same bytes

If they have different names they CANNOT and will not have the same byte sequence.

If they have been altered in ANY WAY, tagged/retagged, different last modified date, created date, they are different. If a single bit in a single byte has changed, to a bitorrent client they are TOTALLY different

How the bitTorrent network will handle these files?

It will treat them as what they are two completely different entities.

[OJNSim]

OK, I understand.

I thought the name does not play a role here.

So lets go one step forward please...

I have two files that might be the same but for some irrelevant reason the they are two different files for the network.

Is there any way I can "fool" the bittorrent client and make it think they are the same files?

What is "the file ID" that makes clients send part of a file #1 and not file #2, to the requesting client?

From a quick view in the first link, bittorrent specifications, it looks to me like the hash code. Am I right?

tx

OJ

[ciaobaby]

Is there any way I can "fool" the bittorrent client and make it think they are the same files?

Not with any real chance of success, unless you want to use a hex editor and edit the code directly on the drive and for that to even have an outside chance of working the pieces would HAVE to be contiguous.

What is "the file ID" that makes clients send part of a file #1 and not file #2, to the requesting client?

From a quick view in the first link, bittorrent specifications, it looks to me like the hash code. Am I right?

Almost right. BitTorrent doesn't have a concept of files, it understand pieces, which are equally sized blocks of binary data.

http://forum.utorrent.com/viewtopic.php?pid=684020#p684020

Each of the pieces have a number in the sequence and a hashsum of each piece in the metadata, so a piece number is requested and when the data arrives it is "hashed" and checked against the hashsum in the metadata, if they match the piece is accepted and put into the appropriate location in the 'jigsaw'.

If you have a fast downloading job you could watch the process happening in the 'Pieces' column on the files tab by observing the colour changes, it's marginally more interesting than watching paint dry if you like that kind of thing.

[OJNSim]

unless you want to use a hex editor and edit the code directly on the drive and for that to even have an outside chance of working the pieces would HAVE to be contiguous.

I can use hex editor...but what doed code on the drive mean?

Almost right. BitTorrent doesn't have a concept of files, it understand pieces, which are equally sized blocks of binary data.

http://forum.utorrent.com/viewtopic.php?pid=684020#p684020

Each of the pieces have a number in the sequence and a hashsum of each piece in the metadata, so a piece number is requested and when the data arrives it is "hashed" and checked against the hashsum in the metadata, if they match the piece is accepted and put into the appropriate location in the 'jigsaw'.

Yes, but what is the "sequence id". when a client asks another peer for piece #2, it also have to identifiy the sequence piece #2 belongs to.

Piece #2 of "Shutter Island With Leonardo DiCaprio", or piece #2 from the sequence "Iron Man 2".

Isnt it?

[ciaobaby]

but what doed code on the drive mean?

You would have to edit the file data WITHOUT loading it into memory and saving it back to the drive because that would alter the 'modified date', so your hex editor is really a disc sector editor, normally used for data recovery procedures.

Yes, but what is the "sequence id". when a client asks another peer for piece #2, it also have to identifiy the sequence piece #2 belongs to.

Piece #2 of "Shutter Island With Leonardo DiCaprio", or piece #2 from the sequence "Iron Man 2".

Isnt it?

Because each job has a hexadecimal ID which identifies it, this is a hashsum of the values of the metadata 'info' fields called the 'info hash', the torrent 'name' is simply a human readable identifier only used for captions. .

[OJNSim]

Ok. So you are talking about the editiing the file (movie) itself. I didn't mean that.

But, if I understand correctly, and I understand I simplfy this, the sequence identifier is basically the hash of the actual bytes sequence of a given file. As you indicated the torrent (file) name, is used only for caption, and It is not part of the hash.

If this is the case, I am asking again,

how come that the case, in which two seeds will upload the network the excat same file,( ie. the exact same bytes sequence), will result two differnt torrents?

[ciaobaby]

As you indicated the torrent (file) name, is used only for caption, and It is not part of the hash.

The name of the physical metadata file is not part of the info hash, they could be called Fred, Barney, Wilma or Betty when you download, load and store them on your machine for all it matters.

Ok. So you are talking about the editiing the file (movie) itself. I didn't mean that.

Ok so you are hoping to merge two metadata files into one, cross file pieces may/can/will 'break' that

But, if I understand correctly, and I understand I simplfy this, the sequence identifier is basically the hash of the actual bytes sequence of a given file.

Nope. The 'sequence indentifier' is the numerical index of the piece, zero based.

If this is the case, I am asking again,

how come that the case, in which two seeds will upload the network the excat same file,( ie. the exact same bytes sequence), will result two differnt torrents?

Because the probability of two metadata files, albeit with the same content, being created with identical clients, under identical circumstance is remote, but it can and does happen, but makes zero difference because for the info hash to be identical, it means that the piece count and piece hashsums are the same.

Try creating metadata files of the same content data using three different clients on the same machine and you WILL have three different info hash values.

The Vuze Wiki is a handy site to read for more information.