It was reported (#2161) that enabling/disabling a downloading of a file
is considerably slow on libtorrent 1.0.3, but not on 0.16.x. The problem
is that a function torrent_file() in libttorrent 1.0.3 does a deep copy
of torrent_info, while get_torrent_info() in libtorrent 0.16.x only
returns a reference.
Sizes are now given in bytes.
Dates are Unix timestamps and converted to ISO 8601 in the web UI.
Numbers are not converted to strings.
-1 is returned for undefined values.
Some keys have been splitted:
Torrent list (json/torrents)
* num_seeds: Torrent seeds connected to
* num_complete: Torrent seeds in the swarm
* num_leechs: Torrent leechers connected to
* num_incomplete: Torrent leechers in the swarm
Torrent generic properties (propertiesGeneral/hash)
* total_uploaded: Total data uploaded
* total_uploaded_session: Total data uploaded this session
* total_downloaded: Total data dowloaded
* total_downloaded_session: Total data downloaded this session
* time_elapsed: Torrent elapsed time
* seeding_time: Torrent elapsed time while complete
* nb_connections: Torrent connection count
* nb_connections_limit: Torrent connection count limit
Global transfer info (json/transferInfo)
* dl_info_speed: Global downalod rate
* dl_info_data: Data downloaded this session
* up_info_speed: Global upload rate
* up_info_data: Data uploaded this session
Closes#1524.
This commit implements a map where qbittorrent store a state of
current torrent movings. This commit speed up
torrents moving a bit and also fix a bug when qbittorrent doesn't do
cleanup action when a single torrent is moved several times without
waiting for a previous move to complete.
How it worked before.
Libtorrent has a function torrent_handle::move_storage() that allows to move a
torrent to a specific directory. This function is asynchorous. It means that
this function quits instantaneously and when the actual operation
completes the alert 'storage_moved_alert' or
'storage_moved_failed_alert' will be sent. The storage_moved_alert contains a
torrent_handle and a new path to where the torrent is moved.
During handling of storage_moved_alert, qbittorrent needs not only new path,
but also an old path to perform some of cleanup actions (like removing an old
folder if it is empty). This was achieved by storing a value named
'previous save path' in TorrentPersistentData. A previous save path is
written when move_storage() is issued and is read when
storage_moved_alert is received.
Problems.
This mechanism has two negative aspects:
1. TorrentPersistentData is very slow. As torrent_handle::move_storage() is asynchoronous,
TorrentPersistentData is responsible for more that 99.8% of time
QTorrentHandle::move_storage(). This percent could be higher when there
are lots of torrents and lower when there are few of them.
2. TorrentPersistentData stores only one previous path. But many
move_storage()'s could be issued without waiting for previous to
complete. Subsequent move_storage()'s overwrites previous save path of a
previous move.
A fix.
The fix is simple. Before issueing move_storage() the oldPath is stored in
a special map called 'torrentMoveStates'. When a storage_moved_alert
is received the map is consulted and an alert is handled.
When user moves torrent when previous moving have not yet finished, the
new location is saved in a field 'queuedPath' the same map. When
torrent moving is completed (or failed) qbittorrent attemps to perform
move again to the queued location.
Future direction.
This fix removes one slow read and one slow write to
TorrentPersistentData on torrent moving, but there is still exists
TorrentPersistentData::saveSavePath in handleStorageMovedAlert(), so
overall time for UI hang should be reduced only threefold. A speeding up
TorrentPersistentData should be addressed in a separate commit.
I don't know if I should clean up torrentMoveStates when torrent is
deleted. In any case, torrent could be deleted when corresponding alert
is in alert queue. So if we decide to clean up torrentMoveStates, then
we should not treat receiving alert from unknown torrent as a error.