I noticed this issue with aria2-1.3.1 so i went ahead and compiled 1.3.2 just to be sure. When using --check-integrity=true on a partially d'loaded torrent, aria2 seems to reject and/or not recognize the files that are already completed and starts the torrent from 0%. This wastes alot of time and bandwidth re-downloading pieces already present.
For example, i used the --select-file option to download the first 20 photos of a small wallpaper torrent, and it worked perfectly. Aria2 d'loaded 11.3MiB of the total 18.8MB and went into SEEDING mode as it should.
aria2c --select-file=1-20 -l LOG-SELECT wallpaper.torrent
So far so good. But when i stop and remove the *.aria2 control file, and reun the torrent as
aria2c --check-integrity=true -l LOG-CHECK wallpaper.torrent
the console output reports 0% and aria2 re-downloads the whole torrent, ignoring the 60% that's already there. This must be a bug because when i run bittornado on the partial download, it reports 60% and just d'loads the remaining 40%.
I think this is rather important especially on large torrents where bandidth and time are at a premium. The two log files are attached on a rapidshare link at
PS: here is my console output for version..
$ aria2c -v
aria2 version 1.3.2
Copyright (C) 2006, 2009 Tatsuhiro Tsujikawa
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
Enabled Features: Async DNS, BitTorrent, Firefox3 Cookie, GZip, HTTPS, Message Digest, Metalink
Hash Algorithms: md5, sha1, sha256
Report bugs to <tujikawa at users dot sourceforge dot net>
Finally we could release stable 1.3 release! Thanks for your contribution :)
Thanks reporting bug! I reproduced it.
This bug is reproducible for the download that a file includes last piece is missing. In your case, last part of file is missing on the disk(because it is not download yet), so it crashed.
This bug doesn't reveal for single-torrent with file allocation on.
I uploaded patch at
cheers, i applied the patch and it seems to work OK. i also repeated test selecting the last 20 files in the wallpower torrent instead of first 20 and that was fine too -- aria2 recognized the already-downloaded parts with the check-integrity option.
however, in case of single-file torrents the check-integrity option still has major bugs, or at least it does for me. for example, if you take any completed single-file torrent, and divide it's size into 2 equal parts: say 100MB/2 =50MB and run..
aria2c --check-integrity=true single-file.torrent
it will correctly report 50% when you have the first-half of the file present. BUT if you do same test with the 2nd-half of the file present aria2 erroneously reports "0%" and ignores half the file that has already been downloaded. this i consider to be a rather major flaw.
by comparison, when i repeat the above using BitTornado, it correctly accounts for the 50% of the file that is still there, whether or not it happens to occur at the beginning or end.
It would be good to detect the position of data, but I don't find good use case for just giving 2nd-half file. aria2 needs padding for first half data for this case. It is very interesting BitTornado has this feature.
For me, this is a new feature and not major flaw.
yes i see what you mean. i was also puzzled how bittornado was able to know the 2nd-half position and accurately recognize it. for this reason i tried a third well-known bittorrent client Ktorrent and it behaves exactly like aria2 -- it sees 50% when the first-half of the single-file torrent is present, but reports 0% when the 2nd half is there.
so i must apologize for saying there is a major flaw. it must be that bittornado is unique in having this ability.
thanks again, and keep up the good work.
i installed the new 1.3.3 release yesterday and tried it with numerous small torrents. i purposely was looking for any bugs with some of the advanced features but it all seemed OK.
also aria2 is giving very good d'load speeds and is comparable to bittornado, and faster than ktorrent.
so i would say version 1.3.3 can be used confidence as a primary bittorrent client.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.