frostwire / frostwire-jlibtorrent

A swig Java interface for libtorrent by the makers of FrostWire. Develop libtorrent based apps with the joy of coding in Java.
http://www.frostwire.com
MIT License
444 stars 137 forks source link

dhtNodes Always 0 #274

Closed lqh995204185 closed 3 weeks ago

lqh995204185 commented 2 years ago

It was good before. The code hasn't changed. I can't get it recently。dhtNodes Always 0

gubatron commented 2 years ago

Please try new jlibtorrent 1.2.16.0 https://github.com/frostwire/frostwire-jlibtorrent/releases/tag/release%2F1.2.16.0

qyzhaojinxi commented 2 years ago

Hi, I test 1.2.16.0.jar. And it didn't work on all my test devices including android11 and android12. No speed, no peers, no dht contacts.

gubatron commented 2 years ago

I've just confirmed the same, I'll be deleting those android jars and uploading new ones, I believe there was a patch missing in the build.

Once I test and they work for me I'll upload the new binaries and will provide MD5 hashes for you to check you have the new ones.

Thank you

gubatron commented 2 years ago

@qyzhaojinxi please try again, just uploaded new android jars

MD5 hashes
e5a831edc666ad7daed368d7a97deaf4  jlibtorrent-android-arm-1.2.16.0.jar
9870ac626a0663245fd93bf1a2aa26ab  jlibtorrent-android-arm64-1.2.16.0.jar
7a8da00a9e26f769ef27ed1e7fdb565b  jlibtorrent-android-x86-1.2.16.0.jar
1a5095c052ae0d17beff397d740953f8  jlibtorrent-android-x86_64-1.2.16.0.jar
gubatron commented 2 years ago

Screenshot_20220422-120406 Screenshot_20220422-120342

qyzhaojinxi commented 2 years ago

@gubatron Thank you. I will try the new ones.

qyzhaojinxi commented 2 years ago

@gubatron Hi, thak for your fix. I have tested the new jar files and they worked well on my devices. But they still don't work on the OPPO Reno 4 pro. It's just like the last version and no speed, no peers, no dht contacts.

igor-rif-shevchenko commented 2 years ago

@gubatron @qyzhaojinxi @lqh995204185 I think I have the same issue (1.2.16.0). Some users reported that nothing downloads. I can't reproduce it on my devices. Several users had Samsung Galaxy but I've tried about 10 devices in Samsung Remote Test Lab and coudn't reproduce that issue. I got logs from one of the users and I've noticed that there is no ListenSucceededAlert, ListenFailedAlert, ExternalIpAlert, LsdPeerAlert, PeerConnectAlert, DhtBootstrapAlert alerts.

igor-rif-shevchenko commented 2 years ago

This seems to be related https://github.com/frostwire/frostwire-jlibtorrent/issues/271

qyzhaojinxi commented 2 years ago

@igor-rif-shevchenko Yes, I think it's the same problem. I can reproduce it on my friend's OPPO Reno 4 pro. It didn't get any alerts. I try to change target 30 to 29 and then worked well. So I think it's about netlink socket and ifaddr sockets. Some devices's kernel are different with others.

qyzhaojinxi commented 2 years ago

Hi, is there any solution for this problem ? There was quit a lot of users meeting this problem. The dhtNodes is always 0.

igor-rif-shevchenko commented 2 years ago

I can confirm, still getting reports that nothing downloads...

ivan1986 commented 2 years ago

can confrm too new lib, md5 same, sdk 29 not download

igor-rif-shevchenko commented 1 year ago

Hi @gubatron , I see that the ticket mentioned above (https://github.com/popcorn-time-ru/popcorn-android/pull/1) says that it's working fine in libtorrent4j, maybe there is some clue how it was fixed there?

qyzhaojinxi commented 1 year ago

@igor-rif-shevchenko I'm not sure if it's the same problem.

I can reproduce it on my friend's OPPO Reno 4 pro. It didn't get any alerts and any speed. I try to change target 30 to 29 and then worked well. So I think it's about netlink socket and ifaddr sockets. Some devices's kernel are different with others.

And I test liretorrent app with libtorrent4j on the same device. It works well.

igor-rif-shevchenko commented 1 year ago

That's the point, if it works with libtorrent4j then we can see how it is different from frostwire-jlibtorrent.

gubatron commented 1 year ago

try adding this to bootstrap your connection to the DHT on your SettingsPack object before creating the SessionParams object

sp.setString(settings_pack.string_types.dht_bootstrap_nodes.swigValue(), "router.silotis.us:6881");
sp.setString(settings_pack.string_types.dht_bootstrap_nodes.swigValue(), "router.bittorrent.com:6881");
sp.setString(settings_pack.string_types.dht_bootstrap_nodes.swigValue(), "dht.transmissionbt.com:6881");
igor-rif-shevchenko commented 1 year ago

@gubatron but those are already added inside SessionManager, am I mising something? I don't use custom settings pack.

    private static String dhtBootstrapNodes() {
        StringBuilder sb = new StringBuilder();

        sb.append("dht.libtorrent.org:25401").append(",");
        sb.append("router.bittorrent.com:6881").append(",");
        sb.append("router.utorrent.com:6881").append(",");
        sb.append("dht.transmissionbt.com:6881").append(",");
        // for DHT IPv6
        sb.append("router.silotis.us:6881");

        return sb.toString();
    }

and @qyzhaojinxi said it works on his device when he changes target 29, that wouldn't work if it was something wrong with settings pack, right?

qyzhaojinxi commented 1 year ago

try adding this to bootstrap your connection to the DHT on your SettingsPack object before creating the SessionParams object

sp.setString(settings_pack.string_types.dht_bootstrap_nodes.swigValue(), "router.silotis.us:6881");
sp.setString(settings_pack.string_types.dht_bootstrap_nodes.swigValue(), "router.bittorrent.com:6881");
sp.setString(settings_pack.string_types.dht_bootstrap_nodes.swigValue(), "dht.transmissionbt.com:6881");

If this code is necessary? Which one is correct comparing with the code in dhtBootstrapNodes?

igor-rif-shevchenko commented 1 year ago

@gubatron do you have any idea what's going on? I keep getting feedback that nothing downloads and just can't do anything about it...

gubatron commented 1 year ago

will look at this on the next update, which could be as soon as this week. I'm on the road now, will be back home by Wednesday.

My guess is that the patch we did for ifnet sockets doesn't work with some android kernels that the maintainers decided to not do as it was dictated by the android project, so the patch ends up breaking connectivity as it tries to use the wrong type of socket

igor-rif-shevchenko commented 1 year ago

@gubatron any news? Does new 1.2.17.0 version have some changes related?

gubatron commented 1 year ago

@igor-rif-shevchenko please give it a try and see if it works now

igor-rif-shevchenko commented 1 year ago

@qyzhaojinxi can you test? I don't have a device with that issue

qyzhaojinxi commented 1 year ago

@igor-rif-shevchenko Sorry about that I can't find the device either. But I will use the latest verison sdk and see the difference about user feedback.

lyxxman commented 1 year ago

There are still such problems