How to disable BitComet from creating Padding files in torrents

Others Torrent Questions
1

Hi!

Recently all my created & uploaded torrents were removed from a site. The reason for this deletion was PADDING Files

These are automatically created and placed in the torrent which is unique in BitComet only. It may have its advantages,

but many sites have taken policies not to allow torrents that contain these files. So now my question, is there a way

to disable the creation of padding files in the current version of BitComet 1.27.

I’ve googled and learned that in a certain older version this was possible, but I don’t want to roll back to a older

version as newer versions download faster so please help me find a way.

Thanks & T.C

align file piece boundry.jpg

2

Further research on this led me to an option in the make torrent dialogue box. The " align file to piece boundary ".

I’ve learned that this option, enabled by default from version .85 creates the padding files and disabling it will stop the

creation of the said files in the torrent.

But what I’ve learned about the reason behind it’s creation now, my question to you is, will this option if disabled at the

time of making the torrent create any kind of problem, such as

  1. Downloaded torrent not opening

  2. Downloaded torrent not playing

  3. Downloaded torrent stuck at 99.99%

I’ve given the site address on this topic below for the benefit of forum users.

http://wiki.bitcomet.com/align_file_to_piece_boundary

Thanks & T.C.

3

This option can easily be disabled by unticking the “align file boundry” option when making a torrent.

/monthly_07_2011/post-1287-13100399619722.jpg" rel=“”>

As far as someone banning torrents that contain padding files, this is done either out of ignorance, or stupidity. Ignorance can be cured, so I will attempt to do so in the case that a reader may wish to know the reasons for these files.

When bittorrent downloading occurs, it doesn’t download a group of files, it downloads a group of pieces, some pieces can contain data belonging to two or more files. The use of padding files simplifies this so that bittorrent protocol becomes more compatible with http/ftp and emule downloading, so you can more efficiently download the pieces from sources outside the bittorrent swarm.

Q: Someone might make the comment that these padding files may benefit the bitcomet user, but the rest of the users don’t benefit and have these annoying files they have to download.

A: These files can indeed benefit the entire swarm in some situations. If this torrent was unseeded and the entire swarm was stuck with less then 100%, a bitcomet peer could complete the download from sources outside the bittorrent swarm, then in turn become a seeder and revive a dead torrent.

Also, these files are very small and are harmless. There is no rational argument for calling them annoying and after your finished seeding the task, the user can simply delete them.

Q: Can a non-bitcomet peer simply disable the download of these files?

A: Yes, but doing so won’t stop them from being downloaded, they just won’t appear in your GUI. Your bittorrent client will put them in a temp file containing unwanted data that are normally created when individual files are disabled in a torrent. The uTorrent client will put them in a file such as “~uTorrentPartFile_xxxxxxxxx.dat”, and other clients have a similar method, but if other clients adopted bitcomet’s method, it would serve everyone’s interest.

4

ps. to answer your questions from your second post. Disabling this option won’t cause any problems for a normal bittorrent download in any way.

However, lets assume you have a torrent containing 3 movies and the swarm is all stuck at 90% and movies 1 and 2 are complete, and movie three is incomplete.

If BitComet finds this same file on emule (or other) network and downloads it, your torrent will be 100% complete IF it contained padding files. If it did not, then the torrent may only be able to use 99.9% of the complete movie 3 that was downloaded from emule. You’ll have the complete movie, but you won’t have 100% of the bittorrent pieces so you can share it all with the swarm.

The above situation could occur when movie 3 was accompanied with a text file or nfo, and although you downloaded the complete movie via emule sources, you could not share the complete movie because one or more of the bittorrent pieces would be incomplete. Padding files would negate the possibility of this happening.

In this case, a tracker that banned padding files only harmed themselves.

5

I’m 100% in agreement with you and I will also take up the issue on that web site’s

forum too. For that if need maybe, I need your permission in advance so that I could

quote from your explanation and also can I mention you there.

You’re right the deletion was made out of ignorance and just because the moderators

there prefer another bit-torrent client doesn’t mean that they have the right to

force everyone to use it when creating torrent’s.

P2P is a means for sharing and freedom. And everyone should be free to chose their own

preferred clients. Forcing it cannot be justified in any way by a mere issue such as

having the padding files and them being garbage, when the advantages are vast if they are kept.

P.S: I had a net problem that led to the first posting if I knew about that I wouldn’t

have re-posted I am very sorry for this, if possible please feel free to delete the first topic

