masca90020

The same. This happens with big files over 6-7 GB in size. LE: Tried another client - not gonna give names - and I can download with no issues at speeds of 70+ MB/s. So it's not entirely only Windows' fault. I believe to think that windows has no issues with the cache system. So my question now is, if it's possible with other clients, why isn't it possible with uTorrent ?

I recently got a gbit connection. And the troubles began: disk overloaded ( with 100 mbit connection the cache is used, but with the gbit connection it's...), windows ran out of memory, pc freezes etc. I'm using Windows 8.1 x64 and uTorrent 3.3.2 build 30260.I'm starting to hate these memory leaks.

Feature temporarily canceled... Thanks for the answer. Thought it was a bug. But why cancel such a feature ? it was kinda useful.

You choose a label and utorrent moves the file from the default download folder to the folder you tell it to by selecting that label.

The labels are also broken it seems. It moves the torrent but not in the file I tell it to. Same labels I've been using for years and same settings.

So, I only have one question: are the I/O problems adressed ? Or uTorrent will forever be damned to disk overload and RAM hogging ?

How can you tell? did you enable logging for incoming connections? what did you see on help->show-stats if you delete all trackers and enable DHT' date=' having peers in your list?[/quote'] I don't use public trackers => I don't need DHT. I saw it pretty simple. While the update interval was active, no peer was connecting to me. When I manually updated the tracker, the upload started with 10 mb/s. This occured 10 times in a row => it's not a coincidence. Anyway, staying to 2.2.1 until it will go off the internet. I think there's a setting that does this, but I don't have time to start and test every variation. This behavior occurs with the standard settings.

Tried 3.2 after I reverted to 2.2.1 and I'm sad to see that I have the same issue that I had since version 3.1 stable hit. Peers won't connect between tracker updates => I can't have a decent ratio. 2.2.1 and 3.0 worked like a charm and 3.1 until 3.2 are acting up. Tried 1000000000 settings and even trid with the default ones. The same. If the tracker does not update, there's no peer connecting to me. And yes, it's allowed in the firewall and in the antivirus.

Thanks. It worked. No disk overload on that torrent anymore.

My disk overloaded issues are now gone. The only thing I did different is that I didn't install any apps. LE: Nvm, the issue isn't gone, it still occurs with large torrents that have lots of files. It just doesn't write to disk. You have my printscreens. But there seems that a workaround is possible. When you have large torrents, follow the disk statistics and don't wait for the cache to fill up. Stop the torrent and let the cache clear. Then start the torrent again. This fixed the disk overloaded for this particular torrent. It has 10 seasons in it, every season has ~23 episodes. I only selected 46 episodes ( 2 seasons ) and I skipped the rest. Maybe it will help if you see that a stop - start fixed the issue.

I've tried every combination possible. When you have a bigger torrent it's instant disk overloaded. That's it, I'm going back to 2.0.4 or 2.2.1 until these bugs are sorted out. I don't know how someone can repair these issues in 3.0.1 and break them all over again in 3.1.2.

At 7 kb/s you'll never see disk overloaded. We download with 10+ mb/s.

I was talking about build 26749. 26746 didn't have this issue. I even tried 1024 mb cache. It fills up. This is what happens. It doesn't write to file. The build before this had no such issue. And these are my cache settings: I've used the same settings since I've started using uTorrent, a loooooooooooong time ago.

This latest version sucks. I get disk overloaded, just like the one before last. Do you on purpose mess uTorrent up ? And yeah, I know how to set up the cache options. Until this build and the one before last I didn't have any problems with disk overloaded.

uTorrent isn't banned, just the torrent file created with it because of many complaints from people that use rTorrent on their seedboxes. There's now a stalemate, none of the developers wanting to modify their client to suit the other client's needs. You don't want to remove those fields, they don't want to ignore the fields and the users are caught in the middle. Over 90% of home users use uTorrent and over 90% of seedbox owners have rTorrent. I think that there is time for a compromise, be the bigger man kind of thing and think who is gonna suffer from these decisions. The developers couldn't care less, the tracker owners as well and there are the users that can't use their favorite client. Anyway, I'm hoping that you'll understand what I wanted to say and this will be my last post regarding this matter.

That's true. This issue can easily be fixed but most of the trackers do not accept 3.1x torrent files because other torrent clients can't handle or ignore these new fields. I really don't know why the staff here doesn't understand that those fields are useless and return to the old format. The RSS Downloader is still bugged and the update of the RSS feeds still cause mini-hangs. One would think that these bugs can be easily fixed or . Your words, not mine.

It didn't work.

It's a great thing that you got back the option to hide the sidebar. I like it very much to be able to hide it. I missed that in 3.1 after I've used it in 3.0. Another thing: I've sent that RSS feed a long time ago and the RSS feed support is still the same. Mini-hangs are present every time the client updates that particular feed.

Sent it to Firon. Now let's see if something happens. LE: I want to mention that I tested it both with https and http.

I can provide the example feed, but it's from a private tracker and it contains all my data inside. I could provide it to a support e-mail if the devs want to. The feed is correct.

Is there any chance for the RSS component to be rolled back to 2.2.1 code ? I'm tired of mini-hangs when adding some feeds that used to work fine until 3.1.

The problem is in tbdev, because tbdev does not accept negative values inside a torrent file. File-media sometimes contain negative values, like here: So, the trackers should fix this. Post on their forums. I did the same and they fixed the problem on the trackers I use.

Private trackers do not accept this kind of torrent files. They have more information inside them than a normal torrent file until date and that's an issue for many trackers.

Yes, that's what I want to say. Created the torrent file 10 times and then created another ten different torrent files and the result is the same. No tracker accepts them with this error. I compared them with the ones made with 2.2.1 for example, and they have some differences that may be to blame for this behavior. uTorrent opens them fine, but you can't use them outside uTorrent by uploading to a tracker.

I've created two' date=' with no issues. But I'll try a third one...[/quote']I reported the bug earlier and you confirmed it. ( not a bencoded file bug ) LE: Let me be clear about this issue. No tracker accepts the torrent file created with the latest build of utorrent 3.1. This wasn't an issue until this latest build.