Jump to content

uT 2.0.4 Error: Element not found (other solutions don't work)


Recommended Posts

I see this in the log (filename obscured by Xs):

[2010-10-05 11:36:39] IO Error:1168 line:395 align:-99 pos:-99 count:7973 actual:7853

[2010-10-05 11:36:39] ReadFile error: xxxxx_xxx_xxxxxx_xxxxxxxx_xxxxxxxxxx_xxxxxxx-xxx_xxxxx_xx_xxxxxxx-xxxxx_xxx-xxxx-xxx\xx-xxxxx_xxx_xxxxxx_xxxxxxxx_xxxxxxxxxx_xxxxxxx-xxx_xxxxx_xx_xxxxxxx-xxxxx_xxx-xxxx-xxx.txt:0:7973:169048:2

Now, it's a long path but the download root is c:\downloads so we're on a shorter total path than limited by Windows.. There doesnt seem to be an option for compact allocation in settings (old suggestion to fix), sparse files is ON.. no other deviations from normal settings. I've stopped, force rechecked and restarted the torrent and it just bombs in the last few kilobytes because of this one small text file, only 1 piece to go..

Any ideas what causes this?

Link to comment
Share on other sites

I don't; this is just a regular NATed-through-home-router connection with no firewall, virus etc programs

I noted something odd, when I went to have a look at the Files list tab for the torrent, the file uT was struggling with (i.e. the one named above) was represented in short name format (i.e. XXXXXX~1.TXT) rather than long name format. The same was true of another smal text file. Both files actually exist in the directory (already downloaded this once on an old client, now trying to seed it on new uT and it's screwing up)

I opted to change where the file was downloaded to, and re-chose the same file, and the shortname has changed to a long name. I forced a recheck but it still came out as 99.9% so I started the torrent again and was rather surprised to see the progress bar for these files was white, even though the download priority was "normal" (usually it's white if youre skipping the file)

I set the files to skip and back to normal and the progress bars for them are green now, so I'll see what happens as uT downloads the missing piece and report back if it breaks..

if it doesnt break, perhaps this is something the uT team can look at in relation to Element not found; the MS DOS short name (maybe the file doesnt have a short name any longer due to it being reseeded after being downloaded long ago.. it has been copied between hard disks since, possibly fat32 -> ntfs along the way)

Link to comment
Share on other sites

Oooh, wait a second.. I've just noticed in the Files tab, that two files are repeated with identical paths but with different sizes, e.g.

path\to\file\abc.txt 7.78kB

path\to\file\def.txt 615B

path\to\file\abc.txt 7.66kB

path\to\file\def.txt 1.37kB

Is this an error on the part of the person who made the torrent? What does uT do if a torrent tells it to download two distinct files to the same local location? I'll try setting these to different names and see if it downloads properly

Link to comment
Share on other sites

Using the Relocate.. option to tell uT to download the repeated filenames into different files solved the "Element not found" problem

Would this sort of thing be an easy-to-add-to-the-code solution for problematic torrents, so that uT can download them?

Link to comment
Share on other sites

  • 1 month later...

I just encountered this problem too with a torrent originally created on a Linux system. There are several files that only differ in case, eg. one is fileA.dat and the other is filea.dat. This means that every time a block for one file is downloaded, it also overwrites a block belonging to the other file, leading to that block becoming bad and giving the dreaded "Element not found" error.

So not only do you have to be careful about repeating files names, but also files that are case-insensitively equal.

Feature suggestion: Automatic renaming of those files - or at least a warning when loading a torrent that contains them.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...