starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

refuses to finish last piece #1861

New issue

Closed

opened 2026-02-21 15:53:50 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-21 15:53:50 -05:00

Owner

Originally created by @jmkqb on GitHub (Nov 19, 2014).

I thought I was getting something I could really get behind. I simply want to preview large mp4 files (usually documentaries which only have a title and little to no descriptive value) before repeatedly wasting bandwidth downloading 1-2GB of things I don't end up wanting. mp4 files generally won't play without data stored at the end of the file. So sequential and last piece downloading is exactly what I need. However, I have now tried 20 dls with a large number of seeds. Only 1 has downloaded the last piece properly. 2 have refused to even request it. And 17 have exhibited the identical exasperating behavior of requesting the last piece (little green line in status) but REFUSING TO FINISH THAT PIECE even as 25, 50, even 100 other mostly-sequential pieces finish perfectly. It is statistically impossible that these pieces just happen to randomly get requested from a "slow source".

I am not pretending to be an expert, but if that piece can be requested, something beyond chance must account for it not being completed.

I would suggest something like a "forced" "preview mode" where some timer is set when the last piece is requested and if it is not completed, some other attempt is made. It is also useful to go beyond a "last piece". Indexes stored in some of these files can be 0.5-1% of the size of the file. Last pieces can contribute less than a full piece-size to the file and even when they do, if there are more than 100-200 pieces, this may not contain sufficient data. In which case, it needs to be x last PIECES. In "forced" mode, non-sequential pieces would not be requested even though this may slightly reduce overall performance.

I was (and still am) willing to contribute if this feature actually worked.

Originally created by @jmkqb on GitHub (Nov 19, 2014). I thought I was getting something I could really get behind. I simply want to preview large mp4 files (usually documentaries which only have a title and little to no descriptive value) before repeatedly wasting bandwidth downloading 1-2GB of things I don't end up wanting. mp4 files generally won't play without data stored at the end of the file. So sequential and last piece downloading is exactly what I need. However, I have now tried 20 dls with a large number of seeds. Only 1 has downloaded the last piece properly. 2 have refused to even request it. And 17 have exhibited the identical exasperating behavior of requesting the last piece (little green line in status) but REFUSING TO FINISH THAT PIECE even as 25, 50, even 100 other mostly-sequential pieces finish perfectly. It is statistically impossible that these pieces just happen to randomly get requested from a "slow source". I am not pretending to be an expert, but if that piece can be requested, something beyond chance must account for it not being completed. I would suggest something like a "forced" "preview mode" where some timer is set when the last piece is requested and if it is not completed, some other attempt is made. It is also useful to go beyond a "last piece". Indexes stored in some of these files can be 0.5-1% of the size of the file. Last pieces can contribute less than a full piece-size to the file and even when they do, if there are more than 100-200 pieces, this may not contain sufficient data. In which case, it needs to be x last PIECES. In "forced" mode, non-sequential pieces would not be requested even though this may slightly reduce overall performance. I was (and still am) willing to contribute if this feature actually worked.

deekerman closed this issue

2026-02-21 15:53:53 -05:00

deekerman commented

2026-02-21 15:53:56 -05:00

Author

Owner

@chrishirst commented on GitHub (Nov 22, 2014):

I am not pretending to be an expert, but if that piece can be requested, something beyond chance must account for it not being completed.

The only thing that is required for a piece to be 'requested' is that your client does not have the piece already.

This kind of situation is known as 'piece starvation' and is a consequence OF sequential downloading.

@chrishirst commented on GitHub (Nov 22, 2014): > I am not pretending to be an expert, but if that piece can be requested, something beyond chance must account for it not being completed. The only thing that is required for a piece to be 'requested' is that your client does not have the piece already. This kind of situation is known as 'piece starvation' and is a consequence OF sequential downloading.

deekerman commented

2026-02-21 15:53:56 -05:00

Author

Owner

@jmkqb commented on GitHub (Nov 22, 2014):

I am sorry but either you didn't read my post or I wasn't as clear as I thought I was. In 17 of 20 cases the last piece was requested early BUT NEVER FINISHED. In every case I was connected to a considerable number of seeds with that last piece. If a piece is "requested", it should stand the same chance of completion as any other requested piece with approximately the same number of available sources. Yet many 100s of other pieces are requested and completed after the request of these crucial last pieces. A feature of "get last piece" should GET THE PIECE, not leave it REQUESTED AND UNCOMPLETED until the entire rest of the file is completed.

I did not just complain. I did my best to help in a solution. I am further suggesting either making the feature work or withdrawing it.

