warwick_erik Posted March 27, 2011 Share Posted March 27, 2011 I like the Piece Map tab feature, but I think that its usefulness could be improved. The problem with the current piece map is that it is difficult at best to determine which pieces are associated with a particular file. I propose making a per-file piece map, which would show the pieces that contain a portion of a particular file. There are a few different ways in which this could be implemented. Note that the current per-torrent Piece Map tab should be retained. A new column in the Files tab Place the per-file piece map below each file in the File tab. This option would need a GUI feature that enables/disables the per-file piece maps so that large files don't fill the screen with piece map boxes. This could also be "sub-directory" structure between each file and its per-file piece map, much like how files and folders are represented in the Files tab currently. A minor issue to be addressed is the misrepresentation of the number of pieces in the torrent. For example, if the piece size is 1MB but you have 50 files that are each 0.33MB, then you would end up with more piece map boxes than there are actual pieces. This doesn't necessary need to be addressed, but it could be solved by extending the set of piece map icons (i.e. new icons to indicate that a piece spans a second file). I have attached a crude example of what I think this new feature should look like. Link to comment Share on other sites More sharing options...
The UnUsual Suspect Posted March 27, 2011 Share Posted March 27, 2011 Thank you for your suggestion. I agree it will be complicated, as some pieces could have data from multiple files, but as you stated different color piece icons could demonstrate it contains shared data. My thoughts are that if this is implimented, that it be done in a separate window that pops up if you select an option to "view bittorrent pieces that compose this file" (that would have to be shortened to fit context menu of course), so it doesn't clutter up the gui. One thing I'm not sure about is if this will have any real benefit to the average user to warrant the time necessary to do the coding. Can you elaborate as to what benefit it would have for you? Also, I (personally) feel we need to do more to steer users away from treating the downloads as they are done file by file. There is so much ignorance over this, such as a user deleting file 2 manually and disabling it in the gui, then suddenly being surprised when file 1 and 3 revert to 99% complete. If it was upto me, I'd put a warning on the file selection area stating that altering these settings will adversely effect efficiency of download. Also users that download large torrents one file at a time are really hurting themselves and all other peers. torrents just don't work like that, and as much as we try to educate users, we continue to get members doing this. Link to comment Share on other sites More sharing options...
kluelos Posted March 28, 2011 Share Posted March 28, 2011 The whole "map pieces to files" idea has been treated with great "not invented here" disenthusiasm by the community. BitComet's "padding files" intended to correct anomalies, were widely rejected and called "spam", especially by the morons over at the Demonoid forums. There's not much enthusiasm for trying this again. There's also no way to correlate the piece map with the files. Hmm. This is a little more difficult... Files exist in a certain order within a directory. You SEE them in alphabetical order, but that's not the way they exist . One of the early Norton MSDOS utilities -- the ones written by Peter Norton before he sold the name to Symantec -- was called "dirsort", and it rearranged an MSDOS directory into alphabetical order, then rewrote it to disk that way. The point is that the order did not exist otherwise, and under MSDos you saw the files listed in the order they were created. One DIRSORTed them to get them into alphabetical order, which is a big reason why Peter Norton was so highly thought of. GOOD utility! Alphabetical order is taken for granted under Windows. So they're NOT in alphabetical order, really, on the disk. The pieces are calculated in terms of what's on the disk, so there's no correlation between the sequence of filenames that you see, and the sequence of pieces in the .torrent file. They're not necessarily even in the same order. This is therefore a lot harder than it might seem. Link to comment Share on other sites More sharing options...
greywizard Posted March 28, 2011 Share Posted March 28, 2011 I sort of agree with TUUS. I can't seem to fathom a very good reason to go through all the trouble necessary to code this. What would be your immediate benefit, out of this? At the end of the day, every new line of code added, increases the size of the installer, of the executable and also the possibility of new bugs to occur. Therefore, the main criteria based on which features must get added into an application should be these: To what purpose does it serve? Is it worth the trouble to implement? Link to comment Share on other sites More sharing options...
warwick_erik Posted March 30, 2011 Author Share Posted March 30, 2011 TUUS does make a good point about how new users have this "per-file" mindset. I suppose the point of this feature would be to give the Piece Map some context. When I look at the piece map, I can deduce that, for example, pieces 30-40 are probably part of file 7, but it isn't obvious. Another implementation method that just occurred to me is to make this new "per-file" piece map use the same format as the Peer Status column on the Peers tab. This could be as compact as the user wants it to be, could be turned on/off just like any other column, and the GUI interface already exists. In this case, I don't think it would be necessary to indicate that a particular piece spans multiple files because the interface is less precise than the piece map. kluelos, you do make a good point about alphabetical order. However, alphabetical order doesn't really have anything to do with what I'm suggesting. I assume that pieces are already somehow associated with a file or files at some point, otherwise you wouldn't be able to open any files until the entire torrent finishes downloading. What I'm suggesting is just that this representation be displayed graphically. Also, the feature only interprets data that is already present in BitComet, it wouldn't (and shouldn't) affect the underlying operation of BitComet. greywizard, I agree with your points about extra code and bugs. This certainly isn't a critical feature, but more of a "cherry on the top" type of feature. I'm not privy to the BitComet code base, so I have no idea how complex this feature would be to implement. Perhaps it would be 20 lines of code, perhaps it would be 500. Link to comment Share on other sites More sharing options...
The UnUsual Suspect Posted March 30, 2011 Share Posted March 30, 2011 Just to keep you updated, the development team has looked over this post, and the graphics you made. I still don't know if it will be seriously considered, but I agree that if it's not a lot of work, it wouldn't be a bad idea. Link to comment Share on other sites More sharing options...
khota33 Posted April 2, 2011 Share Posted April 2, 2011 Well i would say that if it isn't that big trouble to add this functionality into bitcomet, then it would be a nice feature. ;) Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now