after version 7.13.1 upgrade all existing downloads stopped downloading with anynomity enabled

[inekestijnman]

after version 7.13.1 (64) upgrade all existing downloads stopped downloading. if i change anonimity to zero it immediately starts downloading. so it's not my bitdefender (in which tribler is enabled). with ananomity=1 there are no peers seeds found. with anonimity=3 there are seeds found but nothing downloads.

[herrJones]

upvote

[qstokkink]

I just performed a fresh install of 7.13.1 and I cannot reproduce this. Could you provide more info? In particular, it would help us if you could provide a screenshot of the Tunnels / Peers tab in the debug screen (please anonymize the IP/port/mid numbers):

[inekestijnman]

Steps:

I was running a torrent in previous version 17.13.0 , it was downloading with about 300kb/s at 3 HOPS stopped it at 3%

I then updated to 17.13.1 without deleting the appdata folder.

The torrent jumped to status downloading, identified a couple of peers, but with zero download speed.

I made you the requested screenshot nr.1

Then I did an uninstall. Removed the Appdata folder. Ran registry cleaner. And installer again.

Reloaded the torrent. It hung on "initializing ..

I switched to NO ANONIMTY for a second and it immediately downloaded with 52 peers found to 10% in less than a minute.

I changed back to 3 hops and download speed went to zero (status downloading)

I then added a fresh 2nd torrent, which hangs on searching for metadata. I made screenshot 2 of the downloadscreen, this status is unchanged for 30 minutes now...

I made the requested screenshot 3 of the tunnel/peers. No need to anonymize, as it is completely empty.

I am on a surface pro 4 with windows 10 64bit

Van: Quinten Stokkink @.> Verzonden: maandag 15 januari 2024 10:12 Aan: Tribler/tribler @.> CC: inekestijnman @.>; Author @.> Onderwerp: Re: [Tribler/tribler] after version 7.13.1 upgrade all existing downloads stopped downloading with anynomity enabled (Issue #7805)

I just performed a fresh install of 7.13.1 and I cannot reproduce this. Could you provide more info? In particular, it would help us if you could provide a screenshot of the Tunnels / Peers tab in the debug screen (please anonymize the IP/port numbers):

afbeelding.png (view on web) https://github.com/Tribler/tribler/assets/3630389/659c2ccb-2b56-4398-b9c4-5 01c6aedd569

- Reply to this email directly, view it on GitHub https://github.com/Tribler/tribler/issues/7805#issuecomment-1891636441 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ALEMMCDTY4TDWS5MXGMIS3TYO TXFXAVCNFSM6AAAAABBRHVNJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJRGYZTM NBUGE . You are receiving this because you authored the thread. https://github.com/notifications/beacon/ALEMMCEJSR2JXDW2X6BLYYTYOTXFXA5CNFS M6AAAAABBRHVNJ6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT QYAKNS.gif Message ID: @. @.> >

[egbertbouman]

There seems to be something going wrong when creating multi-hop circuits, and I've also seen the case where less circuits are getting created than expected (which could intermittently stop a download). Also, the information in the debug panel doesn't always seem to be correct. I'll investigate this further.

[egbertbouman]

This is a lot harder to reproduce than I originally thought. I was having problems creating 3-hops circuits initially, but after waiting long enough, they would eventually appear. The slowness of multi-hop circuits isn't something we can fix obviously, as that just depends on which node you select for the next relay.

One thing that could slow down or even stop downloads is when circuits are suddenly destroyed. This can always happen, and Tribler does need to deal with this -hopefully rare- situation. So, during testing I periodically destroyed all available circuits to see if Tribler would recover, which it did.

I did notice some problems with circuit management (i.e., how many circuits are created/destroyed), which I'll fix. But I can't reproduce the case where downloads can't recover altogether. Although another user on our forum seems to experience something similar with v7.13.

If anyone can post pictures of the Tunnels / Circuits and Tunnels / Peers tabs (as described above) while they experience the problem, that would be really helpful.

[egbertbouman]

I've finally been able to reproduce this (on Windows, using main and hops=1), but it certainly took a while. Now that I had a chance to take a closer look, I'm not sure this is aTunnelCommunity issue, although considering the amount of traffic that's going through it may very well be a contributing factor.

When the downloads stop, all of the network connectivity seems to stop working as well. Circuits can't be created, peer counts in all communities drop (but not to 0), and the IPv8 socket total_down never changes (i.e., no incoming messages). Changing the hop count to 0 does work, but of course that happens outside of Python.

If the issue indeed started appearing in v7.13.1, it could be related to https://github.com/Tribler/tribler/pull/7677. I wonder if anyone is experiencing similar issues on linux/mac

[synctext]

@inekestijnman @herrJones We making progress trying to fix this one. Thank you for reporting! We now trying to switch 'reactor core' to see if that was the issue.

Coming days we should have some new stable + experimental builds to try out. New stuff should yield a 160 Mbit/sec performance boost for anonymous downloading :grin:

[drew2a]

It looks like a duplicate of

• 7972

[qstokkink]

The newest (upcoming 8.0) version of Tribler includes a different event loop, which has been confirmed to fix this issue.

[inekestijnman]

That would be great. So I'll wait for 8.0. Thanks for the update.

Best regards, Ineke Stijnman ​

Op 21 aug 2024 13:42, om 13:42, "Dr. Quinten Stokkink" @.***> schreef:

The newest (upcoming 8.0) version of Tribler includes a different event loop, which has been confirmed to fix this issue.

-- Reply to this email directly or view it on GitHub: https://github.com/Tribler/tribler/issues/7805#issuecomment-2301846878 You are receiving this because you were mentioned.

Message ID: @.***>