Ut 1.8 takes forever to load

while Ut 1.7.7 takes a few seconds, 1.8 loads in some minutes. now, this is a problem i had with an earlier beta too, so i thought it was a bug needed to be corrected. the problem is still there with the stable version though. i think the problem may be that i have 1500+ completed files in list (which i'd prefer to keep), but why should a new version work worse than an older one? did anything change with the files management in the 1.8? and is there a way to disable it, maybe through some advanced options?

oh, my OS is vista ultimate, AV is antivir, and i use vista firewall. it's a fast computer too (quadcore) so that's not the issue. but i repeat, 1.7.7 works perfectly fine in the same configuration.

so.. does anyone have any idea why this happens? i searched in this forum too but found nothing so far..

This is my complete wild guess ONLY!:

Over time, maybe the data files uTorrent uses to keep track of all your files got slowly corrupted.

...Maybe due to power outages?

nope, if i downgrade to Utorrent 1.7.7 it works perfectly fine. the problem is not the data files..

You could be right then...either slower code for uTorrent v1.8's handling of torrent lists...or uTorrent v1.8 accessing Windows code that uTorrent v1.7.7 didn't...that is slower.

I can only imagine that if you have an active file indexer on your computer that it HAS to bog down something horrible when uTorrent fires up.

hmm no i'm pretty sure i disabled the file indexer as soon as i installed vista (i always do)

one thing that maybe i didn't mention: an earlier version of the 1.8 beta worked perfectly fine too! i'm not really sure which one it was, though. i think it's the build 9704, since it's the earliest beta setup i have.

If the torrents are all started/queued, it checks if they all exist on startup, iirc.

hmm nope they are almost all completed.. could it be that it checks those too? and if it does, how can i disable it?

It doesn't check the files themselves, just if they exist.

even the completed ones? and i mean completed, not queued or waiting to seed..

even if it only checks if they exist they are a lot of files, no wonder it takes so much time. is there a way to disable this feature? i mean, when i want to know if they exist, i'll check myself.

The presence-checking of files doesn't take long, and certainly not the length of time you describe.

Avira Antivir is your antivirus?

Does the problem persist with it temporarily disabled or uninstalled?

yes, it's my antivirus, and disabling it doesn't help.

btw here's what happens: i execute utorrent, and in the task manager i see it in the process list, gaining memory veeeeery slowly, sometimes freezing on the same amount for a while. in the end, as soon as it reaches around 62-65MB, it loads. this takes approx. 5 minutes though!

isn't there a way to disable these kind of checks or just a way to see what it actually does at startup?

process monitor is probably the best thing to monitor that.

ok i downloaded process monitor. basically it does the same operation for EVERY file, completed or not, which consists in:

Create File

QueryStandardInformationFile

Read File

Close file

now, i have approx. 1500 completed files and 20ish more in the download list (not in download, just in the list)

so that makes approx. ~6k events right?

problem is, there are like ~50k events total. and they are all the same: the aforementioned 4 operations, only these times the destination path is not the torrents in my roaming path, but C:\ or G:\ (the two partitions on my hard disk)

i really don't understand..

but besides the difference in the number of events, why does it even do these checks on the files? and isn't there a way to disable them?

It does the checks because you have the torrents started... It HAS to check if the files exist to start the torrent. You can stop them all and the next startup will probably be a lot faster.

but that's the point, they are NOT started! they are almost all completed! in fact, i tried to do what you said just to be sure, and it obviously didn't change anything.. what i'd like to know is, what do those operations in the process monitor mean? and why does it do them on every file on the list, regardless of their status?

So the torrents are STOPPED in the client, then? When I had a huge amount of torrents (about 2k?) it took about a minute to start, but if I closed and immediately reloaded it usually only took a few seconds.

yeah right now i have like 3 active torrents and 1 in queue, all the others are stopped - completed and incomplete alike.

and it takes 5 minutes even if i immediately reload the client. while 1.7.7 took a few seconds everytime.

When you have torrents uTorrent MUST check the handles for each load. I.e. windows reading the files. Watch your Process Explorer Handle list when opening 1.7 vs 1.8.

so.. littlefire, you're right. i put back Ut 1.7 and apparently it does mostly the same thing. only differences, it takes 4 seconds instead of 5 minutes, and it doesn't do those operations i talked about earlier where the destination path is C:\ or G:\. and it does ~30k operations total.

so.. any other guesses? any idea about how to resolve my problem? why is 1.8 so slow?

Would you mind sending me your .dat files and the .torrents? Just zip up "C:\Documents and Settings\username\Application Data\uTorrent".

I have the same problem with the new release of uTorrent

My computer for uTorrent is Celeron 600 (512 MB RAM), so it longs 10 minutes to get started...

I've monitored the starting of uTorrent with FileMon from SysInternals. There are 10 minutes long NO file actions!

The most of my downloads are in some folder on the disc M. But the most messages are:

....

OPEN M:\

QUERY INFORMATION M:\

CLOSE M:\

OPEN M:\

QUERY INFORMATION M:\

CLOSE M:\

....

But than in few seconds I get my uTorrent.

If I downgrade to 1.7.7, there are no problems at all.

Hope you can suggest, what I could monitor to know where is the problem. Is there meanwhile Linux's strace for Windows, so that one could see what was the last call before these 10 minute delay?

Do the same thing alus asked for, please.

so, i tried every alpha trying to locate the problem. I also already told alus, but i thought maybe it could help saying it here too: the problem starts with alpha 7429. i guess the problem is "flush write files if download is complete"? i don't know, it seems like the only thing somehow related.

If your downloads are completed and you dont plan to seed anymore.

Why dont u just remove them from the list.

Should clear up the list itself.

This delay with start I encounter also in uTorrent 1.7.7 IF I have NOT STOPPED the seeds/downloads in shared (throw Linux samba) folders on another computer and I have not yet entered a password to get access to this folder. So windows explorer asks this password for the first time (and it will be remebered for the whole windows session) but uTorrent doesn't do this and hangs for 10 minutes!

The same if I will change the download location and the network path doesn't exist anymore, I also have to wait while this timeout.

So I can assume 1.8 try to check even my stopped downloads (with broken networks paths). Maybe there is any chance to change this behaivor of uTorrent? I mean the handle of timeouts with broken paths.