Some torrents getting stuck on CHECKING_FILES state about frostwire-jlibtorrent

[gubatron]

how many transfers do you have?

[dessalines]

I'm seeding about 20k torrents, but actual currently uploading is usually no more than 0-2 torrents at a time.

[dessalines]

I just tried to run a forceRecheck(), but it had no effect. The file in the torrent aren't corrupted, they're working fine.

[dessalines]

Also, noticing a lot are getting stuck on CHECKING_RESUME_DATA

[gubatron]

well, if I remember correctly, you want to use your resume data file so you don't have to re-check the files whenever you re-start, specially in a case like this one where you're starting 20k transfers.

perhaps it's just a matter of letting it finish.

Now, if they're getting stuck on CHECKING_RESUME_DATA (I'm not sure), but it might be an issue with your resume data file.

[dessalines]

It shouldn't be doing any checks, since I have the flag_seed_mode set. This is a tough one.

Here's what I can gather from the documentation:
http://libtorrent.org/reference-Session.html#add_torrent_params

If flag_seed_mode is set, libtorrent will assume that all files are present for this torrent and that they all match the hashes in the torrent file. Each time a peer requests to download a block, the piece is verified against the hash, unless it has been verified already. If a hash fails, the torrent will automatically leave the seed mode and recheck all the files. The use case for this mode is if a torrent is created and seeded, or if the user already know that the files are complete, this is a way to avoid the initial file checks, and significantly reduce the startup time.

So I suppose that its doing checks because for some reason the hashes are failing?

Should I reach out to @arvidn on this one?

[aldenml]

Do you think is this some how related: http://sourceforge.net/p/libtorrent/mailman/message/34455679/

[gubatron]

It shouldn't be doing any checks, since I have the flag_seed_mode set.

but then you say that you did this:

I just tried to run a forceRecheck()

so :)

[dessalines]

However, one problem that came out of this was force started torrents
(i.e. not auto-managed) would always be checked immediately and not wait
for any previous torrents to complete checking (causing quite a bit of
disk congestion normally).

That is the case for me, since all my torrents are not auto-managed. All force-started.

I’m proposing solving this by always make every torrent subject to the
active_checking_limit (i.e. the number of torrents that are allowed to
be checked at one time). Regardless of whether it’s auto-managed or not.
This would remove some control, but also restore an important property
currently in 1.0.x.

What complicates my situation, is that I'm using seed_mode=true, which means it doesn't do any initial checks at all. But obviously for me, some hashes are failing, because I have some random torrents that get stuck in either checking_files, or checking_resume_data.

EDIT: It appears all of the ones I'm having trouble with are now getting stuck on checking_resume_data.

@gubatron True I did run forceRecheck() on it, but only for the ones that are getting stuck. Why would a recheck require a save resume file?

[gubatron]

at that point you're right it wouldn't make any sense requiring any of that, ideially after the check is done and seeding begins it should add the information of such torrent to the resume.dat file.

[aldenml]

I will close this, you reported the issue in libtorrent and we do nothing related to it. If you are loading a lot of torrents, the calls to stat files can be queued for a long time if the the underlying filesystem is under presure. Is this a VM or real hardware?

[dessalines]

Real hardware, that's fine to close.