Jump to content

guest69

Members
  • Posts

    8
  • Joined

  • Last visited

Everything posted by guest69

  1. That sounds good ... is that 1-5KB/ or Kb/s? And is that per torrent, global or per uploading task? I'm giving uT a try again, and my upload is 30KB with 4 preferred uploads at a time and only 1 Torrent. So far it's doing reasonably well with download speed again (compared to BC doing the same torrent which still was faster, but no longer by much) but indeed ut finds about half the number of peers (DHT was active in both uT and BC, this torrent seems to use several trackers, hope uT checks them all).
  2. Hmmm ... just noticed from switching back and forth between Bitcomet and uTorrent that BC finds far more peers more than twice utorrents 400, and that download speeds are far faster (utorrent seems to limit too much based on upload). Clients that limit their downloads too much based on uploads are it for me. I have 384/1Mbit. As you know, uploads are on 100% of the time, while downloads only go on while there is something to download and someone willing to send it. But we all appreciate watching that TV show today rather than tomorrow. Do NOT limit downloads too much, something like emule's 3x to 4x the upload is reasonable. Don't complain about leechers. There will always be leachers and they'll use whatever client or whatever mod. Do not punish normal users (70%) for leachers. Samething as copyprotection etc ... pirates are ALWAYS going to pirate and leachers are ALWAYS going to leach, copyprotection, caps, private shares and the like only end up punishing regulars users that "pay" for other's sins. Back to Bitcomet Hope they fix that CPU bug and come one with a 0.61, but I'm not holding my breath. It's annoying, but can be lived with. Or hope the uTorrent guys relax the download cap and are a tad more aggressive finding sources and making connections.
  3. Just for further information, I have of course disabled (long ago) indexing and the like. Also decided to try utorrent again after downloading for a while with Bitcomet. Well, same problem. At about 35% of the rehash, always same point, it gives me the access error. I tried re-downloading the .torrent file, pointing to different directories, selecting different files, etc. Always the error, on the same spot. So i decided to try once more but "erasing" some of the already partially downloaded files. Well, I isolated a small group of partially downloaded files that, if present, will give the access error. Didn't bother pinpointing one in particular, as they were 4 o 5 small inconsecuential files (3x5kb .jpg, one .htm and one .txt of less than 1k or maybe even 0bytes). I can not figure anything wrong with those files (attributes, locks, access, etc), so I once again think that a hash-check error has gone bersek and ends up being reported as an "access error" and makes the torrent stop rather than re-download or whatever. If it helps, one of the files has Asian characters in the file name (I ran imei) and has a 0 length although it occupies 1 block. Whatever, there is a bug somewhere with the hash-check-file-write that gives inappropiate cannot access errors. If the error gets logged to a window, I could gladly try to reproduce it and find out more information. Also a ~uTorrentPartFile_2A694AAFC.dat appeared in the (temporary) download directory from i don't know where. So anyway, let me know if anyone needs more info to find this bug. But it looks to me that it's a bug, and not an external software interference.
  4. Hi, Well, same problem here. Happened with the beta about a week old and with the just downloaded 1.4 (final) version. Here is the story: I started a download with Bitcomet 0.60. Bitcomet works great, but with some torrents with a large (over 1,000) peers, it often makes my CPU usage WAY too high, causing problems. It's some sort of bug with the BC 0.60. This download was particularly large, about 10GB with 2MB chunks spread into about 20 files. I downloaded about 10% with bitcomet and grew tire of the CPU usage problem, so tried uTorrent for the first time. Renamed the .bc! files, pointed to the right places, and off we go. For the next 1 1/2 days everything worked fine and utorrent took my torrent from 10 to >30% quickly and efficiently. I noticed less sources that Bitcomet 0.60 was finding, about 800 as oppossed to BC >1,500, but no problem there. Then, out of the blue, the "cannot access" error came up and the torrent stopped. Restarting the torrent only worked for a few minutes at best. Searched for the problems on forums and tried all possibilities. So here it goes: -First and foremost: the obvious. I checked the FAQ, searched the forum, this is the only torrent being downloaded, this is the only instance of utorrent, i tried with certain files "checked" (being selectively downloaded) and with all of them (the whole say 20 files), I rebooted, I'm a computer expert, etc For all the tests I did below, I want everyone to remember that the torrent was working fine for about 1 1/2 days without anything being changed meanwhile and during that time some 2+GB was downloaded. As soon as the "access denied" problem started happening, nothing I tried could get the torrent to resume for more than a few minutes at best. This is windows xp pro, US edition, updated to the latest of the latest Remember again, the download worked fine from the time i installed utorrent without interruption for the next few days and several hundred MB until it gave the error for the first time and ever since. -I do run Norton Antivirus 2005 and nothing else. I deactivated it. It doesn't automatically update, so it was the same it's been for the past 5/6 days. I doubt it's the problem. If it helps, only recent "weird" update was the update to the December version of DirectX 9 from Microsoft some days ago. -I did set the flags on the files. Manually with command line, through windows, to +A and to +AS, installed some unlock utility, etc, etc. Tried everything: renaming files, erasing .torrent and re-downloading, rechecking (re-hashing), sharing on network (I don't have a network, but just in case), you name it. Nothing seems to get utorrent to stop the error. -I have always had all windows media explorer extensions deactivated. Regardless, I tried rebooting and just running utorrent w/o ever opening the explorer. -I tried the latest (just downloaded) 1.4 version of utorrent. If anything, it seems to be worse at this problem. -Tried disabling that cache option in utorrent (u know which one). Because I resumed the download with bitcomet I no longer want to run utorrent to avoid conflicts, so I'm talking from memory and being a utorrent user for only a short day or two don't remember exactly the name of all the options etc. Long story short: I can not figure out where the error comes from. My opinion: write a better error desciption that "access denied" ... something like the name of the file being tried to write to or something would help. Regardless, my opinion is that it's a bug NOT related to the file access rights, at least not the files being downloaded, since it seems to happen also while forced-REHASING the torrent. In another words, seems to be some sort of lock that is left somewhere RELATED to the files downloaded but not the files themselves, I don't think. Where does utorrent store the information related to a .torrent? (u know, percentages, chunks downloaded, etc) Or perhaps just some sort of hash check that, when failed or whatever, erroneusly reports the error as "access denied" when it's something "else". Whenever it gets fixed, I hope to use utorrent again as it seems second best to Bitcomet, which I would never leave if it weren't for the cpu-usage bug with large torrents. I switched the same torrent (back) to bitcomet 0.60, renaming the files with .bc! at the end, and bitcomet resumed without problems and got me another 2% more done in the past few hours. Let me know if there is any information more especific that could help track this bug as I think it's a real problem and (not only) related to external software trying to access the file while uT wants exclusive access and locks fails or whatever. Forgot to mention that last tests gave this conclusion: with the prior Beta, when torrent was forced to manually rehash or re-started after that and tried to rehash by itself, it always stopped at the same (around 30%) point. So it no longer could download even for a few minutes. And with the new 1.4 version, as soon as it starts to rehash, it also shown the error. Even after a clean boot, etc. As i said, I would look into some hash check routine problem ending in the wrong "cannot access" error code. But also remember that before rehashing was forced (or became necessary to start the download), the torrent started to download fine and at some point on the download (a few minutes, a few MB's) it would fail with the error also. If it helps, the torrent includes some zero length files (i.e. "\AUDIO_TS" empty directory by itself).
×
×
  • Create New...