Removing padding files.

Thanks & T.C.

6

TUUS, I must confess that you totally lost me in the second paragraph of your last post. :blink:

How is it possible to have the complete last movie and yet be stuck to 99.9% even though you have all 3 files at 100%?

It doesn’t make much sense or I’m missing something.

Besides, from what empirical observations I made so far, eMule seems to be working fine with torrents not made with BitComet (it appears as the team found a way around the issue of non-BitComet torrents).

Meaning that it doesn’t seem to be a need of padding files in order for eMule to be able to finish a downloading torrent that doesn’t have seeds anymore. Ditto, for web-seeding.

Perhaps we should test that.

7

My example wasn’t very good. The point I was trying to make, but did so ineffectively is that if a file is downloaded with emule, you may not have all the bittorrent pieces that make up that file.

In the example I mentioned it would require the torrent have

movie3.avi

movie3.nfo

and you download movie3.avi from emule, so you have the complete movie, but you cannot share the complete movie if you don’t have the .nfo that is included in one of the bittorrent pieces.

However, if padding files were used, this wouldn’t happen.

edit: I also know from experience that you can get the exact same movie in one torrent, and it will only seed another to 99.9%. Usually because of a minute difference in an .nfo file or something similar, but if the movie3.avi didn’t share any bittorrent pieces, then the emule downloaded movie could easily be made into a 100% complete set of bittorrent pieces.

8

Your welcome to quote me, and if they have any questions, I’d be glad to address them. I do hope they aren’t offended if they read my comment about ignorance or stupidity, but understand we’ve dwelt with a lot of really lame complaints, even likening padding files to a virus, which is just ridiculous.

With Public torrents, bitcomet peers are by design the most swarm friendly. Besides emule, our LTseed network can also complete unseeded tasks so the bitcomet peer can then seed to the rest of the swarm.

For Private torrents, it’s a non-issue because padding files won’t be created.

9

Yep, but if the .nfo file is missing, even if you use padding files you still wouldn’t have a 100% progress for the torrent (due to the missing .nfo). You would have to disable the .nfo file in BitComet in order to achieve 100% in your own client. But in whole the torrent still wouldn’t be complete.

So there is only a partial gain. The end result will still be that you’re able to seed the complete file you downloaded from eMule and spread it into the swarm, whether you use padding files or not.

Since eMule seems to be doing fine without padding files, they don’t seem to serve the same essential purpose as initially. My empirical understanding is that the taskname.piece_part.bc! kind of substituted padding files in all their functions. Although I may be wrong.

The fact is that we never had explicit info on what purpose do padding files **still **serve (that is not covered by the functionality of taskname.piece_part.bc! and of perhaps the new downloading algorithms) so at this point it seems to me like we’re more guessing than stating cold hard facts when we have to answer to users about this.

Padding files would have been great, if they were adopted by all major clients but in the current situation you have to admit that they can be somewhat of a nuisance for non-BitComet users.

While they may scarcely appear in a torrent containing a movie for instance, if you create a torrent containing a couple hundred of mp3 songs or even worse a collection of over 1000 ebooks, then the number of padding files can become proportionally high.

If you use a different client, all those files that you have to delete manually, in the end, won’t make you say nice things about BitComet.

My opinion always was that the option should be (in the current state of things on BitTorrent scene and with all the reserved attitudes towards us) disabled by default. The time when the option may have been adopted and implemented seems to have come and gone and nobody will be able to force at the present time the devs of the other major clients to implement it any time soon.

All clients seems to have settled for using a temp file for boundary pieces (BitComet included).

So, unless they still serves a purpose that eludes us at present time, why keep getting bad reputation on their account?

10

The main purpose between padding files and part files is that it keeps any single bittorrent piece from spanning two or more files. the “part” file system only collects the unwanted data and stores it, it’s an after thought way to handle data from unwanted files, but padding files eliminate the need for that data.

Torrent with padding files.

Movie1 (bt parts 1-100)

Movie2 (bt parts 101-200)

Movie3 (bt parts 201-300)

Torrent without padding files

Movie1 (bt parts 1-100)

Movie2 (bt parts 100-199)

Movie3 (bt parts 199-298)

Now, if you download Movie2 from emule, you’ll only have complete bt pieces 101-198. You can’t have parts 100 and 199 because they require having part of movie 1 and movie 3 (respectively). Padding files eliminate this shortfalling.