@jmkqb commented on GitHub (Nov 22, 2014): I am sorry but either you didn't read my post or I wasn't as clear as I thought I was. In 17 of 20 cases the last piece was requested early BUT NEVER FINISHED. In every case I was connected to a considerable number of seeds with that last piece. If a piece is "requested", it should stand the same chance of completion as any other requested piece with approximately the same number of available sources. Yet many 100s of other pieces are requested and completed after the request of these crucial last pieces. A feature of "get last piece" should GET THE PIECE, not leave it REQUESTED AND UNCOMPLETED until the entire rest of the file is completed. I did not just complain. I did my best to help in a solution. I am further suggesting either making the feature work or withdrawing it.

deekerman commented

2026-02-21 15:53:56 -05:00

Author

Owner

@chrishirst commented on GitHub (Nov 23, 2014):

"The last piece" has a couple meanings,

Are you talking about:
"the last piece";

as in piece number n+1 (where 'n' is the number of pieces in the payload)?
or
as in the only one required to complete the payload?
or
as in the final piece of a particular 'file'?

Does "not finished" mean,
received but discarded as a hashsum failure?

A feature of "get last piece" should GET THE PIECE, not leave it REQUESTED AND UNCOMPLETED until the entire rest of the file is completed.

Actually your client is NOT in control of that at all, it is up to the other peers whether or not they want to serve a request for any particular piece.
If the seeds are in "Super Seeding" they may be 'chocking' your client until another peer requests that particular piece. Have you checked the "peer flags" on your client when this appens?

@chrishirst commented on GitHub (Nov 23, 2014): "The last piece" has a couple meanings, Are you talking about: "the last piece"; as in piece number n+1 (where 'n' is the number of pieces in the payload)? or as in the only one required to complete the payload? or as in the final piece of a particular 'file'? Does "not finished" mean, received but discarded as a hashsum failure? > A feature of "get last piece" should GET THE PIECE, not leave it REQUESTED AND UNCOMPLETED until the entire rest of the file is completed. Actually your client is NOT in control of that at all, it is up to the other peers whether or not they want to serve a request for any particular piece. If the seeds are in "Super Seeding" they may be 'chocking' your client until another peer requests that particular piece. Have you checked the "peer flags" on your client when this appens?

deekerman commented

2026-02-21 15:53:56 -05:00

Author

Owner

@jmkqb commented on GitHub (Nov 27, 2014):

I appreciate that you are staying with this. I thought maybe I'd try saying it again with pictures. qb1 demonstrates the frustrating behavior. The black circled piece is requested almost immediately but as you can see remains uncompleted even as over 1/3 of the remainder is finished perfectly.

I briefly restarted a different torrent to demonstrate and give you some flags to observe. qb2 shows the state before starting (the last piece also requested early and staying green/unfinished). qb3 shows flags of some peers approx. 1 min. after restarting. qb4 shows that rather than completing the requested last piece, a few scattered other pieces are requested. Even if there are still only seeds in super-seed mode (unlikely since as you can see the torrent is now a minimum of 9 days old), some of them must be at the end. (If I leave the torrent running, you will see way more than 9 seeds.)

My current list contains 20 mp4 files (which I have been able to find no way to preview without this data at the end of the file) exhibiting the distribution of behavior described in my first post (17/20 like this, 2 failing even to request). When I start one of these torrents it is typically 3-4 days old and usually has multiple 100s of seeds so anything close to a majority in super-seed mode would be HIGHLY unlikely.

I have even stopped the torrent, rechecked it (which in your case seems to remove existing piece requests) and restarted them with "last piece first" selected and alternating sequential on and off and even varying bandwidth limits and connections. Nothing gets this "end" piece (maybe a better term?) to finish. Thus the files remain "unpreviewable" (probably not a real word).

