Jump to content

relocating completed torrents causes <100% completion


manys

Recommended Posts

After a torrent is finished and I move it to a different directory, the files lose pieces. The meter in uT shows missing pieces from the beginning and end of each file every time I do this. Aside from "don't do that," what is happening here, and can it be avoided? Is uT paying attention to directories and thus changing the hash with each copy or change in the name of the parent path?

Link to comment
Share on other sites

That's one of the two reasons pieces get "lost". If every file has its edge piece affected.. let me make the other case. You are playing with media files. And you use a media library manager like WMP or iTunes. They alter your data. Your data is no longer what you downloaded hence the "missing" pieces.

Edit: I meant to reply to your latter question last time, but I got distracted. uT doesn't modify the torrent. It loads it, all changes made such as trackers and rename operations are stored in the resume.dat.

Link to comment
Share on other sites

The files are not media? In the Files tab, right click the column header turn on First Piece. Sort by First Piece. If every file in order is showing RED (unavailable) that means that the data was corrupted. If it happens on all files and they're not media, run a chkdsk immediately to keep from losing data. Additionally you may want to run memtest86 > 12 hours to see what shows up.

The reason for the % decrease is whenever you change paths, uT re-verifies data integrity. It's not the moving which caused the "loss" of data, but it made you aware of it.

Link to comment
Share on other sites

the last part makes some sense. is it a part of the torrent spec that a path change will invalidate files/pieces within a torrent, or is it a uTorrent thing? If it's a uT thing, why can't it figure out that the paths are the only thing that changed? Currently I have to actually re-download the torrent in order to straighten everything back up, which seems excessive and redundant.

Link to comment
Share on other sites

  • 5 weeks later...

Solved. The problem is not due to merely moving the files, it's from changing ID3 tags. If only the protocol could handle this, because a lot of people have lax attitudes toward ID3's and I'd rather not have multiple copies laying around for things I'm seeding. Boo hoo for me, I guess!

So yes, when a file doesn't match the hash it gets redownloaded, but that wasn't my question.

(v1.8.2, btw)

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...