Torrent paused and can't resumed if downloaded from magnet

[proninyaroslav]

Hello. This problem is observed only with torrents of the certain tracker - http://forum.tntvillage.scambioetico.org. For example take this torrent http://forum.tntvillage.scambioetico.org/index.php?showtopic=569096. Torrent paused if it downloaded from magnet (this applies to all torrents of this tracker). I also can't resume it, because it immediately stops automatically. If I download from torrent file then this problem is missing. Also this problem is not observed if I delete all trackers from the end of magnet uri (e.g. magnet:?xt=urn:btih:AD838261E23F84886E1219EDF53A8B608A8D5820&dn=Microsoft+Windows+10+v1703+AIO+8+in+1+Aprile+2017.torrent).

I want to warn that I'm using a modified fetchMagnet version from jlibtorrent. App logic requires unlimited time to downloading metadata. Code:

public TorrentDownload fetchMagnet(String uri)
{
    if (uri == null) {
        throw new IllegalArgumentException("Magnet link is null");
    }

    add_torrent_params p = add_torrent_params.create_instance();
    error_code ec = new error_code();
    add_torrent_params.parse_magnet_uri(uri, p, ec);

    if (ec.value() != 0) {
        throw new IllegalArgumentException(ec.message());
    }

    sha1_hash hash = p.getInfo_hash();
    torrent_handle th = null;
    boolean add = false;

    try {
        syncMagnet.lock();

        try {
            th = swig().find_torrent(hash);
            if (th != null && th.is_valid()) {
                add = false;
                if (callback != null) {
                    callback.onMetadataExist(hash.to_hex());
                }

            } else {
                add = true;
            }

            if (add) {
                p.setName(uri);
                p.setSave_path(uri);

                long flags = p.getFlags();
                flags &= ~add_torrent_params.flags_t.flag_auto_managed.swigValue();
                flags |= add_torrent_params.flags_t.flag_upload_mode.swigValue();
                flags |= add_torrent_params.flags_t.flag_stop_when_ready.swigValue();
                p.setFlags(flags);

                ec.clear();
                th = swig().add_torrent(p, ec);
                th.resume();
            }

        } finally {
            syncMagnet.unlock();
        }

    } catch (Exception e) {
        if (add && th != null && th.is_valid()) {
            swig().remove_torrent(th);
        }

        throw new Exception(e);
    }

       ...
 }

I don't delete torrent handle that remains after receiving metadata and I use it for the subsequent downloading this torrent. This is probably a bad example of using this code, but it works fine for all torrents, except torrents of this tracker. This problem is not observed in the original version of fetchMagnet, and also if I delete and create torrent handle again.

[aldenml]

sorry for the delay, can't give you an ETA now for the review of this issue

[proninyaroslav]

Ok, I'll wait.

[proninyaroslav]

Main thread with detail problem description https://github.com/proninyaroslav/libretorrent/issues/93#issuecomment-316372311

[proninyaroslav]

Is there any progress in solving this problem?

[aldenml]

hi @proninyaroslav, I'm still very busy with three particular native crashes in libtorrent, but I want to ask you: Is the "requires unlimited time to downloading metadata" your original problem to not use the fetchMagnet? You can pass the maximum integer as a timeout, and that's essentially infinity

[proninyaroslav]

Нes, this is a good idea, but there are several unpleasant moments:

• operation is not asynchronous, if you don't use a separate thread.
• after receiving metadata, the torrent is deleted from the session. If user add a torrent to the downloading list when metadata has not yet been received, you will have to add it again.

At the moment, the solution of this problem is to remove TorrentHandle and add it again.

[aldenml]

You are right with those undesired issues, fetchMagnet and related API still needs to be evolve more, I try to work on it this week

[proninyaroslav]

Hi. I tested version 1.2.0.13-RC11 and now many trackers that have not worked before are working correctly. But with some still there is the same problem, for example, with this:

magnet:?xt=urn:btih:59066769B9AD42DA2E508611C33D7C4480B3857B&dn=ubuntu-17.04-desktop-amd64.iso&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80&tr=udp%3A%2F%2Ftracker.istole.it%3A6969&tr=udp%3A%2F%2Fopen.demonii.com%3A1337

magnet:?xt=urn:btih:6EA43E8EF81170ECBACA6F82D4A0FF6480D56026&tr=http%3A%2F%2Fbt.t-ru.org%2Fann%3Fmagnet&dn=%D0%98%D1%81%D1%87%D0%B5%D0%B7%D0%BD%D0%BE%D0%B2%D0%B5%D0%BD%D0%B8%D0%B5%20%D0%A5%D0%B0%D1%80%D1%83%D1%85%D0%B8%20%D0%A1%D1%83%D0%B4%D0%B7%D1%83%D0%BC%D0%B8%D0%B8%20%2F%20Suzumiya%20Haruhi%20no%20Shoushitsu%20%2F%20The%20Disappearance%20of%20Haruhi%20Suzumiya%20%5BMovie%5D%20%5B%D0%91%D0%B5%D0%B7%20%D1%85%D0%B0%D1%80%D0%B4%D1%81%D0%B0%D0%B1%D0%B0%5D%20%5BRUS(int)%2C%20JAP%20%2B%20SUB%5D%20%5B2010

[aldenml]

This is fixed with https://github.com/frostwire/frostwire-jlibtorrent/commit/46af86399e8fa3898927ba6e1b20f9211609c720, added a new java API for it, try 1.2.0.15-RC3. I saw you added some workarounds in your project, let me know if this helps to simplify your code. I will close this issue, but feel free to open new ones.

[proninyaroslav]

Ok, thanks, one of these days I'll check it.