Advanced setting: bt.initial_piece_percentile

bt.initial_piece_percentile ... A numeric value from 0 to 99 which governs the position at which default initial-seeding begins. If there are, say, 5000 pieces in a torrent, then 0 begins at piece #0. If the value is set to 25, then initial-seeding begins 25% of the way into the torrent, or at piece #1250 in this case.

Usefulness: Imagine a situation in which the creator of a new torrent realizes he needs to fix something after seeding some portion (say, the first 15%). As things stand now, he X-outs, fixes things, creates a new .torrent file (different hash), re-uploads to hosting sites, and begins seeding...from piece #0. Pre-existing peers with partially completed sets show up eventually after DLing the new .torrent files, but generally not until well after the seeder has duplicated a lot of effort. But by manually adjusting the initial-seeding start marker, he can skip over previously sent material in the expectation that pre-existing peers will seed it when they eventually return.

Or, the seeder may wish to emphasize a particular file in his torrent first; i.e., a "sample" file.

(I've needed/wanted to do both of these on a not infrequent basis.)

Heh, I faced a similar situation. It was a two-file torrent, and the first file had been seeded separately a few weeks before. Now that we had both files, we wanted one torrent with both files.

Heres what I did. I put a second peer into the swarm, using a second computer. That second peer had 100% of my first file, but none of my second file. That forced the super-seeder (not sure if it was Azureus or uTorrent) to move ahead to the first pieces of the second file. Once that started, I simply disconnected my second peer so all of my bandwidth could focus on the 2nd file and several someone elses who downloaded the first file already could seed it into this swarm.

It worked.

For me, it's been a very rare need. I'm not sure I'd prioritize this as high as you would.

Well, as the peer, you're in the catbird seat. But if you were the seed and I were the peer...and not showing up in a timely manner -- yet you *knew* I was out there with the first gig's worth of the torrent just waiting to trade it for you -- it'd drive you nuts to have to seed that gig a second time, and then have me show up an hour later.

I find myself wanting this ability at least once a week. I think it's an easy inclusion because, somewhere within the guts of the code, uTorrent already has a default value (piece #0) to begin initial-seeding from. My request is just that the value be accessible to change by the user (whether it's a percentage or a piece integer isn't that important to me).

I think it's an easy inclusion because, somewhere within the guts of the code, uTorrent already has a default value (piece #0) to begin initial-seeding from. My request is just that the value be accessible to change by the user

Very good point ... it's low risk and easy ... those factors do matter.

This kind of option wouldn't belong in the Advanced options, as the Advanced options affect things globally. If you're initial seeding 2 torrents, and you don't want to start seeding from the exact same percentile on each one, it would definitely have to be a per-torrent option.

While on the topic of percentage, it's a very unprecise method of deciding what piece to start from.

If you're initial seeding 2 torrents, and you don't want to start seeding from the exact same percentile on each one, it would definitely have to be a per-torrent option.

I'd just change the value inbetween starting torrents. But I'll be happy however I get the feature.

While on the topic of percentage, it's a very unprecise method of deciding what piece to start from.

True...now that you can determine exact piece ranges in the Files tab (has uTorrent always had that, or did I only notice it lately?), integers are probably better. Picking a number too high should default to the last piece of the last file in the torrent, following by piece #0.

This is pretty impossible to accomplish. You upload the pieces the peers request, not what the you/your client thinks it should upload. Although there's an extension that can help with this: http://www.bittorrent.org/fast_extensions.html. Of course, you can always favor requests that fall into the range you specify, it still wouldn't do exactly what you want.

Wyrmchild, this request is for an ability to manually tweak initial-seeding mode. (It's meaningless to regular seeding mode.)

Here are two reasons why it's necessary.

Initial seeding mode works by mimicking fast extension in a rather horrible fashion by only telling peers you have those few pieces you're ready to serve them immediately. Initial seeding also hides your status as seed because of this.

And I highly doubt the initial seeding works by linearly seeding all pieces from 0 to the highest piece - if it does, then it's counterintuitive to the arguments of leeching the files in-order which the forum mods and probably some developers have been shouting as being a Bad Idea.

It does not strictly follow 0-end ordering. It at least attempts to ignore pieces that it sees are already present.

Initial seeding mode works by mimicking fast extension in a rather horrible fashion

Shame that the original super-seed algorithm was implemented before fast extensions even existed at a concept level. Super-seed attempts to hard-enforce what the fast extension only tries to suggest.

Initial seeding mode works by mimicking fast extension in a rather horrible fashion by only telling peers you have those few pieces you're ready to serve them immediately. Initial seeding also hides your status as seed because of this.

Are your sure about that last part? IIRC, I'm able to see a torrent's uploader listed as a seed in Peers while he is in initial-seeding mode.

In any event, we're getting off-track; please see the "two reason" links. They are very annoying to power-uploaders, particularly those who deal in multi-file torrents and seeding from multiple machines and/or locations.

Yes, I'm quite sure, because to be listed as seed you need to report that you have all the pieces, yet most super-seeding modes accomplish this by reporting only few pieces that they want _you_ to have, instead of allowing you to choose freely from what they have for offer (the default). This can't be accomplished without hiding the fact that they have all pieces, ergo, they appear as normal peers because to be listed as seed you need to tell them you have all the pieces. Of course, they still send announces as regular so the tracker sees them as seeds.

In regards to the two links, it can't be resetting when it isn't sending them in linear fashion. And the second link has very little to do with this, than allowing users to point the start point which the client could deduce by itself after some pre-defined amount of time of no piece requests from the peers. Instead of allowing the user to point some arbitrary start point.

The tracker may see a initial seeder as a seed while peers seed the initial seeder as another peer with typically low percentage completed...rising (very?) slowly as the torrent progresses.

Seeds may briefly connect with initial seeders, but the initial seeder should report themselves as a seed and disconnect from them.

In regards to the two links, it can't be resetting when it isn't sending them in linear fashion. And the second link has very little to do with this, than allowing users to point the start point which the client could deduce by itself after some pre-defined amount of time of no piece requests from the peers. Instead of allowing the user to point some arbitrary start point.

I will reiterate: Both of the those are very annoying to power uploaders. Common situation: I am initially-seeding a new torrent (one of many projects making demands upon my bandwidth); after sending out couple gigs or so to a half-dozen peers (because the torrent is still new), several of them disappear, taking a fat hunk of the torrent with them. Shortly after that, I need to restart for some reason or other. -- And what am I supposed to do with v1.7.5 now? Reseed starting from piece #0, when I have every reason to believe the absent peers will eventually return and off-load their accumulation? Being able to control the position marker -- or at least prevent resetting to #0 as per previous versions -- enables me to continue sending "virgin" pieces. With manual control, I'd also be able to seed, say, an NFO file or sample file first in a multi-file torrent.

Reseed starting from piece #0

I already said it doesn't seed linearly from 0 to the end. As did DreadWing.

Saving the availability on exit is also bad (you have no guarantees after restart that they actually _are_ on the swarm, though some timestamp comparison could be done whether or not they might still be there), just crank up the per torrent peer limit to something like 50 or so and you're very likely to see enough (=all) peers to make any such restarts percentages unjustified.

INITIAL-seeding. In a *new* torrent. Starts at 0 and increments. I know, because I can watch it in the logging tab. (And who cares if they may or may not come back to the swarm, when I know there's parts of my torrent that have NOT been initially-seeded at all?) In any event, the reset-to-0 bug has been fixed in 1.8b, and that solves 1.7.5's problem.

A manual positioning tool for initial-seeders of multi-file torrents would still be very welcome.

Well, it shouldn't do that, and fixing that is more important than adding some arbitrary user controlled feature so the user can fix it.

Well, it shouldn't do that...

....do what? Count up one piece at a time?

-- But that's exactly what I want initial-seeding to do. The very last thing I want it doing is jumping around tossing out pieces at random -- because then if a peer disappears back into the swarm for awhile, uTorrent loses track of that piece, and might send it out again before it's percolated back to any connected peer. Whereas, with the incremental system, if pieces #0 to #4729 have been sent, I needn't worry about uTorrent ever sending those pieces out again before the entire torrent has had at least one upload pass. Meaning: If some leech DLs a half-dozen pieces and then quits the torrent until it's at 90%, then rejoins, his pieces may make it back into the mix before I gotta run through it again. And the crowd goes: "Yay! 24mb we don't have to duplicate before we can get on to our next project!"

(Honestly: I wonder sometimes how many of you actually make torrents. Big torrents that take days to get established. Watching your client stubbornly insist upon re-sending pieces that you know are already out there in the hidden cloud when there are pieces that have never been sent yet -- is extremely frustrating. I'm telling ya: I *swear* at my machine loud enough that the people in the upstairs apartment hear me. It's a massive waste of my time and bandwidth -- mine as well as everyone else in the torrent, because they ALL have to wait TOO when I'm delayed getting the torrent to a full distributed copy.)

I've made several multi gigabyte torrents, and usually my ratio is around 2.5 when first stable(!) full copy appears (and not just some hit&run type), but that's with only ~10 connected peers out of over 20 known. And this is from full-time seeding, no breaks or anything in between. How much worse can it get with the same pieces uploaded multiple times with limited connected peers? And random uploads are better for avoiding hit&run types who only want to check the initial file and ignore the rest. Ergo, random seeding forces them to contribute longer because it takes them longer to get full files.

I've made several multi gigabyte torrents, and usually my ratio is around 2.5 when first stable(!)

Then you're uploading about 145% more than you should have to using initial-seeding mode and IP-blocking (in PG2) the more egregious leeches.

If seeding 105% takes you two days, and you have several other upload projects lined up, you do NOT want to spend five days seeding 250% before you can move on to the next project.

And random uploads are better for avoiding hit&run types who only want to check the initial file and ignore the rest.

That is absolutely, categorically untrue, and probably why you're having to upload 250%. In regular seeding mode, you will upload the most popular file in the torrent many times before you finally finish seeding the file which is marked "low" priority by the most people. Furthermore, if a leech grabs a chunk and runs, he'll usually have sent out a dozen tiny 16k and 64k "slivers" to other peers, and your client will try to "finish" that piece, often multiple times so long as it's rare and in a file marked high-priority.

But do things my way (sequential initial-seeding), and that highly-requested unfinished piece will just sit there waiting endlessly while every other "virgin" piece in the torrent is sent out first. While this happens, the unfinished piece becomes ultra-rare, meaning that when the leech does finally log back on, other peers immediately requests his ultra-rare piece, and drag it out of him before you, the seeder, have to cycle through a second pass.

Now if you're talking about leeches who grab one file in a multi-file and split, well then regular seeding is worse, because it enables peers with that mentality to get their whole file and then leave. Sequential-seeding, otoh, tends to delay (or thwart entirely) the rate at which they can snarf one file prior to their being a whole distributed copy. This is good for two reasons: 1. if they stick around, they have to re-trade in order to get anything out of anybody. 2. if they leave, they're a leech I don't have to deal with anyway.

Sequential-seeding may work just fine for single-file torrents, but if there's a bunch of files in a series and people are wanting to just get the first file and run...it's potentially possible to leave a lot of people in the lurch if the grab-and-run peers are the only ones (besides you the seed) that had all of the first file/s.

While initial-seeding, I couldn't give two flaming farts for making sure that any particular file of a multi-file torrent is finished completely unless I specifically want that particular file finished completely (e.g., a sample file or an .nfo file). My express interest is in securing a distributed copy with the least demands upon my bandwidth. If anything delays that, then *I* am in the lurch, and consequently everybody waiting for my *next* torrent is in the lurch too.

I think we need to look to FAST extensions to help out for this...where the seed instead of the downloading peer can decide what part is best to give next.

I would LOVE any kind of "ultra-mode" initial-seeding capabilities, however they are implemented or widgeted. E.g., customizable "seed the files of a multi-file torrent in this order" options, IP-address tracking across disconnects to thwart leeching, etc.

I'm just dying for finer-tuned tools....