wyrmchild

Causes piece availability to be front heavy, but shouldn't cause problems if the client doesn't insist on the order. Of course, best piece availability would be to the front as well. The protocol itself doesn't prohibit this kind of behaviour, but is discouraged as Firon said. The only real flaw with this is that the bandwidth isn't distributed across the peers since with this any peer can fulfill any (sequential) request. Also takes longer to have other full seeds out there since the likelyhood of one peer staying to seed after finishing isn't that high (a good majority just drop out soon after receiving the whole thing in public trackers), so this is where it harms the swarm.

The only thing that executable compression prevents is for multiple processes of the same app from sharing parts of the memory (program _code_ and (static) const data only, afaik). So there's nothing really lost with uTorrent since you're always running only one instance of it. And the O/S is as capable of swapping "unused" parts of the program out of RAM (to swap) as with unpacked executables. So, in the end, the only thing you'd gain from having unpacked exe is the start-up speed (because there'd be no decompression needed). Edit: Plase note, the same thing happens if you use NTFS's file compression on an executable or DLL. I have to agree with the why part though. I like regular unpacked executables much more, even though there's usually nothing gained from having them

I don't think handshake completion should be in error log as it now is.

No probs with RC2 so far. @seika They don't increment the build numbers just for fun or 1337 factor

Beta 2936 seems to be running smoothly.

uTorrent b2922 occasionally crashes (hangs indefinitely, to be more precise) when clicking on a torrent in the client for me too. Seems to occur most often when the files tab is open. The crashes occur in a minute or so of starting if I idly click at the downloads (seems to occur only after it manages to connect to peers). Anyways, having the files tab open is the surest bet to get the crash to occur. Crash dumps: http://www.savefile.com/files/842728

@DreadWingKnight "Running that many torrents at a time will cause some to run at less than 1kbyte/sec. Torrents that are running at less than 1kbyte/sec aren't counted towards queue counts." That _might_ be true (about the number of torrents) if my connection wasn't 5/5 mbit (also, upload slots set to 2 per torrent). But yeah, the option that controls that still is the reason (advanced: queue.dont_count_slow_ul). Can't help that other people have poor connections and just can't download fast enough

Nope, deleting settings.dat didn't help me, though I didn't expect it to, really I've set the "max active torrents" to 12, yet µTorrent insists on running around 28 instead. Doesn't really hurt me or my networking at all, but it's not doing what I tell it to Edit: Come to think of it, I've set the "use additional upload slots if blah-blah" on, so that must be it, right?

Deleting settings.dat seems to be the most common suggestion for fixing bugs.. so, would you by any chance implement some sort of hash checking for it at start-up? I'm pretty sure most instances of corruption would show up with that. Unless you actually change the format used with the betas Going to see if deleting it helps my current probs with the client (b2248)

@warpik The option is already there, just check preferences/bittorrent

I've not had any RSS re-downloading probs anywhere (notably, not in Tokyo Toshokan) :\ For clarification: [sHS] Darker than Black is in one of my filters, which was in Lucifer's downloads, too.

The spoofing warning from trackers is likely because the client is sending IP=#.#.#.# in query string to the tracker in announces and some trackers don't like it for some mystic reason, especially when the source IP is not the same (with NATs or transparent proxies this might be common). It's simply a problem with trackers that are set to some paranoid security level.

I'd like to have the RSS thing to have regexp matching too, and for the releases tab to show the original name rather than the parsed one (difficult to create good filters without looking at the RSS feed with something else). The parser currently discards a lot of useful information (at least, it is useful to me). (Edit: Probably the wrong place for requesting this, but since the RSS thing seems to be constant topic here...)

Here are the latest crash dumps: http://koti.mbnet.fi/ultima/uTorrent-1.7-beta-1703.7z

I just got empty error string ("Error:" and nothing else) instead of the out-of-disk-space error message it should've given from torrent auto-downloaded from RSS feed.