Also to clarify, you’ll have the complete “movie2.avi” on your system, but not the complete pieces to make it in the bt task.

11

Additional thoughts.

All clients seems to have settled for using a temp file for boundary pieces (BitComet included).

Just to clarify, this only addresses the problem of downloading torrents, but does nothing to solve the issues with cross-protocol downloading. Padding files (or another yet undeveloped option) are necessary for bitcomet to download a file from within a torrent and construct 100% of the bittorrent pieces that make up that file.

Currently, on a torrent without padding files, an emule downloaded file will not be able to seed 100% of the content of the same file in a torrent unless it’s the only file within that torrent, but one small txt or .nfo file in the torrent and one of the BT pieces will be incomplete. If that piece is already present in the swarm, then it’s not a problem, but BitComet’s ability to save an unseeded task wouldn’t rely on this condition if the torrent had padding files.

12

TUUS, I understand what padding files do and the issue they solve.

My point was that even if you work with a torrent with padding files enabled, if you still miss the rest of the files (that go along with movie2 which you downloaded from eMule) you won’t be a seeder in the full sense that’s understood in BitTorrent (i.e. you’ll still be missing some files of the torrent, thus you won’t have 100% of the torrent content).

There is no argument from my part that padding files would push the situation a step forward, as far as uploading, into the swarm, the whole file(s) downloaded from alternative sources (eMule) goes.

But as I said, given the current situation in the scene one would have to weigh the pros and cons.

In the example I gave you (torrents with lots of little files) the number of padding files generated on non-BitComet clients is humongous (it could be almost as big as the number of files) and thus the management hassle to eliminate them undeniable.

Besides, clueless users (the likes of this one who posted the question) won’t know how to make the difference between a situation when by enabling padding files, the benefits will outweigh the nuisance (i.e big files such as movies) and the opposite.

Therefore, you can sympathize with a tracker admin that wants to avoid a flood of complaints, questions and anger from many users who’ll wake up with loads of padding files in their downloads.

If anything, I think those tracker admins are doing a favor to us, preventing way more users from becoming “enemies” to BitComet.

I still think that this decision to let the option by default on enabled is still being regarded by the rest of the Scene with not very welcoming eyes, since we appear to “disregard all the other clients out there” and it’s only fueling the hostile attitude of many trackers.

I’m not debating a single second the technological potential benefits of padding files for the entire swarm (when enabled); I’m just saying that in the current state of facts (with other clients not showing the slightest sign that they intend to adopt it) it remains a rather oddball that, alas, too often has undesirable effects on the public image of BitComet.

It’s true, we could always throw back that the option could be implemented by other clients too, to avoid this but they will always point that this option was kind of “forced” on the community without going through a proposal-draft path. The truth is that this option was very under-publicized, so basically the community was never given the chance to digest it, and perhaps adopt it; if a single major client would have been co-opted into this, BitComet would have won the battle a long time ago on this front. I think you’ll agree that it’s good marketing that sells an idea; even a good one. Unfortunately, this was never a strong point of BitComet.

Instead this was simply launched out there, and when people woke up with lots of meaningless files, they viewed this as “being forced on them” and naturally reacted as we all know.

And in fact, at the end of the day the users of other clients have no fault that the developers of the clients they use, choose not to implement this option.

Therefore we will always appear to “burden” them for no reason or to be using “aggressive” marketing tactics by forcing them to switch to BitComet in order to get rid of the nuisance of padding files.

13

I have to agree that BitComet’s public relations have been horrible. Most people (myself included) had no idea what padding files were when we first saw them. The file name choice was poor too. I think it included something like “update to bitcomet version 0.85 or above to avoid seeing these” in the file names themselves. They should have said “used to align bittorrent piece boundary”. It wasn’t until our torrent freak paper was published that many people even knew why this was done, and I do have to agree that it probably should be disabled by default.

Also, about the number of padding files equaling the number of files, there can never be more padding files then bittorrent pieces, so in a large torrent with 1000s of files, there should be much less padding files if each piece contains multiple files.

On another subject, it would be nice if bitcomet could automatically archive files in extremely large torrents. I think I’ll make a post about that suggestion, but if you have a 100gb torrent that has 50,000 photos in it, the overhead would be huge and it would be nice if it would automatically put them in zip archives for the user.

back on topic, I hope I successfully explained how it would be possible to download 100% of a movie via emule but only be able to share 99.x% of it on bittorrent.