Jump to content

More than just the "queue size"


2bad

Recommended Posts

Call me a newb, but I was encouraged to see that info about queue size was at the top of the list of posts in the Feature Requests the first time I ever went on this forum. I would like more than just queue size. I would like to see the size of data remaining to be d/l based on files selected within the torrent. It appears that the % downloaded does reflect the % of only the selected files. It would be nice if but the number of pieces remaining to be d/l based on the files selected is not shown within a torrent.

If less than all the files in a torrent are selected, it would be nice on the General tab to see, for example,

Pieces: ### x 64.0kB (have x)

Where ### is the number of pieces actually required to deliver only the selected files within the torrent rather than the total number of pieces in the torrent.

Generally, it would be nice to have more detail about the queue.

Link to comment
Share on other sites

Does that represent the remaining total size of the all the pieces necessary or only the total of the data of the uncompleted selected files or only the total of the partial file data remaining to be downloaded in the selected files?

Do you see the ambiguity?

Link to comment
Share on other sites

The number of pieces in the torrent should not be changed. If anything, adding a new number to display the number of pieces needed should be added, not replacing the existing number.

As for remaining... Is there there something insufficient about the Remaining column?

Remaining displays the amount of data left for µTorrent to download before it finishes downloading the torrent job. Note that this column takes selective file downloading into account, so only the data you select to be downloaded will be counted. If no data is left to be downloaded, this column will be blank.
Link to comment
Share on other sites

"The number of pieces in the torrent should not be changed. If anything, adding a new number to display the number of pieces needed should be added, not replacing the existing number."

Agreed. I am requesting more information, not requesting to replace existing information.

Link to comment
Share on other sites

Pieces: ### x 64.0kB (have x)

Where ### is the number of pieces actually required to deliver only the selected files within the torrent rather than the total number of pieces in the torrent.

Implies replacement >_>

Pieces: [total] x (have X {of Y needed})

or something would be better (where the stuff in the { ... } would be shown only if selective file downloading is used). The problem here is that a user might have pieces that belong entirely to a skipped file -- where would that be counted? This can happen if, say, the user downloads the piece, and later decides he doesn't want the file.

Link to comment
Share on other sites

"Note that this column takes selective file downloading into account, so only the data you select to be downloaded will be counted."

Then, if I only need 10kb to complete my file and it's in a 4.00MB piece of which I won't be using any other data, does the remaining column reflect the 10kb or the 4.00MB? See the difference?

Link to comment
Share on other sites

It reflects the the full piece size. There is no ambiguity: obviously, µTorrent would not show 10kB and then wait to download 4MB. However much is needed to be downloaded is what is shown in the Remaining column. You're reading deeper into it than you really need to.

Link to comment
Share on other sites

Well, the difference is in showing how much remaining that I have asked for versus how much remaining that I have to wait around for in order to get what I have asked for. If it is a large difference that might be useful to know. I might prefer to abort.

I guess, in general, it would be nice to be able to compare how much I have to download in order to get what I want to the size of what it is that I'm really after.

Link to comment
Share on other sites

Unless you're skipping every other file in a torrent with a ton of small files, the difference won't be large. Such a scenario is highly unlikely, and IMO, isn't worth the additional trouble of calculating the sizes. If you find yourself in such a situation, it wouldn't be too difficult for you to realize that the amount of wasted data will be massive anyhow (you already know that edge pieces will cause waste, after all, and the number of edge pieces increases as the average "surface area" decreases for each file relative to the piece size).

Doesn't mean it won't be implemented, but I tend to doubt it. Who knows -- my predictions aren't always 100% accurate...

Link to comment
Share on other sites

"Unless you're skipping every other file in a torrent with a ton of small files, the difference won't be large. Such a scenario is highly unlikely, and by my measure, isn't worth the additional trouble of calculating the sizes."

This is precisely the situation that has precipitated my request. It has happened several times in the short time since I have discovered the benefits of torrent technology. I think we're on the same page now.

That is, a torrent with a ton of small files but built in large pieces.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...