LeKing
Established Members-
Posts
106 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Events
Blogs
Store
Everything posted by LeKing
-
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...
-
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.
-
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...
-
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!
-
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).
-
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 .
-
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.
-
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 )
-
path is %appdata%\utorrent\updates that's all folks !
-
"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 .
-
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.
-
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 ?!!
-
Now I know why it was crashing all the time from some days : silent update ! Manual update solved the problem.
-
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 !)
-
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...)
-
Not specially appealing, but frustrating : unable to spot torrents which tracker are on error state !
-
+1 ... (maybe it was intended)
-
cache size must be high, and scheduler ought to be disabled... (in order to avoid infamous message !)
-
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...
-
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 !!!
-
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 !
-
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 !
-
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
-
5469 nodes in DHT ; RC1 has not yet reached my perso record ! maybe it's time to work on this...
-
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)