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

[doug2h]

Still get disk overload with 18518. Got it with 18429 also. After about 30 min or so all speed die to about 1-2k disk overload 100%. All default settings so all changes happen with update.

Back to 18304 for now. Thanks for the great work.

[420]

What does the "v" flag mean? I saw it briefly when connecting to some seeds on a torrent.

I would very much appreciate if someone could point me to a complete list of flags and their meanings. The list you have in the FAQ and in the help file is incomplete.

"A picture is worth a thousand words"

[nso]

@doug2h

Oops, there is change in caching happened. Whole pieces go in the cache now.

But 6.43GB From File vs 142MB From Cache at your picture looks like extremely inefficient caching of reads (it almost does not work at all) while 4.00MB of 1.00MB and 3.91GB(!) of 32MB looks like а bug.

You should specify cache size manually (could be ~max_ul_speed * 100second enough as before 2.1) and disable Windows caching of reads.

@All

What does discio.resume_min mean?

@devs

I have many torrents gray at µT start for long time to grew old, this is 1st reason not using queueing.

Torrents don't start according 'Last Active' column, that buries queueing for me.

@420

You can still disable Windows caching. It spoils at quick ul/dl. You can even disable all the caching of reads, disk still remains cashing.

[420]

Nothing we can do to fix the cache problem. Setting cache size manually doesn't help. It's a problem that started between builds 18304 - 18429.

So, basically, the most recently released builds (18429 & 18518) are completely useless for downloading.

Hope this is fixed in the next build.

For now, anyone using these defective builds should downgrade back to 18304.

[Dim_on]

Question: are You going to do something similar, if so when?

[signe]

@doug2h - I'm seeing the same thing. Read cache never grows beyond 1 M, but the use fluctuates between 0 and 4M.

Write cache was sitting at >3G out of 32M.

When I disable write caching, the read cache suddenly starts to grow, as it should have been all along. Up to 18M and increasing slowly as it needs it.

I think the two issues are linked, obviously...

[stijnkoppelmans]

The write caching works for me. It's just the progress bar that's always full and the 3xx GB size. The actual caching works though.

I am having issues with the built-in speed test though. It'll say it's checking queue and then tell me the place in queue, but it'll stay in that placein queue forever.

So even when in place 1 in queue, I'll be there for 5-10 minuten without anything happening.

[Archlinux]

You'll probably wanna use the most recent emulation option, honestly. A lot of compatibility stuff is there for older OSes.

That never even crossed my mind, which makes me feel quite dumb. I take it there's not much of a difference with using e.g. xp and win 7 emulations, though?

[Firon]

We do a few small things different on OSes newer than XP, but there's probably gonna be little visible difference between XP and 7 compatibility while running on Wine.

[signe]

Disabling write caching does resolve the "torrents all eventually drop to sub-1kbps transfer rates" issue. Couldn't tell you why.

[Hyosung]

Minor, but any plans on fixing the issue brought up by post #379

"Last version doesn't remember its windows size after restart. It also ignores existing custom Main.ico."

Thanks.

[toph]

usability regression in alpha 18581 and [can't tell how long before - was ok in 1.8.5] — now it's impossible to launch an incomplete file (!ut added) via doubleclicking in Files pane, which is a disaster for video since any player plays such videos, for example to check picture quality after downloading a few MB (prioiritize first/last enabled)

[Firon]

This is intentional. We lock all files while downloading now to avoid other applications modifying them while we are still downloading. Furthermore, we no longer close file handles every 2 minutes to avoid other applications stealing our file handles (this is the cause of the dreaded access denied error) and only close the file when we haven't used it in a few minutes.

You could just use the new streaming feature in 2.1 instead of trying to preview it the way you're doing.

[toph]

:-D Firon, that seems funny, sorry...

1. I can still open the video file directly (from Explorer) without any problems for uTorrent

2. uTorrent can lock for shared writes and still open file without troubles

so you've just introduced an awkward UI handicap to be circumvented via scripters like e.g. AutoHotkey.

[Firon]

Oh, wait, you're talking about something different, not the file access change.

Yeah, it no longer lets you open incomplete files from the UI, but that change was made a LONG time ago. For 99.9% of the users, it doesn't make sense to allow that.

Just stream it if you wanna preview it. That's why the function exists.

[toph]

for 99.9% users _I_ know it makes uTorrent awkward... moreover it doesn't help a bit internally or so it seems judging by your info. As a wellknown wisdom says - if something works don't change it. Anyways it seems that uTorrent has already peaked in 1.85 or so.

[Firon]

A downloading app shouldn't really let you open an incomplete file through normal means. It's just not the expected behavior.

[toph]

whatever makes you happy and thank you for your excellent app.

[bugmenot2]

Since i think version 18429, I have observed a significant memory leak. While the Task Manager reported usage is around 20 MB as before, my actual RAM usage will increase by around a GB while running for about 30-45 minutes. Over longer periods, the usage increases proportionately. When closed, the usage drops almost immediately. I am only seeding about 10 files. This makes it almost impossible to seed for any period of time without constant observation.

Running Win7 x64.

[acmodeu]

I'm experiencing exactly the same thing!

[vnicolici]

Problems experienced with version 18429:

- 100% of one cpu core used all the time

Problems experienced with version 18518:

- 100% of one cpu core used all the time

- disk overloaded message and poor download speed a few times a day, but the hdd is actually idle. Only solved by restarting the application.

Problems experienced with version 18581:

- 100% of one cpu core used all the time

- Crash when attempting to stream the video to vlc while downloading it. I can provide the crash dumps created by uTorrent, and a dump created manually from task manager after it crashed and was asking me if I want to send a crash report.

- Not sending the crash reports to the developers when asked: "HttpSendRequest failed".

- Freeze when attempting to stream the video to vlc while downloading it. I created a crash dump of the frozen application, I can provide it if needed.

[fixxxer]

Hi everybody!

Does anyone work with Falcon? Every time from the begininng of this feature I receive the following trying to connect:

Of course I have been invited and already created the account (even two accounts) but I cannot neither use them in uTorrent (last 2.1.18581) nor log in Falcon Home.

So is it working at all?

[fkro]

a new bug i noticed in 18581

- when i delete a completed torrent from the list.. then the entire list disappers and i have to press All again to get it back

[moryoav]

bug in 18581: if you select "Set Download Location" under "Advanced" while the file is still downloading messes up everything. The file stays in it's original location and doesn't move, when you then stop the download and physically move the torrent to wherever you want it then the downloading restarts from 0.

[DreadWingKnight]

Moryoav, you assume that uTorrent is supposed to move the files for you when you do that, don't you?

Well it doesn't.

Stop the torrent

Move the files

Set the download location

Force a re-check to verify the set download location worked right

Start the torrent