#187 More information for --on-download*

open
nobody
None
5
2012-09-28
2010-11-14
Finesse
No

Could we have more information piped out of the --on-download-complete etc options so additional scripts can be made that, for example extract an archived downloaded file automatically.

Things like download dir/filename.

Also when downloading a metalink which contains multiple files, there is no output when all files in the metalink are completed I assume because they are all treated as separate (unlike BT downloads)

Discussion

  • Finesse
    Finesse
    2010-11-14

    I forgot to mention this is for when not running aria2 as a daemon or rpc.

     
  • tujikawa
    tujikawa
    2010-11-15

    The reason why filename is not passed is that one download can contains many files. There is no limit for them but the number of argument to script is limited I think.
    I designed --on-download-* option to work with xml-rpc.

    There is a way to combine several files in metalink to one download like torrent.
    This depends on the current implementation but it works.
    To do this, you need Metalink4 spec.
    In order for aria2 to support name attribute of metaurl element, it combines files which has size specified and has same metaurl. You can specify non-existent URI to metaurl to just achieve our goal.

    The XML is like this:

    <metalink xmlns="urn:ietf:params:xml:ns:metalink"> <file name="file1"> <size>12345</size> <url>http://localhost/file1</url> <metaurl mediatype="torrent" name="file1">http://localhost/not_found</metaurl> </file> <file name="file2"> <size>67890</size> <url>http://localhost/file2</url> <metaurl mediatype="torrent" name="file2">http://localhost/not_found</metaurl> </file> </metalink>

    http://localhost/not_found is URI point to file which does not exist.
    When the above meta4 file is fed to aria2c, it will download file1 and file2 in one download.

    This method has some drawbacks, one of them is -V option cannot be used even if each file element has piace hashes.

     
  • tujikawa
    tujikawa
    2010-11-15

    I think most of the download is just one file, so if most of the user is satisfied with one file path passed to --on-download-* script, I'll do so.