Have a hidden flag for each file that lets vuze know if even a single byte of a file has been downloaded, If not when vuze is asked to move a file it only move partial or completed files and does not move empty files, instead it writes a new ones and deletes old ones ".en mass" after transferring all the others. Also each torrent has a unique directory under the "vuze download" directory, I'll just call it torrent's directory for clarity. When right clicking on the torrent in the library or anywhere else, there should be a move option to move the entire torrent. When moving the torrent it has a check box for including the torrent's (unique to that torrent) directory in the move, otherwise it only moves files and sub-directories within that torrent's directory. Also why can't Vuze move files a quickly as you can under the OS. The OS moves them much quicker but of course screws up Vuze's ability to track the files.

The Problem:

It usually so happens that a media file could be previewed only after a good percentage of it has been downloaded and that too much later, only to be discarded if the file does not contain the required content,quality,etc.

To avoid this common condition, Vuze has provided a feature to download the first and last pieces of a torrent file on priority. However, this solution is not always fruitful.

When downloading a media torrent, I've noticed that media info was incomplete despite downloading the first and last pieces. Moreover, I've also observed that such torrents most likely contained the info in the first "few" and the last "few" pieces of the torrent; typically in the first 2 MB and the last 2 MB (See the Note in the end).

Moreover, this task becomes even more difficult for torrents with multiple media files as it is very cumbersome to identify the file boundaries - the piece where a media file ends and the next one begins within the torrent.

My Suggestion:

I'd suggest the piece-map grid to highlight the pieces that contain media info in a distinctive color so that a user can force the pieces to be downloaded manually. Better still, modify the existing feature to download all these pieces on priority rather than download only the first and the last ones.

I may also add here that in some rare cases, a similar but a very close symptom was observed when despite having all the required media info, the file could still not be previewed, in which case, the same workaround of having to force the pieces further down the grid worked! I'm not deterministic here and tell as to how many of such pieces are required in order to successfully preview the media file. I tried forcing few pieces and was able to preview thereupon.

NOTE:

A user may be interested in the following piece of info:

There's a relationship between the number of pieces and the total size of the torrent being downloaded. Either of them could be a multiple or a factor of the other.

Pieces per MB = Total No. of Pieces listed in Piece Map

                        ------------------------------------------------

                           File size in MB (1GB = 1024 MB)

EXAMPLE:

For Illustration, view the attachments - General Tab (for Size) & Piece Map (for No. of Pieces).

Size in MB = 2.81 GB * 1024 = 2877.44 ~ 2878 MB
No. of Pieces = 721
Size of Each Piece = 2878/721 = 719.5 ~ 4 MB

Most likely, this media torrent had all the require media info with the downloading of the first and last pieces (> 2 MB).

Alternatively,
If it had been a multiple, say for e.g,
2878 MB * 4 = 11512 pieces,
combining 4 pieces will yield 1 MB. In this case, the user will have to force-piece (download) the first 8 pieces (2 MB) and the last 8 pieces (2MB) to capture the media info.

I use the classic UI under XP.

I often want to change where I'm seeding a torrent from; to retarget the whole torrent. The data has already been copied across by a backup process.

At the moment, I have to temporarily hide the folder that Vuze had been using by renaming it, then use the move data option (which then works). Without the hiding, Vuze tries to move data and then complains that the files already exists at the target. I then manually do a hash recheck for safety.

So please add a Retarget option for whole torrents, which changes the data location without moving data and then automatically does a hash recheck to assess the data at the new location.