rutorrent will not list torrents when more than 6393 are loaded

[jerryfreak]

Please complete the following tasks.

• [X] Web browser cache cleared
• [X] Link provided to install script if applicable
• [X] Web browser, ruTorrent, PHP and OS version provided

Tell us about your environment

bug is reproducible in all of the following combinations: web browser: chrome and firefox, repeatable in all browsers tried rutorrent 3.10 stable and 4.0 beta3 when either is installed via rtinst script PHP: 7.4 OS: ubuntu 20.04 and 22.04

Tell us how you installed ruTorrent

originally through rtinst script then updated to 4.0 via rutupgrade.

also tried stickz's custom code from here, to no avail _

Describe the bug

rtorrent/rutorrent is stable and uses little resources up to 6393 torrents in the list (most are non-active, i.e. they are checking in with trackers but not making peer connections)

upon adding the 6394th torrent rutorrent loses connection with rtorrent and rutorrent log displays the following error

"bad response from server: (500 [error,list])"

rutorrent is unable to list torrents until they are manually removed from session to bring the number in the list to 6393 or fewer

Steps to reproduce

1. run rtorrent with rutorrent as installed above
2. add torrent #6494 to the list via either rutorrrent gui or rtorrent watch folder

Expected behavior

expected rutorrent to maintain functionality

Additional context

repeatable to the exact number of torrents in the list on multiple machines with multiple OSes and rtorrent/rutorrent versions

[jerryfreak]

this seems to be somehow related to the manner in which rinst script installs

i wanted to install flood to see if i could reproduce the bug in an attempt to isolate the problem to rutorrent

the easiest way to install flood is the swizzin script, i installed a relatively light (for swizzin) install including nginx rtorrent transmission deluge qbittorrent rutorrent flood autodl vsftpd panel ffmpeg

to my surprise rutorrent installed from this package went beyond 6393 with flying colors. in fact i was able to take it out to nearly 11000 torrents with low resource usage, even while running rutorrent concurrently with the more resource-heavy flood (~25% CPU with both, and ~10% CPU with rutorrent alone), and about 5GB of the available 32GB of memory

the swizzin script uses the default 8.1.2 version of php in 22.04, not the 7.4 that is required to install rtinst on 20.04/22.04, perhaps the limitation is in php

[liaralabs]

The limitation you're facing could be a timeout in php execution or perhaps in the scgi socket somehow. This isn't really a problem with ruTorrent, but rather the way the rtinst script has configured the webserver and applications. As you have noted, swizzin doesn't show this behavior (and php7.4 is not to blame as swizzin works perfectly comparably under buster and bullseye which are using older versions of php)

You might consider comparing php.ini between swizzin and rtinst and the pool.d/www.conf files as well. There may be some differences here which explain the behavior. Additionally, the timeout may be on the webserver as well (i.e. nginx/apache timeouts).

If you still have access to the broken instance, you can check the network graph waterfall and see if any specific calls are timing out at oddly specific intervals (i.e. 10s, 20s, 30s, 60s). This will usually indicate something is closing the connection (the webserver or php timeouts) instead of letting it continue. I'd be willing to bet the issue is less the number of torrents, but rather that the one final torrent pushed it over the threshold and it started producing a reliable timeout

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stickz]

Closing this off. The problem was the xml-rpc limitation for sending information. It was not set high enough. This has been resolved on both swizzin and docker-rtorrent-rutorrent by patching the rTorrent software.