Unfortunately, I must work within some data limits and want to be able to apply it to files I'd really like to see. uTorrent's "stream" mode works terribly, often giving the full technical specs of a file by completing this "end piece" (so I know it's possible) and then declaring fully-playable files "not supported" and thus apparently switching out of sequential mode. Your prog does a superior job of sequential downloading but won't finish these critical end pieces.

As I've said, I'm not familiar enough with the nuts and bolts to say how. I can only say that I've watched uT consistently get the crucial piece and I've watched your sw do a good job at sequential. I am just desperate to see those 2 things combined. As I said, it seems to me that it shouldn't be that programatically difficult to institute some kind of "forced preview mode" where the first x% of the file are downloaded and a necessary portion at the end (refer to my discussion in my first post) and other piece requests/offers were ignored.

I also know that's easy for me to say since I'm not the one who has to do it. If I were remotely proficient in cpp, I'd take your code and do it myself. I'm just not. So I'm hoping you are.

Thanks again

@jmkqb commented on GitHub (Nov 27, 2014): I appreciate that you are staying with this. I thought maybe I'd try saying it again with pictures. qb1 demonstrates the frustrating behavior. The black circled piece is requested almost immediately but as you can see remains uncompleted even as over 1/3 of the remainder is finished perfectly. I briefly restarted a different torrent to demonstrate and give you some flags to observe. qb2 shows the state before starting (the last piece also requested early and staying green/unfinished). qb3 shows flags of some peers approx. 1 min. after restarting. qb4 shows that rather than completing the requested last piece, a few scattered other pieces are requested. Even if there are still only seeds in super-seed mode (unlikely since as you can see the torrent is now a minimum of 9 days old), some of them must be at the end. (If I leave the torrent running, you will see way more than 9 seeds.) My current list contains 20 mp4 files (which I have been able to find no way to preview without this data at the end of the file) exhibiting the distribution of behavior described in my first post (17/20 like this, 2 failing even to request). When I start one of these torrents it is typically 3-4 days old and usually has multiple 100s of seeds so anything close to a majority in super-seed mode would be HIGHLY unlikely. I have even stopped the torrent, rechecked it (which in your case seems to remove existing piece requests) and restarted them with "last piece first" selected and alternating sequential on and off and even varying bandwidth limits and connections. Nothing gets this "end" piece (maybe a better term?) to finish. Thus the files remain "unpreviewable" (probably not a real word). Unfortunately, I must work within some data limits and want to be able to apply it to files I'd really like to see. uTorrent's "stream" mode works terribly, often giving the full technical specs of a file by completing this "end piece" (so I know it's possible) and then declaring fully-playable files "not supported" and thus apparently switching out of sequential mode. Your prog does a superior job of sequential downloading but won't finish these critical end pieces. As I've said, I'm not familiar enough with the nuts and bolts to say how. I can only say that I've watched uT consistently get the crucial piece and I've watched your sw do a good job at sequential. I am just desperate to see those 2 things combined. As I said, it seems to me that it shouldn't be that programatically difficult to institute some kind of "forced preview mode" where the first x% of the file are downloaded and a necessary portion at the end (refer to my discussion in my first post) and other piece requests/offers were ignored. I also know that's easy for me to say since I'm not the one who has to do it. If I were remotely proficient in cpp, I'd take your code and do it myself. I'm just not. So I'm hoping you are. Thanks again ![qb1](https://cloud.githubusercontent.com/assets/9856568/5219328/9809f894-7624-11e4-8186-3b8ddf51f6ef.jpg) ![qb2](https://cloud.githubusercontent.com/assets/9856568/5219331/9fea663e-7624-11e4-889c-c6a1a6685c42.jpg) ![qb3](https://cloud.githubusercontent.com/assets/9856568/5219340/af62b346-7624-11e4-8f6c-d043d3844cd5.jpg) ![qb4](https://cloud.githubusercontent.com/assets/9856568/5219364/d9e3d5f0-7624-11e4-8155-2d453b79bebb.jpg)

deekerman commented

2026-02-21 15:53:56 -05:00

Author

Owner

@chrishirst commented on GitHub (Nov 27, 2014):

If peers are not 'willing' to serve your client that particular piece absolutely NO AMOUNT of doing anything with your client will force it to happen, it does not matter whether you have sequential downloading on or off, first and last piece piece priority or not, and nothing anybody can write into libtorrent is going to make it happen.

Your client makes a request to the swarm for a specific piece, if no peer, seeding or not, can not, or will not, deliver that piece for whatever reason, your client is not going to receive it until one does respond with it.

@chrishirst commented on GitHub (Nov 27, 2014): If peers are not 'willing' to serve your client that particular piece **absolutely NO AMOUNT** of doing anything with your client will force it to happen, it does not matter whether you have sequential downloading on or off, first and last piece piece priority or not, and nothing anybody can write into libtorrent is going to make it happen. Your client makes a request to the swarm for a specific piece, if no peer, seeding or not, can not, or will not, deliver that piece for whatever reason, your client is not going to receive it until one does respond with it.

deekerman commented

2026-02-21 15:53:56 -05:00

Author

Owner

@alfrix commented on GitHub (Dec 1, 2014):

First of all "Download first and last pieces first" and "Download in sequential order" don't work well together it seems like sequential order takes preference. #189
@sledgehammer999 i think you should close this since it's #372

@alfrix commented on GitHub (Dec 1, 2014): First of all "Download first and last pieces first" and "Download in sequential order" don't work well together it seems like sequential order takes preference. #189 @sledgehammer999 i think you should close this since it's #372

deekerman referenced this issue

2026-02-21 16:10:04 -05:00

Prioritize by file order #2344