underspace Posted April 5, 2009 Report Posted April 5, 2009 XP SP2, utorrent 1.8.2 build 14458File A, 1.6 GBSeries B, 8GBFile C, 1GBI direct downloaded File A. Then I thought I would help seed. I copied the file to my archive disk. utorrent force re-check found 1 block wrong (99.9%). I assumed utorrent knew what it was doing, so I downloaded that block and started seeding.Then I saw the torrent for Series B that I already had. So I did a force re-check on that and it found episode 20 had 1 block wrong (99.9%). This raised my suspicions. Both File A and Series B have checksums in their filenames. I did some searching and found fsum.exe and the GUI fsumfrontend. It said the checksum of episode 20 matched the one in the filename. So I told utorrent not to download that 1 file and started seeding.I had stopped File A seeding at that stage. I thought I would do another force re-check on File A. utorrent found another block wrong. I know it was another piece because I watched which piece number was being downloaded each time. This is inconsistent. The first re-check only found 1 block wrong. I downloaded it. But then another block was found wrong, when nothing else had changed.Then I thought I would test it on File C, which I have watched with no visible problems. I haven't moved it since I downloaded it. A force re-check on File C found 1 block wrong (99.9%) - well, it looked like 1 block in the 'general' tab view.I upgraded to 1.8.2 from 1.7.7 about a month ago. I replaced the PC memory (1 to 4GB) about 2 weeks ago, and increased utorrent disk cache to 196MB.I restarted utorrent and did a re-check - no change. I rebooted - no change.I still have 1.7.7 and can test that. After running 1.8.2 are the config files backwards compatible? That is, will 1.7.7 get upset about some settings that only exist in 1.8.2 ?I also have a different bittorrent client which I haven't used for over a year. I could test its CRC32 ability.I did notice a big difference in force re-check going from 1.7.7 to 1.8.2. In the old version the cpu fan would go full speed, but it doesn't in 1.8.2 so the code has obviously been changed.Suggestions welcome.Thanks.
moogly Posted April 5, 2009 Report Posted April 5, 2009 Only latest stable 1.8.2 is supported.About your files A & C, are they associated to a non-multifiles torrent, e.g. torrent A -> file Atorrent C -> file Cor these torrents are multifiles and you skipped some files when you downloaded torrents A & C?Because this behavior can occur when you recheck a multifiles torrent if you have previously skipped files from the download..
underspace Posted April 6, 2009 Author Report Posted April 6, 2009 Yes, moogly, torrent A and C are single file torrents. Torrent A was never downloaded. I obtained that file by direct download over the web and then decided to seed it over bittorrent.In researching this problem I did find a thread in this forum about utorrent on Vista 64 filling up the Vista file cache. I decided to try the recommendation made there: to tick the box that disables Windows file caching. And that fixed the problem!! Force re-check now works and says those 3 torrents are at 100%. Note that I have always run utorrent with the Windows write file caching disabled - I figured I didn't want another system between utorrent and the disk for my precious data.Is anyone able to explain why the Windows file cache would return bad data to uTorrent? Is there a Windows patch I need to apply?I just went to the download page, and 1.8.2 build 14458 is the latest version listed.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.