Archived

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

Firon

µTorrent 3.0 "Falcon" (32-bit) alpha 25207

Recommended Posts

Any chance of seeing the magnet uri/maindoc.ico association bug fixed before 2.0.1 2.1 final?

(As previously reported here and here, and independently reported/reproduced here. Jus' sayin' :P)

Share this post


Link to post
Share on other sites

18825 fixed for me, been running all day and no dramas :)

Thanks for the quick fix. Out of curiosity, what's the technical reason behind the out of memory error it was giving?

Share this post


Link to post
Share on other sites

Hello, Yeah the latest build 18825 has been pretty crash happy on my system. Win 7 x64. When it auto-updated to this version it crashed on restart and tends to crash on first start after system reboot. Now since then I get intermittent crashes shortly after the program starts up otherwise once it has been going for a few minutes I haven't seen it crash when left on for awhile. I have been making sure to "Send dump to developers" If I need to upload or report them here as well it's not a problem but figure there's no need to be redundant if you get them through that. Thanks. ~Cyc

Share this post


Link to post
Share on other sites

We'll be rolling another build today to hopefully fix the last of the crashes. Normally we'd ask for you to submit the dumps here, but I'm pretty sure all of you are suffering from the same crash bug.

This is all the result of revamping disk i/o handling to be more general purpose (and better written), so there's naturally some pain in getting it all fixed. :P

Share this post


Link to post
Share on other sites

Using version 18825.

In the last four version released alpha builds, maybe more, I'm seeing a lot of performance issues during downloads.

1. Inefficient piece download: pieces with a few yellow/white blocks are downloaded very late.

Example: you have a torrent with 500 1MB pieces, each piece containing 128 blocks.

The torrent starts normally, it downloads at a reasonable speed, but then it starts to develop a heap of pieces that are stuck at 126 or 127 blocks downloaded out of 128. The remaining one or two blocks are either:

"yellow" (requested more than 60 seconds ago, and it keeps requesting the blocks, appearently from the same peer, because it never receives it), or

"white" (for some reason, uTorrent gives up requesting the missing blocks completely).

This happens even for pieces with high availablilty (over 40). In the mean time, other pieces are downloaded normally.

This is very inefficient. Suppose there is one seed, and 40 peers. Each peer requests randomly one piece from the seed, and each (or a large percent) of the pieces gets stuck, let's say, at 127 out of 128 blocks.

The pieces are not finished because 1% of the blocks are missing, so the incomplete pieces cannot be sent to other peers that need them. So the only source for such pieces remains the seed, slowing down the download.

Most of the time such incomplete pieces remain with 1-2 blocks missing for hours, until the torrent reaches 99%. Then the download speed reaches 0, because uTorrent is still not requesting the missing blocks.

This seems to be a bug of some kind, uTorrent should request such pieces from other peers, and for some reason it doesn't.

The only workaround, if you don't want to wait up to one hour for uTorrent to request the blocks, is to stop and start the torrent. Then the torrent is completed instantly.

What I think should be done: prioritize piece download based upon the number of completed blocks. The more blocks completed, the higher the priority. This way, pieces with 99% of the blocks downloaded will have the highest priority, and will be downloaded first, so they will be available for upload to other peers sooner, freeing the seed of this task.

Also, for pieces with a small percentage of missing blocks, uTorrent should search for alternate peers more aggresively, if the peer it requested the missing block initially doesn't respond in a reasonable time.

1. Streaming stuck on some pieces:

"White" blocks before "green" blocks. It seems uTorrent forgets that some blocks required for streaming have not been downloaded, and requests pieces in green mode with a higher index, even though the previous pieces with lower indexes still contain white blocks (blocks not requested).

This results in the stream playback freezing when reaching the pieces with white blocks. The white blocks are not requested until the torrent reaches 99%, making streaming useless.

Closing VLC, and starting streaming again fixes the problem temporarly, the piece with white blocks is downloaded, then a new piece with an higher index becomes stuck with white blocks while uTorrent forges ahead with other pieces in "green" mode.

This makes the streaming feature useless.

I suspect problems 1 and 2 may have the same cause.

Oh, and my usual problem 100% usage of one CPU core on Win7x64.

And today with version 18825 it stopped downloading a torrent after a few completed pieces, complaining that the files are in use by another process.

Share this post


Link to post
Share on other sites

Oops. I knew I forgot something. :P

-- 2010-04-02: Version 2.1 (build 18888)

- Fix: handle column widths better on upgrade from older versions

- Fix: crash on startup if you had a lot of streamable files in your torrents

Share this post


Link to post
Share on other sites

I made a print screen to see what I mean about white blocks before green blocks during streaming:

whiteblocksbeforegreenb.png

As you can see, pieces 16, 17, 18, 19 already have "forgotten white blocks", but uTorrent is only focusing on downloading piece 20.

This was happening on a well seeded torrent, with version 18825.

The strange thing is, if I wait for 10 minutes, nothing will happen. Not even one of the missing white blocks from those pieces will be downloaded.

However, as soon as I close VLC, uTorrent starts downloading the pieces with "forgotten" blocks in "green" mode. This suggests there may be some locking issues between the streaming module and the download module.

Share this post


Link to post
Share on other sites

1. Download new torrent that has many files with build 18833.

2. Skip some files what are available with that one torrent

3. After a bit of downloading one file exit and install build 18888

4. While downloading your file with newer build keep looking at the log

5. You should be seeing that it tries to open up, create or something else with files that you wanted to skip and says access denied and then crashes up and offers to send crash file.

Share this post


Link to post
Share on other sites

Last two or three alphas does not slow down during http browsing and/or stream content viewing. bt.transp_disposition=15, bt.tcp_rate_control=true, so no ideas what's wrong.

Share this post


Link to post
Share on other sites
1. Download new torrent that has many files with build 18833.

2. Skip some files what are available with that one torrent

3. After a bit of downloading one file exit and install build 18888

4. While downloading your file with newer build keep looking at the log

5. You should be seeing that it tries to open up, create or something else with files that you wanted to skip and says access denied and then crashes up and offers to send crash file.

Your settings data may very well be corrupted. Do you have the dump files?

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.