Pieces reluctant to finish?

[Ver Greeneyes]

This is more of a question than a complaint, as I've noticed this several times but I don't know if it's actually a pattern: I've been watching the pieces tab for a large download, and for some reason they often seem to more-or-less stall around 250-255 pieces. For instance I have a piece downloading now, the last piece of a file that I've set to high priority, which has been stuck at 255/256 pieces for well over an hour now, despite reaching 255 in less than five minutes. I don't know if this is just a coincidence or if it's a bug in µTorrent (or even a 'feature' of the BitTorrent protocol) ... so that's my question. Is this just a stupid coincidence or is there a way µTorrent could increase the priority for these final blocks? It's very frustrating to know a missing 16kiB block is keeping me from getting at a 286MiB file :s

Edit: I'm using the latest 1.8.1 beta, by the way. I haven't noticed any speed problems, but this torrent doesn't have a lot of seeders - and they don't seem to be getting their priorities straight.

Edit2: well, the download finished, but that block actually finished last of all. Apparently it had been requested from one peer, and that peer wasn't giving it to me. Only when it went into endgame mode did it finally finish. However, that means µTorrent didn't try to get it from anyone else for over an hour! (despite the high priority) By the way, I suggest a change in phrasing in the FAQ about Endgame mode. Endgame mode doesn't kick in when all pieces are being actively downloaded, it kicks in when all -blocks- of all pieces are being actively downloaded.

[Switeck]

Could've tried testing by using TCP view to disconnect the 1 slow source. Then uTorrent HAS to get that last 16 KB piece from someone else.

[Ver Greeneyes]

Yeah, I guess so. I wasn't sure what to use to do that, and I wanted to monitor it. It still seems strange to me that µTorrent would make no attempt whatsoever to get the piece from another peer, even after such a large delay.