masca90020

Established Members
  • Content Count

    84
  • Joined

  • Days Won

    1

Posts posted by masca90020


  1. 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 ?

    3102248492.png


  2. 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.


  3. 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.

    Feature temporarily canceled...

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


  4. Peers won't connect between tracker updates =

    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.


  5. 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.


  6. 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.


  7. I was talking about build 26749. 26746 didn't have this issue.

    I even tried 1024 mb cache. It fills up.

    4NhYVs.jpg 4BsH4s.jpg

    This is what happens. It doesn't write to file. The build before this had no such issue.

    And these are my cache settings:

    UNPt0s.jpg I've used the same settings since I've started using uTorrent, a loooooooooooong time ago.


  8. Ignoring the new fields is proper behavior and does not cause the torrent to not work. There's no valid reason to reject the torrents based on them having these fields. If the client chokes for having those fields, THAT client should be banned for improper behavior, not uTorrent.

    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.


  9. Honestly, as a tracker software developer, torrent maker developer and support staff for uTorrent, those admins are idiots running outdated tracker packages.

    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

    those admins are idiots
    . Your words, not mine.

  10. 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.


  11. 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.


  12. With the latest version you can't even create a correct torrent file.
    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.