utorrent vs azureus

[TheDude]

After a couple of years as a major alpha tester for two variants of ABC, followed by several years using utorrent, I recently tried Azureus.

Previously, the "use of more system resources" would have bothered me, but now I have a wireless router and several cheap used laptops to use for web surfing and email, so my desktop PC can be devoted mostly to BT anyways.

Also, I have been getting annoyed by utorrent crashing every so often, with no option to automatically restart, and so I decided to give "AZ" a try. (NOTE: I have done thorough checks of memory and hard drives, and there are no hardware problems.)

I have previously used another unrelated Java program, and have had Java JRE crash regularly, but I thought that was due to poor design in that program.

But, I experienced the same problem with Azureus - like the other program, it would simply "disappear" (and I am not running any of the programs on the "Azureus disappears" troubleshooting list). Reading the Java Forums, it seems like this is a common problem.

So, I'm back to utorrent (the Az crashes were far more frequent), and the experience allowed me to offer the following points:

Azureus advantages:

- Plugin system allows development of features for special interest groups (main program developers cannot spend their time adding features for only a small number of users).

- Schedule plugin allows more than two different sets of speeds (for example, overnight I want unlimited speeds, plus I need a "light use" limit that allows one person to browse or watch Youtube, and then a third "heavy use" limit that allows more than one person to browse (typically in the early evening).

- Category plugin that assigns category automatically by tracker URL.

- Different Up and Down speeds per category.

- Plugin with different seeding options per category.

- Automatic force re-check option after finishing download. (Utorrent claims that this only is needed by those with "hardware problems", but this is not true. It's possible that fragmentation causes it, but that is not a "hardware problem", since every drive has fragmentation, just some more than others.)

utorrent advantages:

- High, Normal and Low Priority for files in a torrent (while Az only has High and Normal, with not much difference between the two). This allows setting one file at "High" and the rest "Low", ensuring that you get one file that you can use, while the others are downloading.

- High, Normal and Low Bandwidth. This is the utorrent feature that I missed the most while using Az. This allows setting a particular torrent on "High" that you really want as soon as possible, while setting other torrents on "Low" so that they don't slow down the important one. (This setup is needed when the important torrent is not going fast enough to use one's entire download bandwidth.) I also use this setting to give better upload speed when seeding on sites where I am short of "ratio", and less upload bandwidth of sites where I have a very good "ratio".

What is needed:

- A better "per category" implementation than is found in either program. Many BT users use different sites, each of which keep statistics for each user, and require a certain "ratio" over all use of the site.

But the BT programs are still all designed as if every torrent were totally separate, and that the user wants to seed to "1.0" on each torrent individually. Not only is this impossible when a user joins a torrent very late, but also, it is not how things work on sites that keep "per user" statistics.

So, utorrent needs to develop a "per category" system that recognizes that the user may want to seed more on sites where he has an 0.5 ratio and less on sites where he has a 2.0 ratio. (This system should allow the user to choose which categories he wants to favor, rather than imposing a mathematical scheme - as is currently done with seeding.)

[Ultima]

Indeed, per-label/category options (and the power that would be unlocked with it) is probably the most widely requested feature for µTorrent. Like, ever

Whether it should automatically detect it based on trackers is a different story (something I would disagree with), but whatever, that's besides the point (and I'm not even sure it's something you pointed it out ).

[jewelisheaven]

Thanks for the overview. I would like to point out... corrections however

For your Azureus advantages it appears you are expanding your first point (which is acknowledged in the FAQ http://utorrent.com/faq.php#Does_.C2.B5Torrent_have_a_plugin_system.3F) a bit too much. Yes Azureus has plugins, but they are not supported by the azureus development team because they are external.

[ul][li]- Automatic force re-check option after finishing download. (Utorrent claims that this only is needed by those with "hardware problems", but this is not true. It's possible that fragmentation causes it, but that is not a "hardware problem", since every drive has fragmentation, just some more than others.)[/li][/ul]... Rechecking IS NEEDED only in hardware problem cases. If there isn't a problem why would you need to verify data on the hard drive. Especially in your fragmentation example... if there are no bad sectors the only inconvenience experienced while reading the file is stuttering (not hashfails of the different pieces due to bad sectors).

[ul][li]- High, Normal and Low Priority for files ...ensuring that you get one file that you can use, while the others are downloading.[/li][/ul]It does not ensure... it tries to PRIORITIZE. It is very true that when you setup say 12 files at different levels (1 on High, 4 on Normal, 7 on Low) the files in the same level will stay at approximately the same completed % but as expressed in individual posts on the forum over the years, it is not a linear but an exponential progression. If the pieces for your High file are common enough it may be that your Normal level files gain a whole 6% before you get that last 1% for your High file.

[ul][li]- High, Normal and Low Bandwidth.[/li][/ul]It is indeed useful but I have never found it highly useful. If the peers are slow on High (I'll use your private tracker example), and Low peers (a more common public tracker) are faster, the Low priority torrent will still get more of your bandwidth.

For your "What is needed" §, search for "per label" on the forum. It is and has been on the to-do. Unfortunately there are more important things to consider than power-user functions. Reading through the pages of the 1.8 development thread show the gamut of users: from people who have never used a label, people who never even SHOW the category pane, people (like me) who shove all of the torrents on their hard drive at it to see if I can make it stutter, people who still use it happily on windows 98, and people who want the experience to be the same on Vista.

I would also like to thank you for pointing out the fact that two of the most popular clients for the bittorrent protocol crash. Anyone who claims their software is bug-free is lying or deluded. I am a bit saddened that you are unable to get rid of the crashing with uT... but it is a sign of incompatible software.

My personal view on http://forum.utorrent.com/viewtopic.php?pid=283607#p283607 is that your incompatible software includes an indexer or some other file which edits the file's tags (which will of course cause the offending piece to hashfail upon further checking).

[TheDude]

- Automatic force re-check option after finishing download. (Utorrent claims that this only is needed by those with "hardware problems", but this is not true. It's possible that fragmentation causes it, but that is not a "hardware problem", since every drive has fragmentation, just some more than others.)

... Rechecking IS NEEDED only in hardware problem cases. If there isn't a problem why would you need to verify data on the hard drive. Especially in your fragmentation example... if there are no bad sectors the only inconvenience experienced while reading the file is stuttering (not hashfails of the different pieces due to bad sectors).

I don't think that is true.

It is not a hardware problem, it is a problem either with false reporting of completion, or it is a problem with writing to disk.

As I mentioned, if it were a hardware problem, then if one checked older torrents, they too would sometimes show less than 100%.

But, it only happens when the torrent first completes (and it only happens with large multiple-gigabyte torrents), so it seems clear that it has something to do with utorrent's method of "finishing" and/or Windows disk writing, and/or the combination of the two. I am not a "low level" guy, so I can't offer a more specific explanation.

PS I am not running an "indexer", nor anything which modifies "tags". In fact, I have a hard drive that is only used for BT, it is relatively new, and no program other than utorrent accesses that drive (except for manual file copies from that drive to my HT-PC over the network).

[ajones81]

Good analysis, and yes, we're all waiting for per-label options for a long time indeed!

As for your issue, care to post HijackThis/ProcessExplorer logs here?

[TheDude]

I do regular spyware checks...

[jewelisheaven]

Incompatible software is many times unrelated to "spyware". If you have already made a thread about your troubles a link to it will suffice, I couldn't find one.. I only found your un-answered thread to be relevant to the discussion. If you don't want help with your problem say so... ajones was offering assistance.

[Lord Alderaan]

- Automatic force re-check option after finishing download. (Utorrent claims that this only is needed by those with "hardware problems", but this is not true. It's possible that fragmentation causes it, but that is not a "hardware problem", since every drive has fragmentation, just some more than others.)

The claim is simply this: If a piece somehow got corrupted after it was completed (and hash-checked) it means it was because of your hardware/software. Re-checking is futile because the download could become corrupted again a second after you finish the automatic re-checking on completion. Why bother all the µtorrent users with a useless CPU & DiskRead intensive process.

Why even code an option for it into µtorrent? When one IS experiencing these kind of problems one should solve them not just treat the symptoms... Because de facto creating a 're-check on completion' feature gives users experiencing these problems the false idea that the feature helps them solve the problem...

Fragmentation isn't corruption (and it doesn't cause it either). Fragmentation isn't an 'incident'. It's an unavoidable side effect of the way file systems handle writing data and could almost be called intended behavior.

[The8472]

- High, Normal and Low Bandwidth. This is the utorrent feature that I missed the most while using Az. This allows setting a particular torrent on "High" that you really want as soon as possible, while setting other torrents on "Low" so that they don't slow down the important one.

Actually, such a feature is available in Azureus since version 3.0.4.0, it only kicks in if the user-set global download speed limit has been reached (since there's still free capacity if the limit isn't reached).

And btw... most java-crashes can be solved if you provide crash logs to us (Az devs), the causes usually are easy to identify.

[ICleolion]

Hmm, if i remember rightly uT's Bandwidth priority only affects upload speed. So the feature you describe The8472 isn't the same as what uTorrent has.

[TheDude]

Those who have read the other thread keeping missing these points:

- When the so-called "completed" torrent hash-checks at 99%, it only does so the first time. When the torrent is restarted, and reaches 100%, it has never ever gone back to 99.9%.

- Old torrents, such as those that I have been seeding for months, do not go to 99%.

- Smaller torrents never have this problem, only multiple-gigabyte torrents.

If it were a hardware error and/or data corruption, then any data on the disk would go to 99%.

Since only just completed torrents show as 99% when hash checked, then only one of two possibilities:

- utorrent is not accurately gauging "completion". (This is my best guess as to the cause)

OR

- the disk cache is not correctly writing the final pieces to disk.

Note that many other people have reported the same problem in these Forums. The fact that Azureus has this feature means that many people have reported the problem there too.

The difference is that Az created the feature while utorrent people constantly repeat "it's your hardware".

I don't know how many times over the past 10 years, I have had my Internet connection drop to zero or disconnect entirely, and the conversation goes like this:

Me: " My internet connection has died. Have you had any reports of problems? "

ISP Phone Rep: " What Operating System are you using ? "

ISP Phone Rep: " Please delete all your cookies and all your Temporary Internet Files "

and on and on ...

In contrast, when my power goes out, the Utility Phone Rep never says:

" When is the last time that you had your house electrical system checked ? "

But anything with regards to PCs is considered to be a user problem. If you look at the PC support newsgroups, most of the posts are:

" Have your run a spyware checker lately ? "

in response to everything...

PS: Actually when I switched to DSL a couple of years ago, I stopped having Internet problems, but the example definitely applies to all my ISPs before that...

Miscellaneous:

As I mentioned, the hard drive in question is only accessed by utorrent. To confirm this, I just did a Handle search in Process Explorer for just the drive name ( " M: " ) and every result was utorrent.

(The same was true for Azureus when I was running that instead, of course.)

And, the Azureus " hash check after completion " option was not added in 3.0.4.0, because it is present in 2.0.5.4 ...

[ajones81]

Note that many other people have reported the same problem in these Forums.

Have to be honest with you - haven't seen any reports lately of people facing non-completion only the first time round as you say you are.

Lots of people (including me) download huge torrents regularly - no such problems yet. Hate to break it to you, but it does indeed sound like a hardware problem. Either that, or some extremely rare bug that's showing up only due to the unique environment of your system.

Also, instead of arguing needlessly, what problem do you have with posting the requested logs? I'm not saying something will turn up, but it might. So either provide the requested info. or else if you do think it's a bug, provide the devs with crash dumps or some way they can reliably duplicate the problem. If you can't do that, then no use posting repeatedly, is there, 'cos no one can help you.

P.S. Have you checked your hardware lately? Thoroughly. Run a full surface scan and also, Memtest86+ overnight.

P.P.S. What version of uTorrent are you using and on which OS? Have you messed with the advanced disk cache settings at all?

[TheDude]

Thoroughly. Run a full surface scan and also, Memtest86+ overnight.

.... which is the same as ....

Please delete all your cookies and all your Temporary Internet Files

..... and ....

Have your run a spyware scan lately ?

and you know:

- Over the past 15 years, I never fixed one problem by deleting cookies or Temporary Internet Files

- I've never turned up anything in a spyware scan (despite running two major programs)

- I've never had memtest86 or memtest86+ ever show an error

Concerning surface scans:

While I have had those detect bad sectors in the past, I have never had that occur with any disk that was not used for BT (which is why I use a separate disk for BT, which is used for nothing else).

Also, every detection of bad sectors was preceded by obvious symptoms - such as utorrent freezing in the middle of a hash check of the file that had the bad sector.

But, in any event, I did check my hardware recently just to make sure that the Java problems (which happened with another program besides Azureus) were not due to hardware. So, I've been conditioned also. :-)

Lots of people (including me) download huge torrents regularly - no such problems yet.

The faulty logic here is "if only a minority of people have a problem with a program, then it must be due to hardware".

An easy counter-argument is that only a minority of people are using a specific setting in the program.

There is also the factor that people tend to report only those problems that prevent them from accomplishing their purpose. Having to manually hash check every torrent after completion would just become a normal chore that would not be reported.

Even more likely is that the 99.9% but "completed" torrent is automatically moved to another folder where it is ends up being played back causing an audio or video glitch, which the user attributes to an error by the uploader or encoder - never realizing that the torrent didn't really fully complete. And so not reported.

If you don't want help with your problem say so... ajones was offering assistance.

Offering assistance is commendable, but in neither thread have I asked for help with a problem, rather I have asked for a feature.

[ajones81]

FYI, non-completion of torrents and failing hash-checks without reason, even once, is NOT a feature request, it's a bug report, and a serious one at that (if indeed uTorrent is at fault, which I'm not too convinced of right now). Why don't you post in the Feature Requests section then, eh?

You obviously seem to be competent enough () to solve your own problems, so I won't bother to post here anymore. Have a nice day.

[remeark]

You forgot the biggest advantage of Azureus: open source code.

[jewelisheaven]

That's not an advantage. BitTorrent is a brand (or don't you see the TM next to their logos and other site paraphernalia) and as such must be protected. Keeping the previous decision of uTorrent's closed-source nature when BitTorrent, Inc. bought it didn't change anything, and it is still as secure as ever. (Do some research on why build 488 wasn't the last 1.6 stable)

I think you're getting at the fact you're still wanting uT to implement a plugin feature though.

[Firon]

Fragmentation cannot cause corrupted files, just fyi.

[amc1]

Well... not going to bother replying to all of this (who cares about my opinion anyway ), but...

Azureus crashes are usually to do with the Java VM clashing with some other program. Nothing that we can do in Azureus anyyway.

But the BT programs are still all designed as if every torrent were totally separate, and that the user wants to seed to "1.0" on each torrent individually.

There is a plugin which can do this sort of thing in Azureus.

But I don't necessarily blame BT programs not catering for "torrent sites" - there's a lot of things regarding private torrent sites which I dislike (especially one which are strict at enforcing a global ratio).

You forgot the biggest advantage of Azureus: open source code.

That's not an advantage. BitTorrent is a brand (or don't you see the TM next to their logos and other site paraphernalia) and as such must be protected.

The two things are completely different. Open source is an advantage - for example, I wouldn't have become an Azureus dev if I didn't have it wasn't open source. Same with other people.

Registering a trademark is not the same thing as it being closed source either.

[Firon]

Open source has its benefits, and I wouldn't mind µTorrent being open source. But the debate between the two won't stop me from using one over the other.

[TheDude]

UPDATE:

I just remembered another really helpful Azureus feature.

utorrent does have an advanced setting that:

queue.dont_count_slow_dl: Enabling this option tells µTorrent to ignore slow downloading torrent jobs as part of the queue. If a torrent job is downloading at less than 1 KiB/s, it will not prevent the next item in the queue from starting.

But the big addition in Azureus is that it allows you to set the threshold of speed, below which it is not counted.

Why is this so helpful ?

I am constantly in a situation where I have one torrent that I want sooner than any other - so I want to set the Queue to " 1 " so that the torrent is not slowed down by having a second.

However, the next torrent in the queue may be one with few seeds that are slow, and may only use a fraction of my download capacity.

So, the action that is needed is:

- Only download the important torrent and no other (to get it as soon as possible), and then

- When that download is finished, download more than one torrent if necessary to use maximum download capacity.

The simple way to do that is:

- Keep the queue at " 1 "

- Instead of having queue.dont_count_slow_dl threshold be 1 kb/sec, allow the user to set it, so that they can optionally set it at something higher, so that a second download would be started.

Azureus does allow the user to set that.

However, even better would be four simple options:

queue.start.dl.below.max = true

queue.start.ul.below.max = true

queue.start.dl.threshold.percent = 70

queue.start.ul.threshold.percent = 90

where utorrent would start the next queued download (or upload) if the download speed (or upload speed) fell below 70% (or 90% default for upload)

using the "number of torrents" to determine queueing misses the point of queueing altogether.

[jewelisheaven]

And if you kept updated on people's request you would see that specific request was rejected/denied/trashed not even a week ago. http://forum.utorrent.com/viewtopic.php?id=34359

[Firon]

Hm. I could've sworn I'd put that feature on the todo, but I looked today and I couldn't find it... It's on it now, though.

[TheDude]

And if you kept updated on people's request you would see that specific request was rejected/denied/trashed not even a week ago. http://forum.utorrent.com/viewtopic.php?id=34359

That thread does not have any rejection or denying at all (and nor does the one linked in that thread, either)...

[Ultima]

Right... If you (anyone in general) don't have anything to add regarding the comparison between µTorrent and Azureus, you'd best stop adding to the off-topic discussions. The thread is straying off from where it started, so let's try to keep it on track.

[TheDude]

A further data point (on why Azureus has a "re-check after completion" option).

This morning, a 35 gb torrent of 24 files finished in utorrent - ("complete"). I then did a force re-check, and it came up as 99.9% complete - the very last file that finished, was 99.7% complete. Note that files that complete while the torrent is still incomplete, are finished to 100.0%.

No other torrent for the past few months has done this.

The fact that Azureus has a check-upon-completion option, indicates that they recognize that this is a condition that occurs from time to time, as a simple result of the way BT and BT cleints work (and/or maybe a result of the way Windows works).