Class TorrentHandle

java.lang.Object
com.frostwire.jlibtorrent.TorrentHandle
public final class TorrentHandle extends Object
You will usually have to store your torrent handles somewhere, since it's the object through which you retrieve information about the torrent and aborts the torrent.

.. warning:: Any member function that returns a value or fills in a value has to be made synchronously. This means it has to wait for the main thread to complete the query before it can return. This might potentially be expensive if done from within a GUI thread that needs to stay responsive. Try to avoid querying for information you don't need, and try to do it in as few calls as possible. You can get most of the interesting information about a torrent from the torrent_handle::status() call.

The default constructor will initialize the handle to an invalid state. Which means you cannot perform any operation on it, unless you first assign it a valid handle. If you try to perform any operation on an uninitialized handle, it will throw ``invalid_handle``.

.. warning:: All operations on a torrent_handle may throw libtorrent_exception exception, in case the handle is no longer referring to a torrent. There is one exception is_valid() will never throw. Since the torrents are processed by a background thread, there is no guarantee that a handle will remain valid between two calls.

  • Field Details

    • OVERWRITE_EXISTING

      public static final add_piece_flags_t OVERWRITE_EXISTING
      Instruct libtorrent to overwrite any data that may already have been downloaded with the data of the new piece being added.

    • QUERY_DISTRIBUTED_COPIES

      public static final status_flags_t QUERY_DISTRIBUTED_COPIES
      calculates ``distributed_copies``, ``distributed_full_copies`` and ``distributed_fraction``.

    • QUERY_ACCURATE_DOWNLOAD_COUNTERS

      public static final status_flags_t QUERY_ACCURATE_DOWNLOAD_COUNTERS
      includes partial downloaded blocks in ``total_done`` and ``total_wanted_done``.

    • QUERY_LAST_SEEN_COMPLETE

      public static final status_flags_t QUERY_LAST_SEEN_COMPLETE
      includes ``last_seen_complete``.

    • QUERY_PIECES

      public static final status_flags_t QUERY_PIECES
      includes ``pieces``.

    • QUERY_VERIFIED_PIECES

      public static final status_flags_t QUERY_VERIFIED_PIECES
      includes ``verified_pieces`` (only applies to torrents in *seed mode*).

    • QUERY_TORRENT_FILE

      public static final status_flags_t QUERY_TORRENT_FILE
      includes ``torrent_file``, which is all the static information from the .torrent file.

    • QUERY_NAME

      public static final status_flags_t QUERY_NAME
      includes name, the name of the torrent. This is either derived from the .torrent file, or from the &dn= magnet link argument or possibly some other source. If the name of the torrent is not known, this is an empty string.

    • QUERY_SAVE_PATH

      public static final status_flags_t QUERY_SAVE_PATH
      includes ``save_path``, the path to the directory the files of the torrent are saved to.

    • FLUSH_DISK_CACHE

      public static final resume_data_flags_t FLUSH_DISK_CACHE
      The disk cache will be flushed before creating the resume data. This avoids a problem with file timestamps in the resume data in case the cache hasn't been flushed yet.

    • SAVE_INFO_DICT

      public static final resume_data_flags_t SAVE_INFO_DICT
      The resume data will contain the metadata from the torrent file as well. This is default for any torrent that's added without a torrent file (such as a magnet link or a URL).

    • ONLY_IF_MODIFIED

      public static final resume_data_flags_t ONLY_IF_MODIFIED
      If nothing significant has changed in the torrent since the last time resume data was saved, fail this attempt. Significant changes primarily include more data having been downloaded, file or piece priorities having changed etc. If the resume data doesn't need saving, a save_resume_data_failed_alert is posted with the error resume_data_not_modified.

    • IGNORE_MIN_INTERVAL

      public static final reannounce_flags_t IGNORE_MIN_INTERVAL
      By default, force-reannounce will still honor the min-interval published by the tracker. If this flag is set, it will be ignored and the tracker is announced immediately.

    • ALERT_WHEN_AVAILABLE

      public static final deadline_flags_t ALERT_WHEN_AVAILABLE

    • PIECE_GRANULARITY

      public static final file_progress_flags_t PIECE_GRANULARITY
      Only calculate file progress at piece granularity. This makes the `fileProgress()` call cheaper and also only takes bytes that have passed the hash check into account, so progress cannot regress in this mode.

  • Constructor Details

  • Method Details

    • swig

      public torrent_handle swig()
      Returns:
      the native object

    • addPiece

      public void addPiece(int piece, byte[] data, add_piece_flags_t flags)
      This function will write data to the storage as piece piece, as if it had been downloaded from a peer. data is expected to point to a buffer of as many bytes as the size of the specified piece. The data in the buffer is copied and passed on to the disk IO thread to be written at a later point.

      By default, data that's already been downloaded is not overwritten by this buffer. If you trust this data to be correct (and pass the piece hash check) you may pass the overwrite_existing flag. This will instruct libtorrent to overwrite any data that may already have been downloaded with this data.

      Since the data is written asynchronously, you may know that is passed or failed the hash check by waiting for PieceFinishedAlert or HashFailedAlert.

      Parameters:
      piece - the piece index
      data - the piece data
      flags - flags

    • addPiece

      public void addPiece(int piece, byte[] data)
      Same as calling addPiece(int, byte[], add_piece_flags_t) with flags with value 0.
      Parameters:
      piece - the piece index
      data - the piece data

    • readPiece

      public void readPiece(int piece)
      This function starts an asynchronous read operation of the specified piece from this torrent. You must have completed the download of the specified piece before calling this function.

      When the read operation is completed, it is passed back through an alert, ReadPieceAlert. Since this alert is a response to an explicit call, it will always be posted, regardless of the alert mask.

      Note that if you read multiple pieces, the read operations are not guaranteed to finish in the same order as you initiated them.

      Parameters:
      piece - the piece index

    • havePiece

      public boolean havePiece(int piece)
      Returns true if this piece has been completely downloaded, and false otherwise.
      Parameters:
      piece - the piece index
      Returns:
      if piece has been completely downloaded

    • peerInfo

      public List<PeerInfo> peerInfo()
      Returns a list filled with one entry for each peer connected to this torrent, given the handle is valid. If the handle is invalid, it will return an empty list.

      Each entry in the vector contains information about that particular peer.

      Returns:
      the list with the peers information
      See Also:

    • torrentFile

      public TorrentInfo torrentFile()
      Returns a pointer to the torrent_info object associated with this torrent. The TorrentInfo object may be a copy of the internal object.

      If the torrent doesn't have metadata, the pointer will not be initialized (i.e. a NULL pointer). The torrent may be in a state without metadata only if it was started without a .torrent file, e.g. by using the libtorrent extension of just supplying a tracker and info-hash.

      Returns:
      the internal torrent info

    • status

      public TorrentStatus status(boolean force)
      `status()`` will return a structure with information about the status of this torrent. If the torrent_handle is invalid, it will throw libtorrent_exception exception. See torrent_status. The ``flags`` argument filters what information is returned in the torrent_status. Some information in there is relatively expensive to calculate, and if you're not interested in it (and see performance issues), you can filter them out.

      By default everything is included. The flags you can use to decide what to *include* are defined in the status_flags_t enum.

      It is important not to call this method for each field in the status for performance reasons.

      Returns:
      the status

    • status

      public TorrentStatus status()
      Returns a structure with information about the status of this torrent. If the handle is invalid, it will throw libtorrent_exception exception. See torrent_status. The ``flags`` argument filters what information is returned in the torrent_status. Some information in there is relatively expensive to calculate, and if you're not interested in it (and see performance issues), you can filter them out.
      Returns:
      the status

    • status

      public TorrentStatus status(status_flags_t flags)
      This method returns an up to date torrent status, the flags parameters is an or-combination of the status_flags_t native values, in case you want advanced (and expensive) fields filled. We recommend the use of the simple call to status() that internally keep a cache with a small time resolution.
      Parameters:
      flags - the flags
      Returns:
      the status

    • getDownloadQueue

      public ArrayList<PartialPieceInfo> getDownloadQueue()
      Returns an array (list) with information about pieces that are partially downloaded or not downloaded at all but partially requested. See PartialPieceInfo for the fields in the returned vector.
      Returns:
      a list with partial piece info

    • infoHash

      public Sha1Hash infoHash()
      Returns the info-hash for the torrent.

      If this handle is to a torrent that hasn't loaded yet (for instance by being added) by a URL, the returned value is undefined.

      Returns:
      the torrent info hash

    • inSession

      public boolean inSession()
      Note that this is a blocking function, unlike torrent_handle::is_valid() which returns immediately.
      Returns:
      Returns true if the torrent is in the session. It returns true before SessionHandle::removeTorrent() is called, and false afterward.

    • pause

      public void pause()
      This method will disconnect all peers.

      When a torrent is paused, it will however remember all share ratios to all peers and remember all potential (not connected) peers. Torrents may be paused automatically if there is a file error (e.g. disk full) or something similar. See FileErrorAlert.

      To know if a torrent is paused or not, call status() and inspect TorrentStatus#isPaused() .

      The ``flags`` argument to pause can be set to ``torrent_handle::graceful_pause`` which will delay the disconnect of peers that we're still downloading outstanding requests from. The torrent will not accept any more requests and will disconnect all idle peers. As soon as a peer is done transferring the blocks that were requested from it, it is disconnected. This is a graceful shut down of the torrent in the sense that no downloaded bytes are wasted.

      torrents that are auto-managed may be automatically resumed again. It does not make sense to pause an auto-managed torrent without making it not automanaged first.

    • resume

      public void resume()
      Will reconnect all peers.

      Torrents that are auto-managed may be automatically resumed again.

    • flags

      public torrent_flags_t flags()

    • setFlags

      public void setFlags(torrent_flags_t flags, torrent_flags_t mask)

    • setFlags

      public void setFlags(torrent_flags_t flags)

    • unsetFlags

      public void unsetFlags(torrent_flags_t flags)

    • flushCache

      public void flushCache()
      Instructs libtorrent to flush all the disk caches for this torrent and close all file handles. This is done asynchronously and you will be notified that it's complete through CacheFlushedAlert.

      Note that by the time you get the alert, libtorrent may have cached more data for the torrent, but you are guaranteed that whatever cached data libtorrent had by the time you called flushCache() has been written to disk.

    • needSaveResumeData

      public boolean needSaveResumeData()
      Returns true if any whole chunk has been downloaded since the torrent was first loaded or since the last time the resume data was saved. When saving resume data periodically, it makes sense to skip any torrent which hasn't downloaded anything since the last time.

      A torrent's resume data is considered saved as soon as the alert is posted. It is important to make sure this alert is received and handled in order for this function to be meaningful.

      Returns:
      true if data has been downloaded since the last time the resume data was saved.

    • queuePosition

      public int queuePosition()
      Every torrent that is added is assigned a queue position exactly one greater than the greatest queue position of all existing torrents. Torrents that are being seeded have -1 as their queue position, since they're no longer in line to be downloaded.

      When a torrent is removed or turns into a seed, all torrents with greater queue positions have their positions decreased to fill in the space in the sequence.

      This function returns the torrent's position in the download queue. The torrents with the smallest numbers are the ones that are being downloaded. The smaller number, the closer the torrent is to the front of the line to be started.

      The queue position is also available in the torrent_status.

      Returns:
      the queue position

    • queuePositionUp

      public void queuePositionUp()
      The queue_position_*() functions adjust the torrents position in the queue. Up means closer to the front and down means closer to the back of the queue. Top and bottom refers to the front and the back of the queue respectively.

    • queuePositionDown

      public void queuePositionDown()
      The queue_position_*() functions adjust the torrents position in the queue. Up means closer to the front and down means closer to the back of the queue. Top and bottom refers to the front and the back of the queue respectively.

    • queuePositionTop

      public void queuePositionTop()
      The queue_position_*() functions adjust the torrents position in the queue. Up means closer to the front and down means closer to the back of the queue. Top and bottom refers to the front and the back of the queue respectively.

    • queuePositionBottom

      public void queuePositionBottom()
      The queue_position_*() functions adjust the torrents position in the queue. Up means closer to the front and down means closer to the back of the queue. Top and bottom refers to the front and the back of the queue respectively.

    • queuePositionSet

      public void queuePositionSet(int position)
      Updates the position in the queue for this torrent. The relative order of all other torrents remain intact but their numerical queue position shifts to make space for this torrent's new position
      Parameters:
      position - the new position

    • setSslCertificate

      public void setSslCertificate(String certificate, String privateKey, String dhParams)
      For SSL torrents, use this to specify a path to a .pem file to use as this client's certificate. The certificate must be signed by the certificate in the .torrent file to be valid.

      Note that when a torrent first starts up, and it needs a certificate, it will suspend connecting to any peers until it has one. It's typically desirable to resume the torrent after setting the SSL certificate.

      If you receive a TorrentNeedCertAlert, you need to call this to provide a valid cert. If you don't have a cert you won't be allowed to connect to any peers.

      Parameters:
      certificate - is a path to the (signed) certificate in .pem format corresponding to this torrent.
      privateKey - is a path to the private key for the specified certificate. This must be in .pem format.
      dhParams - is a path to the Diffie-Hellman parameter file, which needs to be in .pem format. You can generate this file using the openssl command like this: ``openssl dhparam -outform PEM -out dhparams.pem 512``.

    • setSslCertificate

      public void setSslCertificate(String certificate, String privateKey, String dhParams, String passphrase)
      For SSL torrents, use this to specify a path to a .pem file to use as this client's certificate. The certificate must be signed by the certificate in the .torrent file to be valid.

      Note that when a torrent first starts up, and it needs a certificate, it will suspend connecting to any peers until it has one. It's typically desirable to resume the torrent after setting the SSL certificate.

      If you receive a TorrentNeedCertAlert, you need to call this to provide a valid cert. If you don't have a cert you won't be allowed to connect to any peers.

      Parameters:
      certificate - is a path to the (signed) certificate in .pem format corresponding to this torrent.
      privateKey - is a path to the private key for the specified certificate. This must be in .pem format.
      dhParams - is a path to the Diffie-Hellman parameter file, which needs to be in .pem format. You can generate this file using the openssl command like this: ``openssl dhparam -outform PEM -out dhparams.pem 512``.
      passphrase - may be specified if the private key is encrypted and requires a passphrase to be decrypted.

    • saveResumeData

      public void saveResumeData(resume_data_flags_t flags)
      ``save_resume_data()`` generates fast-resume data and returns it as an entry. This entry is suitable for being bencoded. For more information about how fast-resume works, see fast-resume_.

      The ``flags`` argument is a bitmask of flags ORed together. see save_resume_flags_t

      This operation is asynchronous, ``save_resume_data`` will return immediately. The resume data is delivered when it's done through an save_resume_data_alert.

      The fast resume data will be empty in the following cases:

      1. The torrent handle is invalid. 2. The torrent is checking (or is queued for checking) its storage, it will obviously not be ready to write resume data. 3. The torrent hasn't received valid metadata and was started without metadata (see libtorrent's metadata-from-peers_ extension)

      Note that by the time you receive the fast resume data, it may already be invalid if the torrent is still downloading! The recommended practice is to first pause the session, then generate the fast resume data, and then close it down. Make sure to not remove_torrent() before you receive the save_resume_data_alert though. There's no need to pause when saving intermittent resume data.

      .. warning:: If you pause every torrent individually instead of pausing the session, every torrent will have its paused state saved in the resume data!

      .. warning:: The resume data contains the modification timestamps for all files. If one file has been modified when the torrent is added again, the will be rechecked. When shutting down, make sure to flush the disk cache before saving the resume data. This will make sure that the file timestamps are up to date and won't be modified after saving the resume data. The recommended way to do this is to pause the torrent, which will flush the cache and disconnect all peers.

      .. note:: It is typically a good idea to save resume data whenever a torrent is completed or paused. In those cases you don't need to pause the torrent or the session, since the torrent will do no more writing to its files. If you save resume data for torrents when they are paused, you can accelerate the shutdown process by not saving resume data again for paused torrents. Completed torrents should have their resume data saved when they complete and on exit, since their statistics might be updated.

      In full allocation mode the reume data is never invalidated by subsequent writes to the files, since pieces won't move around. This means that you don't need to pause before writing resume data in full or sparse mode. If you don't, however, any data written to disk after you saved resume data and before the session closed is lost.

      It also means that if the resume data is out dated, libtorrent will not re-check the files, but assume that it is fairly recent. The assumption is that it's better to loose a little bit than to re-check the entire file.

      It is still a good idea to save resume data periodically during download as well as when closing down.

      Example code to pause and save resume data for all torrents and wait for the alerts:

      .. code:: c++ 

       
 extern int outstanding_resume_data; // global counter of outstanding resume data
 std::vector<torrent_handle> handles = ses.get_torrents();
 ses.pause();
 for (std::vector<torrent_handle>::iterator i = handles.begin();
 i != handles.end(); ++i)
 {
 torrent_handle& h = *i;
 if (!h.is_valid()) continue;
 torrent_status s = h.status();
 if (!s.has_metadata) continue;
 if (!s.need_save_resume_data()) continue;

 h.save_resume_data();
 ++outstanding_resume_data;
 }

 while (outstanding_resume_data > 0)
 {
 alert const* a = ses.wait_for_alert(seconds(10));

 // if we don't get an alert within 10 seconds, abort
 if (a == 0) break;

 std::auto_ptr<alert> holder = ses.pop_alert();

 if (alert_cast<save_resume_data_failed_alert>(a))
 {
 process_alert(a);
 --outstanding_resume_data;
 continue;
 }

 save_resume_data_alert const* rd = alert_cast<save_resume_data_alert>(a);
 if (rd == 0)
 {
 process_alert(a);
 continue;
 }

 torrent_handle h = rd->handle;
 torrent_status st = h.status(torrent_handle::query_save_path | torrent_handle::query_name);
 std::ofstream out((st.save_path
 + "/" + st.name + ".fastresume").c_str()
 , std::ios_base::binary);
 out.unsetf(std::ios_base::skipws);
 bencode(std::ostream_iterator<char>(out), *rd->resume_data);
 --outstanding_resume_data;
 }
      .. note:: Note how ``outstanding_resume_data`` is a global counter in this example. This is deliberate, otherwise there is a race condition for torrents that was just asked to save their resume data, they posted the alert, but it has not been received yet. Those torrents would report that they don't need to save resume data again, and skipped by the initial loop, and thwart the counter otherwise.

    • saveResumeData

      public void saveResumeData()
      Similar to calling saveResumeData(resume_data_flags_t) with empty flags.

    • isValid

      public boolean isValid()
      Returns true if this handle refers to a valid torrent and false if it hasn't been initialized or if the torrent it refers to has been aborted. Note that a handle may become invalid after it has been added to the session. Usually this is because the storage for the torrent is somehow invalid or if the filenames are not allowed (and hence cannot be opened/created) on your filesystem. If such an error occurs, a file_error_alert is generated and all handles that refers to that torrent will become invalid.
      Returns:

    • makeMagnetUri

      public String makeMagnetUri()
      Generates a magnet URI from the specified torrent. If the torrent handle is invalid, null is returned.
      Returns:

    • getUploadLimit

      public int getUploadLimit()

    • setUploadLimit

      public void setUploadLimit(int limit)

    • getDownloadLimit

      public int getDownloadLimit()

    • setDownloadLimit

      public void setDownloadLimit(int limit)

    • forceRecheck

      public void forceRecheck()
      This method puts the torrent back in a state where it assumes to have no resume data. All peers will be disconnected and the torrent will stop announcing to the tracker. The torrent will be added to the checking queue, and will be checked (all the files will be read and compared to the piece hashes). Once the check is complete, the torrent will start connecting to peers again, as normal.

    • forceReannounce

      public void forceReannounce(int seconds, int tracker_index, reannounce_flags_t flags)

    • forceReannounce

      public void forceReannounce(int seconds, int tracker_index)

    • forceReannounce

      public void forceReannounce(int seconds)

    • forceReannounce

      public void forceReannounce()
      Force this torrent to do another tracker request, to receive new peers. The ``seconds`` argument specifies how many seconds from now to issue the tracker announces.

      If the tracker's ``min_interval`` has not passed since the last announce, the forced announce will be scheduled to happen immediately as the ``min_interval`` expires. This is to honor trackers minimum re-announce interval settings.

      The ``tracker_index`` argument specifies which tracker to re-announce. If set to -1 (which is the default), all trackers are re-announce.

    • forceDHTAnnounce

      public void forceDHTAnnounce()
      Announce the torrent to the DHT immediately.

    • trackers

      public List<AnnounceEntry> trackers()
      Will return a sorted list with the trackers of this torrent.

      The announce entry contains both a string url which specify the announce url for the tracker as well as an int tier, which specifies the order in which this tracker is tried.

      Returns:
      the list of trackers

    • scrapeTracker

      public void scrapeTracker()
      Will send a scrape request to the tracker. A scrape request queries the tracker for statistics such as total number of incomplete peers, complete peers, number of downloads etc.

      This request will specifically update the ``num_complete`` and ``num_incomplete`` fields in the torrent_status struct once it completes. When it completes, it will generate a scrape_reply_alert. If it fails, it will generate a scrape_failed_alert.

    • replaceTrackers

      public void replaceTrackers(List<AnnounceEntry> trackers)
      If you want libtorrent to use another list of trackers for this torrent, you can use replaceTrackers(List) which takes a list of the same form as the one returned from trackers() and will replace it. If you want an immediate effect, you have to call forceReannounce().

      The updated set of trackers will be saved in the resume data, and when a torrent is started with resume data, the trackers from the resume data will replace the original ones.

      Parameters:
      trackers - the list of trackers
      See Also:

    • addTracker

      public void addTracker(AnnounceEntry tracker)
      This method will look if the specified tracker is already in the set. If it is, it doesn't do anything. If it's not in the current set of trackers, it will insert it in the tier specified in the AnnounceEntry.

      The updated set of trackers will be saved in the resume data, and when a torrent is started with resume data, the trackers from the resume data will replace the original ones.

    • addUrlSeed

      public void addUrlSeed(String url)

    • removeUrlSeed

      public void removeUrlSeed(String url)

    • urlSeeds

      public List<String> urlSeeds()
      Return a set of the url seeds currently in this torrent. This list is based on BEP 19.
      Returns:
      the url seed list

    • addHttpSeed

      public void addHttpSeed(String url)

    • removeHttpSeed

      public void removeHttpSeed(String url)

    • httpSeeds

      public List<String> httpSeeds()
      Return a set of the url seeds currently in this torrent. This list is based on BEP 17.
      Returns:
      the url seed list

    • pieceAvailability

      public int[] pieceAvailability()
      Returns an array with the availability for each piece in this torrent. libtorrent does not keep track of availability for seeds, so if the torrent is seeding the availability for all pieces is reported as 0.

      The piece availability is the number of peers that we are connected that has advertised having a particular piece. This is the information that libtorrent uses in order to prefer picking rare pieces.

      Returns:
      the array with piece availability

    • piecePriority

      public void piecePriority(int index, Priority priority)

    • piecePriority

      public Priority piecePriority(int index)

    • prioritizePieces

      public void prioritizePieces(Priority[] priorities)

    • piecePriorities

      public Priority[] piecePriorities()

    • filePriority

      public void filePriority(int index, Priority priority)
      index must be in the range [0, number_of_files).

      The priority values are the same as for piece_priority().

      Whenever a file priority is changed, all other piece priorities are reset to match the file priorities. In order to maintain sepcial priorities for particular pieces, piece_priority() has to be called again for those pieces.

      You cannot set the file priorities on a torrent that does not yet have metadata or a torrent that is a seed. ``file_priority(int, int)`` and prioritize_files() are both no-ops for such torrents.

      Parameters:
      index -
      priority -

    • filePriority

      public Priority filePriority(int index)
      index must be in the range [0, number_of_files).

      queries or sets the priority of file index.

      Parameters:
      index -
      Returns:

    • prioritizeFiles

      public void prioritizeFiles(Priority[] priorities)
      Takes a vector that has at as many elements as there are files in the torrent. Each entry is the priority of that file. The function sets the priorities of all the pieces in the torrent based on the vector.
      Parameters:
      priorities - the array of priorities

    • filePriorities

      public Priority[] filePriorities()
      Returns a vector with the priorities of all files.
      Returns:
      the array of priorities.

    • setPieceDeadline

      public void setPieceDeadline(int index, int deadline)
      This function sets or resets the deadline associated with a specific piece index (``index``). libtorrent will attempt to download this entire piece before the deadline expires. This is not necessarily possible, but pieces with a more recent deadline will always be prioritized over pieces with a deadline further ahead in time. The deadline (and flags) of a piece can be changed by calling this function again.

      If the piece is already downloaded when this call is made, nothing happens, unless the alert_when_available flag is set, in which case it will do the same thing as calling read_piece() for ``index``.

      Parameters:
      index -
      deadline -

    • setPieceDeadline

      public void setPieceDeadline(int index, int deadline, deadline_flags_t flags)
      This function sets or resets the deadline associated with a specific piece index (``index``). libtorrent will attempt to download this entire piece before the deadline expires. This is not necessarily possible, but pieces with a more recent deadline will always be prioritized over pieces with a deadline further ahead in time. The deadline (and flags) of a piece can be changed by calling this function again.

      The ``flags`` parameter can be used to ask libtorrent to send an alert once the piece has been downloaded, by passing alert_when_available. When set, the read_piece_alert alert will be delivered, with the piece data, when it's downloaded.

      If the piece is already downloaded when this call is made, nothing happens, unless the alert_when_available flag is set, in which case it will do the same thing as calling read_piece() for ``index``.

      Parameters:
      index -
      deadline -
      flags -

    • resetPieceDeadline

      public void resetPieceDeadline(int index)
      Removes the deadline from the piece. If it hasn't already been downloaded, it will no longer be considered a priority.
      Parameters:
      index -

    • clearPieceDeadlines

      public void clearPieceDeadlines()
      Removes deadlines on all pieces in the torrent. As if resetPieceDeadline(int) was called on all pieces.

    • fileProgress

      public long[] fileProgress(file_progress_flags_t flags)
      This function fills in the supplied vector, or returns a vector, with the number of bytes downloaded of each file in this torrent. The progress values are ordered the same as the files in the torrent_info.

      This operation is not very cheap. Its complexity is *O(n + mj)*. Where *n* is the number of files, *m* is the number of currently downloading pieces and *j* is the number of blocks in a piece.

      The ``flags`` parameter can be used to specify the granularity of the file progress. If left at the default value of 0, the progress will be as accurate as possible, but also more expensive to calculate. If ``torrent_handle::piece_granularity`` is specified, the progress will be specified in piece granularity. i.e. only pieces that have been fully downloaded and passed the hash check count. When specifying piece granularity, the operation is a lot cheaper, since libtorrent already keeps track of this internally and no calculation is required.

    • fileProgress

      public long[] fileProgress()
      This function fills in the supplied vector with the number of bytes downloaded of each file in this torrent. The progress values are ordered the same as the files in the torrent_info. This operation is not very cheap. Its complexity is *O(n + mj)*. Where *n* is the number of files, *m* is the number of downloading pieces and *j* is the number of blocks in a piece.
      Returns:
      the file progress

    • savePath

      public String savePath()
      The path to the directory where this torrent's files are stored. It's typically the path as was given to async_add_torrent() or add_torrent() when this torrent was started.
      Returns:

    • name

      public String name()
      The name of the torrent. Typically this is derived from the .torrent file. In case the torrent was started without metadata, and hasn't completely received it yet, it returns the name given to it when added to the session.
      Returns:
      the name

    • moveStorage

      public void moveStorage(String savePath, MoveFlags flags)
      Moves the file(s) that this torrent are currently seeding from or downloading to. If the given savePath is not located on the same drive as the original save path, the files will be copied to the new drive and removed from their original location. This will block all other disk IO, and other torrents download and upload rates may drop while copying the file.

      Since disk IO is performed in a separate thread, this operation is also asynchronous. Once the operation completes, the StorageMovedAlert is generated, with the new path as the message. If the move fails for some reason, StorageMovedFailedAlert generated instead, containing the error message.

      The flags argument determines the behavior of the copying/moving of the files in the torrent.

      Files that have been renamed to have absolute paths are not moved by this function. Keep in mind that files that don't belong to the torrent but are stored in the torrent's directory may be moved as well. This goes for files that have been renamed to absolute paths that still end up inside the save path.

      Parameters:
      savePath - the new save path
      flags - the move behavior flags

    • moveStorage

      public void moveStorage(String savePath)
      Sames as calling moveStorage(String, MoveFlags) with empty flags.
      Parameters:
      savePath - the new path
      See Also:

    • renameFile

      public void renameFile(int index, String newName)
      Renames the file with the given index asynchronously. The rename operation is complete when either a FileRenamedAlert or FileRenameFailedAlert is posted.
      Parameters:
      index -
      newName -