Archived

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

Firon

µTorrent 3.1 Release Candidate 11

Recommended Posts

@ChichipioWilson: Thanks for an excellent report! I believe I've knocked these off today' date=' but I'll verify it some more tomorrow. Hopefully we can do a refresh tomorrow night[/quote']

ah, was wondering about that.

RC3 bug, show in "download" tab torrents that are already finished.

had 2 go back ...

yeah, im seeing that too. happening for torrents that you didn't select all files in, its probably the same bug as ChichipioWilson posted so arvid might have already fixed it.

That bug will be fixed in the next build (which we're hoping to do today).

Share this post


Link to post
Share on other sites

Any idea when it come out as finished instead of beta? It honestly does not matter to me if it never comes out of beta it's just a private tracker that refuses to put beta's on there list of usable clients for their tracker. Not rushing just wondering.

Share this post


Link to post
Share on other sites
I just had a torrent get stuck in RC3 (diskio.low_prio_disk = *false, if it matters) with two 1MB pieces (64 blocks each) left in cache. Status says "Flushing to disk (128)" but then they never get flushed, even though there is no other disk activity and it is the only active torrent.

Stuck Dump: http://www.mediafire.com/?drwz5e8q1jraa87

After I created the dump I restarted my other torrent, stopping the stuck torrent, and did a Force Recheck, which caused the program to hang. Let it go for awhile to see if it would be temporary but 3 hours later, still frozen.

Hang Dump: http://www.mediafire.com/?iuns6fghrl6vs5t

Also, please respond to the remaining items in my main post: http://forum.utorrent.com/viewtopic.php?pid=620310#p620310

Thank you.

build 26519 - getting the flushing issue with 12 x 16 blocks left = 192.

no hashfails, iskio_low_prio = true

No sign of heavy activity in disk, write stats show the cache is slowly growing, but virtually 0kbps on any meters. Only one other dl running at present, with very activity at present.

Stopping and forcing recheck locks UT up, leading to a forced app stop, restat and torrent is straight back to downloading, and last 12 pieces start downloading again and promptly finish in around 10 seconds. Looks like tythe flushing gets dropped and new copies of piiees cures the problem?.

Share this post


Link to post
Share on other sites

My modified disk / cache related settings are now those. My latest cache related mod was setting adv.->diskio.smart_sparse_hash = false due to hash fails.

Didn't see any of the above issues on Win7/x32, yet...

Try them out... be aware that the disk related I/O are set here to a "normal" (higher) priority for faster connections, but might do some good for others to keep the cache consumption at a lower level...

cacheoptimizedsettings.th.png

31rc5cacheoptimizedsett.th.png

Edit:

Eventually, this stuck at flush (512) state - happened to me too... With 2 pieces left in the cache. :(

dump: http://www.mediafire.com/?suuezo5hf3sxiup

Share this post


Link to post
Share on other sites

Hmm… that doesn't happen to me (and I'm guessing anyone else since it would be too obvious and someone would have noticed it by now). Are you sure it's not a problem with the translation file? I suggest you change your language to English and check again. Well, you should always do this step anyway. Forcing others to read screenshots in our own language is not the best way to get help.

Share this post


Link to post
Share on other sites

With RC3 sometimes (often enough) utorrent's GUI hangs for a 5-20 seconds. Also opened a torrent and it said: utorrent is already running. I know, i want to add the torrent. For the second add it worked.

Using win7 64bit.

Share this post


Link to post
Share on other sites
With RC3 sometimes (often enough) utorrent's GUI hangs for a 5-20 seconds. Also opened a torrent and it said: utorrent is already running. I know, i want to add the torrent. For the second add it worked.

Using win7 64bit.

Does it happen at startup and about every 20 minutes? Or is it random intervals instead?

Share this post


Link to post
Share on other sites
With RC3 sometimes (often enough) utorrent's GUI hangs for a 5-20 seconds. Also opened a torrent and it said: utorrent is already running. I know' date=' i want to add the torrent. For the second add it worked.

Using win7 64bit.[/quote']

Does it happen at startup and about every 20 minutes? Or is it random intervals instead?

Same for me GUI hangs for a 5-20 seconds every 2 minutes.

Share this post


Link to post
Share on other sites
With RC3 sometimes (often enough) utorrent's GUI hangs for a 5-20 seconds. Also opened a torrent and it said: utorrent is already running. I know' date=' i want to add the torrent. For the second add it worked.

Using win7 64bit.[/quote']

Does it happen at startup and about every 20 minutes? Or is it random intervals instead?

random intervals, every few minutes, sometimes twice a minute

when hangs my cpu usage is around 30%, when working normal it is 5%. ram usage is around 200mb. if it helps.

Share this post


Link to post
Share on other sites

Could you take a dump of uTorrent when the GUI hangs? Has to be during the hang, though.

In Task Manager, go to Processes, find utorrent.exe and right click -> Create Dump File. Compress it, then email it to me.

Thanks!

Share this post


Link to post
Share on other sites

Lost all my torrents on upgrade to RC4... I'm guessing due to the resume dir stuff you changed since I was using resume.dir_only = *true and got "File not found during integrity check: <%AppData%>\uTorrent\resume.dat" in the logger.. Were the hashing issues due to the resume dir or something?

Also, please respond to the remaining items in my main post.

Thank you.

Share this post


Link to post
Share on other sites
Lost all my torrents on upgrade to RC4... I'm guessing due to the resume dir stuff you changed since I was using resume.dir_only = *true and got "File not found during integrity check: <%AppData%>\uTorrent\resume.dat" in the logger.. Were the hashing issues due to the resume dir or something?

I'm seeing "ReadFile error: <filepath\name>:734480384:85032:562216:19" in the logger as well when I added a torrent where I unchecked files during the Add dialog. The ReadFile error was for the file I unchecked and the other file existed so it was being Rechecked.

Also, please respond to the remaining items in my main post: http://forum.utorrent.com/viewtopic.php?pid=620310#p620310.

Here is the dump as described in #4: http://www.mediafire.com/?s8m217hq4dgg6be

Thank you.

Hi osmosis,

Here is a work-around to get back your torrents:

- set resume.dir_only = false

- kill utorrent

- delete resume.dat

- downgrade to RC3

- run RC3, do load the torrent list (will also write out resume.dat

- upgrade to RC4

Everyone else: please do not use resume.dir_only.

Share this post


Link to post
Share on other sites

Well so far all looks good and working well. RC4 update seemed to fix all the hangs and bugs from RC3. Upon update, all went smooth and tranistion from RC3 to RC4 without a hitch. Did not loose any of my files or any of the above issues durring the update. Thank you for all the hard work guys! :D

Win 7 Ultimate 64 Bit

AlienWare 17X

Share this post


Link to post
Share on other sites
Here is a work-around to get back your torrents [...] Everyone else: please do not use resume.dir_only.

No worries, I just readded them from %AppData%\uTorrent. What's the big issue with resume.dir_only? Seems to have been working pretty well.

P.S.: Cleaned up my other buglist post. That dump goes with #3 on that list now.

Share this post


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