Jump to content

About bt.prio_first_last_piece


ezalo

Recommended Posts

This is my first post and perhaps a candidate for humiliation. I made a search but I could not find any suggestions similar to the one that follows. But we never know... :)

I'm using uTorrent beta 2.0.17539. The download priorization of the first and last piece seems, imho, a bit meaningless. Since its purpouse is to preview the currently downloaded file, in general, these chunks can not be enough for most players/readers/previewers to exhibit a proper result or to reconstruct parts of it. In particular, one can verify the authenticity :) of an avi file with chunk size of 256K *only* after the movie is completely downloaded, since an actual file is constructed approximately at random and uniformely. virtualdub can accomplish the index reconstruction with difficulty in some cases but it takes one life time of an average human. An analogous reasoning applies to rar or zip files or other type I don't recall at this moment.

It seems that an easier workaround is replacing bt.prio_first_last_piece by an int: 0 (don't priorize) or by a number representing the amount of chunks defined by the user. Or something similar, defined by you, C guys. Or I missed something.

Keep the good job. uTorrent is a fantastic tool.

Regards

------------------------

edit: or by a number representing a fraction of total size, eg. 2%, 5%, etc.

------------------------

edit: ok. my mistake. found a similar suggestion. http://forum.utorrent.com/viewtopic.php?id=65116 .

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...