theron

Thanks for the post and dumps. I'm taking a look a this now.

At 14 crashes per 1000 you probably won't see many crashes on average but in reality it's likely there are a number of people that have something in their settings or resume file that cause it to crash much more frequently, such as a terabyte+ sized torrent with tens of thousands of files where they select every other file to download (a possible crash I'm looking in to now). We like to shoot for 4 to 6 crashes per 1000. Any time your machine goes in to high CPU load because of our client please feel free to send me a sample along with a screen shot and an explanation of the conditions under which this is occurring including OS version, machine setup and wether or not any of the target locations are on an external or network drive. Any information we get can help us nail down the problem. The client is pretty good about choosing peers from the list available from the trackers, DHT and peer exchange. Tweaking the limits on a per torrent basis up or down when there are user storms may not be as helpful as you might think as everybody is competing for a small number of peers with a set maximum bandwidth but if it's a feature you think would be popular you may want to post it on uservoice: http://utorrentideas.uservoice.com/forums/58959-torrent-mac http://utorrentideas.uservoice.com/forums/47263-torrent-for-windows Since this feature would require some core changes to implement I would recommend posting it on the windows client board since they see much more traffic. If it makes it in to the windows client and in to our core code it will be a trivial addition to the mac client.

Fixed in 1.5.3.

I'll be checking this out on Lion later on this week.

Auto updates are currently turned off for this version because we wanted to see how stable it was for the few people that would download the latest version before we updated all of the beta users. The crash rate is somewhere around 14 crashes per thousand which is too high so we'll probably avoid turning on the autoupdate until we get a new beta build out with a few more bug fixes. Hopefully we'll have that up later on this week.

Just confirmed the bug. Thanks for the info. We'll look in to fixing this.

There is a bug where if you manually select an RSS feed item for download it doesn't show the torrent add dialog like the windows build does. This will not make it in to the next beta refresh but will be addressed before it goes stable. I haven't been able to reproduce the missing feed names after adding the torrent for download but I'll keep an eye out for it. Do the names come back when you restart uTorrent? Check your system log and see if there is an array out of bounds error when this happens. If both of these are the case then the problem should be fixed in the next beta release.

This should be fixed in the next beta release.

I don't know how AppZapper works exactly when it deletes all traces of a program... so are you sure that it deleted the settings.dat file in ~/Library/Application Support/uTorrent/ ? Yes, we removed ALL traces of the app. When I run Version 1.0.2 (23439), I have zero problems. The .torrent files go in there by default but the actual download should default to your Download directory assuming it exists in ~/Downloads. If it's missing or not writable it's possible it would fall back to your application directory. You can change where the .torrent files are stored in your directory preferences. Have you tried running Disk Utility -> Repair Disk Permissions on your disk?

No. Here is my configuration for "Directories": NEW DOWNLOADS: F:\Download\Incomplete COMPLETED: F:\Download\Complete Also' date=' I got this error tonight using latest build (25327): Error: Invalid access to memory location I selected only one file in the torrent. After viewing the sample I selected the full version and gave it a priority of high and got the error mentioned above. I get it even when doing a "Force Re-Check".[/quote'] Well there's your problem! That explains why I was having so much trouble reproducing this issue. I'll look in to the file selection/deselection bug as the probable cause.

Is your COMPLETE folder on a different drive than your download folder?

This has already been added to the backlog.

This is definitely a bug. I'll look in to it.

I have copies of your process samples as well as the zip file with both the dump and the configuration files (thanks erume). I will go through them and see if I can't nail down the problem.

Interesting. Could you upload the full dumps to a hosting site and put the link here so I can pull it down and check it out? I haven't been able to reproduce this since the last fixes went in to 0.9.1.1. Also if moving your setup/config files out of the way fixes the problem please upload a copy of those too with your process dump and I'll try to reproduce this. Thanks.