LeKing

Established Members
  • Content Count

    106
  • Joined

  • Last visited

Everything posted by LeKing

  1. About false positive : kis does not give false positive (on utorrent); why not using it ? norton gives false positive for all, all I mean, applications using udp protocol. Two years ago, it reached number one in a hit parade of anti-vir, in terms of quality, protecting the computer. I did not return to it ; I had many, many times be infected with it : norton is a bargain for hackers, you don't have to be very clever to defeat norton ; just place a java script which changes century value of your system time for about 30 seconds ; norton reacts as if subscription were expired, and totally ceases to function, even when time is restored. It is a feature implemented to defeat users who want to use norton without renewing their subscription...
  2. it was where I wanted, cause I use default path ; not difficult to find : you type %appdata%\utorrent in address bar of explorer. I do not use BEncode editor, maybe I should.
  3. It is far much quicker to rename a file, than to create an empty one ; using notepad, I could create a file.txt, then I should rename it file.dat. Two operations in place of one!!! What there in my settings? Many changes that I reverted to normal, except two check boxes : those I indicate : "apply rate limit to utp connections" and the other check box "add new upload slot if ul rate < 90% cap" Those settings are not reverted easily, cause no asterisk indicates where is default value...
  4. After many crashes, I took a look on downgrading to 2.2.1 ; crash at launch ! I deleted settings.dat, and then it recreated it with standard parameters ; functiunated awhile, but finished by a crash after many hours... I allowed it to upgrade to 29625, and with settings.dat of 2.2.1, it dl properly at high speeds !!! Unchecking "apply limit to utp" and "open new ul slot if ul < 90% cap" gives faster ramping for dl throttling, but very kamikaze... Now, I think I will leave those settings all the time!
  5. I experienced this trouble ; I got a longer wifi connection to utorrent putting up a wnr 2200 router at the rear of the netgear numericable 100Mbps ; and then I upgraded the netgear 100mbps provided by numericable with the LaBox 200mbps by numericable, and connection turn bad even more slow. The symptom is : LaBox functiuns pretty well just rebooted, then after several days ping returns more and more packets lost, getting dl rate ridiculous ! Iswitch off/on LaBox, and it resumes... With firmware upgraded on wnr2200, I have very rarely the need to reboot it (maybe twice or three times a year)! connection is set in wifi on the wnr2200, instead directly on cable modem routeur. Looks fuzzy putting a second routeur, but fortunately it does a quite fix (makes last longer).
  6. Message "older version running" indicates that a version of utorrent has been launched, which is different from this you want to run ; try to locate it with task manager, and rename it, or delete it .
  7. I guess not. There is something wich triggers off writing from cache to disk at high speeds. When you pause a torrent with scheduler or manually, resume get downloading, but not seeding : this means all finished torrents stop seeding. So there is this case where downloading is also impacted with the bug. Looks as if a threshold was reached in disk activity ; when downloading at highspeed, dl is not so high that my connection allows (32Mbps), only 1 500 KB/sec. Suddenly dl rate climbs to 2.9-3.1MB/Sec, and taking a look into pieces tab, plenty of full downloaded pieces are storing, appearing in light green ; task manager show utorrent.exe growing at the rythm of memory cache ; when utorrent.exe is 1 200 000k big, a "tung" yield out of the speakers, then utorrent.exe grows for ever fast to 1.6-1.7GB, and exits out of memory!!! (no crashdump generated...) When I say : dl not as high as it should be, downloading a torrent from 3 seedboxes, one of them topping at 60MB/Sec.
  8. In deeds, it is a more general bug : when a torrent is highlighted, you click on the left to select another view, and infos are shown about another torrent ; if you are dumb enough to delete it, it is not the torrent highlighted which is destroyed, but this with infos shown ; I never reported this bug, just because devs MUST have noticed it by themselves. ( bug present since 2.0.0, not present on 1.8.5, if I remember correctly )
  9. path is %appdata%\utorrent\updates that's all folks !
  10. "It's a long way to the top if you wanna rock'n'roll..." wow, updated successfully from 29579 ; it was for a long period that I was obliged to to it manually ! EDIT : and yes, tabs blank as reported .
  11. Probably you were using "c:\program files\utorrent\" to hold your settings, and now they are in "%appdata%\utorrent" ; so you got totally new settings.dat and resume.dat . A manual copy of resume.dat from old location to new location should fix the problem.
  12. 29544 broke a new record ; process utorrent.exe grown up to 1 738 960K in memory before crashing ; dl rate was only 960KB/Sec at that time, but a dozen of torrents downloading together on a local caviar green. Perfect disk could be a beginning of an explanation, but, it does not interact with the N.A.S, so, what was so wrong with it ? Kaspersky pure has to be investigate too... EDIT : no error message telling that crash dump failed to be sent ; was it successful ?!!
  13. Now I know why it was crashing all the time from some days : silent update ! Manual update solved the problem.
  14. I finally discovered which mechanism was crashing 3.3 at high dl speed ; downloading an iso of 39.4GB from three seedboxes, , dl rate was between 1.5MB/Sec and 3.3MB/Sec, so after a while, process utorrent.exe was reported to reached 1 500 062K by task manager, and bing, crash... Destination folder was on the N.A.S ; I decided this morning to try dl on a caviar green with 120 MB/Sec sustain stream, a local drive : good idea, task manager showed process culminating at 1 676 496K in main memory and no crash!!! I now use the local drive to DL and transfer folder for finished dl to move files to the N.A.S ; I hope a solution might be exist, cause downloading directly to N.A.S give security of RAID 6 mechanism. (creating the iso, such big, takes enough time in order to explode memory cache, before allocation processus is done !)
  15. I wonder wether fast mode for retrieving pieces functiuns normally or not : DL speed stuck at 1.2 MB/Sec, with UL= 47 KB/Sec + overhead = 65 KB/Sec ; UL capacity is 120 KB/Sec approximately. I found overhead too high for receiving pieces in high mode (high speed mode is built to drastically reduce amount of acknowledge...)
  16. Not specially appealing, but frustrating : unable to spot torrents which tracker are on error state !
  17. +1 ... (maybe it was intended)
  18. cache size must be high, and scheduler ought to be disabled... (in order to avoid infamous message !)
  19. Yeah, triggering of disk flushing works now ! But, resuming upload when scheduler had got into pause does not operate ; similar fixing should be done for outing from cache to web, or some other triggering, [F] Upload files are cut off for seeding as soon as scheduler get into pause ... Keep on rocking dudes !!! Edit : after awhile, manual pausing get into pieces not flushed to disk ; very weird ! P.S : resizing cache a higher value unleash the mechanism, how fool...
  20. sorry for the inconvenience, but writing routine from cache to disk has to be rewritten : a whole file of 300MB can stay prisoner into the cache, pieces in light green in piece tab, info tab reporting zero piece received ; it occurs with [F] Download mode, when scheduler puts microtorrent in pause ; when scheduler returns to normal, flushing to disk does not recover ! file stuck on indefinitely ! buffer overrun crashes microtorrent... :( By the way, this bug also leads to no seeding ; only trick : disabling scheduler till bug fixed !!!
  21. very strange in log : [2013-02-10 17:22:06] M_________________ - Dvdrip . XXX . Divx . French - XAVOUS: HTTP invalid URL: D:\Partage\M____________________- Dvdrip . XXX . Divx . French - XAVOUS/ actual path : \\DISKSTATION\Download\M_____________________- Dvdrip . XXX . Divx . French - XAVOUS nothing to do wiyh "D" unit... and "force check" stuck on this file ; another file stuck also on this target !
  22. buffer flush to disk fails continously at dl ; pieces tab show plenty pieces completed waiting into buffer ; problem seems to be correlated with dht nodes climbing to many thousands. msn wood burning screen saver facilitates the problem by consuming heavy cpu cycles... cable connection limitates dht growth ; dht bugs specifically with dsl connection ; lost data packets seem very bad managed !
  23. nodes in dht : 18383 ; disk overloaded with dl rate = 2.5KB/s !?? LOG : [2013-02-04 15:55:03] [2001:0:9d38:6ab8:10f6:30d8:8a37:b52c]:57540 [uTP](DOTW2): [µTorrent 3.2.3 (83.0)]: Banning peer: too many pex messages. 5 since Mon Feb 04 15:55:00 2013 [2013-02-04 17:00:07] Impossible de charger "CryptLoad_1.1.8_en.torrent" : le torrent n'est pas en train de bien se B-encoder! [2013-02-04 19:59:59] KMSmicro v3.00: HTTP invalid URL: seed seed seed ^^/ [2013-02-04 20:00:05] Impossible de charger "CryptLoad_1.1.8_en.torrent" : le torrent n'est pas en train de bien se B-encoder! [2013-02-04 23:53:32] 76.241.150.226:37974 [uTP](.Windows 7 Activation 2013..exe): [µTorrent 3.2.3 (0.0)]: Banning peer: too many pex messages. 5 since Mon Feb 04 23:53:29 2013
  24. 5469 nodes in DHT ; RC1 has not yet reached my perso record ! maybe it's time to work on this...
  25. installer cannot run 3.3 after copying it in Program Files(x86) ; trying installing 2.2 gives same result : immediate crash, and no crashdump sent!!! I finally retrieve 3.3, by installing 2.0.0 and clicking on check for update... The fix of installer bug is not operative, and remains from at least 2.2 !!! (windows seven x64)