Discussion:
[libtorrent] save_resume_data_alert does not come
Alexander Dyagilev
2016-10-04 06:38:21 UTC
Permalink
Hello,

Works fine on Windows.

Mac OS X - have a problem saving fast resume data at app shutdown.

I pause session and call torrent_handle::save_resume_data for the each
torrent in the list.

The problem is that neither save_resume_data_alert nor
save_resume_data_failed_alert events arrives after that. Not even a
single one.

Any suggestions?
sledgehammer999
2016-10-04 12:19:53 UTC
Permalink
How long do you wait for alerts?
Which libtorrent version do you use?
Post by Alexander Dyagilev
Hello,
Works fine on Windows.
Mac OS X - have a problem saving fast resume data at app shutdown.
I pause session and call torrent_handle::save_resume_data for the each
torrent in the list.
The problem is that neither save_resume_data_alert nor
save_resume_data_failed_alert events arrives after that. Not even a
single one.
Any suggestions?
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
Alexander Dyagilev
2016-10-08 02:29:07 UTC
Permalink
Hello,

v1.0.9 rev. ca54dc0.

I've made more investigation on the issue.

It appeared that the events comes finally. But it's take unreasonably
long time for them to appear.

Time differs. It takes about 1-5 minutes usually. Before fast resume
data events I get different another events (on paused session!) about
tracker failures, etc. useless stuff.

I would be great to force LT to generate the data immediately.

Now it's just impossible to save fast resume data on app exit.
Post by sledgehammer999
How long do you wait for alerts?
Which libtorrent version do you use?
Post by Alexander Dyagilev
Hello,
Works fine on Windows.
Mac OS X - have a problem saving fast resume data at app shutdown.
I pause session and call torrent_handle::save_resume_data for the each
torrent in the list.
The problem is that neither save_resume_data_alert nor
save_resume_data_failed_alert events arrives after that. Not even a
single one.
Any suggestions?
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
sledgehammer999
2016-10-09 15:56:11 UTC
Permalink
On session shutdown, you should investigate the type of the incoming
alerts. And ignore every alert except the fastresume success/failure ones.
Don't waste time processing the other alerts. Maybe your thread consumes
time processing the other alerts before reaching the fastresume ones.
Or maybe that's because you have a lot of torrents or big torrents for the
session to cleanup in a timely manner?

PS: I am not an expert on libtorrent, so my suggestions may not apply on
your use cases.
Post by Alexander Dyagilev
Hello,
v1.0.9 rev. ca54dc0.
I've made more investigation on the issue.
It appeared that the events comes finally. But it's take unreasonably
long time for them to appear.
Time differs. It takes about 1-5 minutes usually. Before fast resume
data events I get different another events (on paused session!) about
tracker failures, etc. useless stuff.
I would be great to force LT to generate the data immediately.
Now it's just impossible to save fast resume data on app exit.
Post by sledgehammer999
How long do you wait for alerts?
Which libtorrent version do you use?
Post by Alexander Dyagilev
Hello,
Works fine on Windows.
Mac OS X - have a problem saving fast resume data at app shutdown.
I pause session and call torrent_handle::save_resume_data for the each
torrent in the list.
The problem is that neither save_resume_data_alert nor
save_resume_data_failed_alert events arrives after that. Not even a
single one.
Any suggestions?
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
------------------------------------------------------------
------------------
Post by sledgehammer999
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
Alexander Dyagilev
2016-10-13 12:24:58 UTC
Permalink
I ignore them all.

The problem that fast_resume_data alerts just does not come in a
reasonable amount of time.

LT performs some useless stuff and does not do what it asked for.
Post by sledgehammer999
On session shutdown, you should investigate the type of the incoming
alerts. And ignore every alert except the fastresume success/failure ones.
Don't waste time processing the other alerts. Maybe your thread consumes
time processing the other alerts before reaching the fastresume ones.
Or maybe that's because you have a lot of torrents or big torrents for the
session to cleanup in a timely manner?
PS: I am not an expert on libtorrent, so my suggestions may not apply on
your use cases.
Post by Alexander Dyagilev
Hello,
v1.0.9 rev. ca54dc0.
I've made more investigation on the issue.
It appeared that the events comes finally. But it's take unreasonably
long time for them to appear.
Time differs. It takes about 1-5 minutes usually. Before fast resume
data events I get different another events (on paused session!) about
tracker failures, etc. useless stuff.
I would be great to force LT to generate the data immediately.
Now it's just impossible to save fast resume data on app exit.
Post by sledgehammer999
How long do you wait for alerts?
Which libtorrent version do you use?
Post by Alexander Dyagilev
Hello,
Works fine on Windows.
Mac OS X - have a problem saving fast resume data at app shutdown.
I pause session and call torrent_handle::save_resume_data for the each
torrent in the list.
The problem is that neither save_resume_data_alert nor
save_resume_data_failed_alert events arrives after that. Not even a
single one.
Any suggestions?
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
------------------------------------------------------------
------------------
Post by sledgehammer999
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
Arvid Norberg
2016-10-14 01:19:18 UTC
Permalink
Post by Alexander Dyagilev
I ignore them all.
The problem that fast_resume_data alerts just does not come in a
reasonable amount of time.
LT performs some useless stuff and does not do what it asked for.
what does it do?

to create resume data, libtorrent calls stat() on every file of the
torrent. If you have a torrent with millions of files, or files on a very
slow device (USB stick or network drive) it may take a while, but profiling
is the only way of knowing. Please let us know what the disk thread is
doing while you're waiting.

Since you say you're on OSX, my first guess would be that you stop the
torrents or pause the session before asking for resume data. That means the
file descriptors will be closed (which happens in the disk thread). The
filesystem on OSX (HFS+) does not support sparse files. For this reason,
whenever you close a file, the kernel will block the system call while it
allocates all the gaps in the file on disk and fills them with zeros. If
you just downloaded a small portion of a very large file, especially toward
the end of the file, it can take quite a while for the kernel to do this,
especially on a slow drive.

My guess would be that if you profile you'll see the disk thread stuck in a
call to close().

This is mitigated in libtorrent 1.1.x by having multiple disk threads. You
may want to upgrade.

Even with multiple threads though, destruction of the session object will
still block until the kernel is done with all the files.
--
Arvid Norberg
Continue reading on narkive:
Loading...