The download code seems to be based on 3.3, and doesn't have the bugfixes and improvements which have been added since it was released (and which are included in shad0w's experimental). One nasty bug can cause data loss if you resume a file that had been preallocated (by another client for example).
I also looked at the file priority feature, and the implementation is not good. It should take the rarity of pieces into account, similarly to how the algorithm doesn't prefer partially downloaded pieces if other available pieces are really rare. Strict priority that disregards rarity can harm torrents, especially it lowers seeding efficiency if superseed mode is not used.
I have a version of the download code that has properly implemented file priorities as well as several other technical improvements. However, I intend to license it under the GPL, so using it in g3torrent would require a license change.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well it does not completely disregard rarity. But you are right in that it will not go out of its way to DL the rarest pieces if the piece does not belong in the file it is currently interested in. However the pieces that do get picked can be considered the rarest within a given file (or piece range) that has the immediate priority.
I assumed this would be sufficient, but I suppose I could insist that the rarest (ie: less than 2) go first before any other.
As for the file bug, I guess I will have to look closer into that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The download code seems to be based on 3.3, and doesn't have the bugfixes and improvements which have been added since it was released (and which are included in shad0w's experimental). One nasty bug can cause data loss if you resume a file that had been preallocated (by another client for example).
I also looked at the file priority feature, and the implementation is not good. It should take the rarity of pieces into account, similarly to how the algorithm doesn't prefer partially downloaded pieces if other available pieces are really rare. Strict priority that disregards rarity can harm torrents, especially it lowers seeding efficiency if superseed mode is not used.
I have a version of the download code that has properly implemented file priorities as well as several other technical improvements. However, I intend to license it under the GPL, so using it in g3torrent would require a license change.
Well it does not completely disregard rarity. But you are right in that it will not go out of its way to DL the rarest pieces if the piece does not belong in the file it is currently interested in. However the pieces that do get picked can be considered the rarest within a given file (or piece range) that has the immediate priority.
I assumed this would be sufficient, but I suppose I could insist that the rarest (ie: less than 2) go first before any other.
As for the file bug, I guess I will have to look closer into that.