Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RSS subscriptions can only be updated manually and cannot be updated regularly #2529

Closed
4 tasks done
lottelucky opened this issue Jul 5, 2023 · 9 comments
Closed
4 tasks done

Comments

@lottelucky
Copy link

Please complete the following tasks.

  • Web browser cache cleared
  • Link provided to install script if applicable
  • Not using broken rtinst install script
  • Web browser, ruTorrent, PHP and OS version provided

Tell us about your environment

Web Browser: Google Chrome 114.0.5735.199
ruTorrent: v4.15-15
PHP: PHP 7.4
OS: Synology DSM 6.2

Tell us how you installed ruTorrent

ruTorrent v4.1.5-15 installed through Synology's third-party component library SynoCommunity

Describe the bug

It is possible to manually update the RSS subscription, but if the automatic update is set, the RSS update will not respond when the countdown ends.
Close the browser and open it after a while, but there is still no update of RSS.

Steps to reproduce

No response

Expected behavior

No response

Additional context

No response

@stickz
Copy link
Collaborator

stickz commented Jul 14, 2023

Hi @lottelucky, I would highly recommend asking the SynoCommunity if they support the php-dom extension. It's highly recommended to have this extension for ruTorrent. Furthermore, they are also running an outdated version of PHP. ruTorrent v4.1 is tested and confirmed to support PHP 8. It should be relatively simplistic to upgrade the PHP version.

If the problem still persists after modernizing their setup configuration of ruTorrent, we can take a look on our end to see if there was a regression with the improved RSS support, that was implemented in ruTorrent v4.1.

Any additional information related to this problem would be helpful. Sometimes ruTorrent will display a stack trace with an error in your web developer console. You can go to Settings -> More Tools -> Developer Tools -> Console to see if this is the case. Also, you can try enabling the error_log in the php.ini file, to see if there is a problem with the web server backend.

@stickz stickz added bug v4.1 need feedback Waiting for additional information. labels Aug 11, 2023
Copy link

stale bot commented Mar 17, 2024

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.

@stale stale bot added the wontfix label Mar 17, 2024
@lostnihilist
Copy link

I'm having the same problem. RSS is not running automatically after updating to 4.3.6 from 3.9 and from Debian bullseye to bookworm. I've always had execute = {sh,-c,/usr/bin/php /path/to/rutorrent/php/initplugins.php <user> &} in my rtorrent.rc. I've tried switching that to execute2, to no avail (shutting down apache and rtorrent after making the change and restarting). What is required to trigger RSS is not just loading the webif, but selecting on each feed and manually clicking "Update Feed". I do not see anything obviously related in the browser console.

Using Firefox 130, ruTorrent 4.3.6, PHP 8.2 and Debian bullseye. ruTorrent installed by cloning git and checking out the v4.3.6 tag.

Apache access log:

  • automatic refresh: <IP> - <user> [18/Sep/2024:11:33:48 -0700] "POST /rutorrent/plugins/rss/action.php HTTP/1.1" 200 16648 "https://<domain>/rutorrent/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:130.0) Gecko/20100101 Firefox/130.0"
  • manual refresh: <IP> - <user> [18/Sep/2024:11:31:26 -0700] "GET /rutorrent/plugins/rss/action.php?mode=refresh&rss=69f4ef3c89a05be7544534329bbc7256 HTTP/1.1" 200 16704 "https://<domain>/rutorrent/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:130.0) Gecko/20100101 Firefox/130.0"

It seems in the RSS plugin, the default mode is "get" and is then changed if the mode is set in the url. But in the switch statement, there is no case for "get". I tried changing the default to "refresh" and restarted apache/rtorrent to see if this helped. It did not. (No indication of curl running). I wonder if that is a function of a POST versus a GET? Or if I'm just offtrack completely. I'm not a PHP programmer, so much more than this is mostly shooting in the dark for me.

I was also wondering if this might have something to do with the time checking logic if the feed gives a minimum interval? I couldn't quite follow what all was happening there.

rutorrent log file is set in conf/config.php, but nothing is logged there

  • $log_file = '/tmp/rutorrent_errors.log';

The only change I make to the standard v4.3.6 is to specify binary locations, change the log file name, and an .htaccess file (confirmed with git diff).

With automatic refresh (based on the timer next to "Feeds" in the webif), I'm not able to detect (through spamming ps aux | grep curl and watching that at a 0.1s interval) anything happening with the automatic refresh. With a manual refresh, I see curl running to grab the feed and feed items, if any.

Potentially related (but probably not), often (but not always) items added via RSS do not get any info on the time at which they are added (so the "added" column in ruTorrent is blank).

@stale stale bot removed the wontfix label Sep 18, 2024
@lostnihilist
Copy link

lostnihilist commented Sep 20, 2024

I must have screwed something up when changing the default to $cmd to "refresh". I took a slightly altered path and added a "get" to the switch statement, saved and restarted apache. And it seems to be working now. I haven't completely restarted everything to see if it works from startup w/o opening a browser. Not sure why changing the default to "refresh" didn't work before. My best guess is that I didn't save the file when I thought I did? I'm also not sure that this is the best way to go about making this change, as there may be reasons to not have the default trigger an action. But it seems to work for me. This is what I changed in 4.3.6 to get things working.

$ git diff
diff --git a/plugins/rss/action.php b/plugins/rss/action.php
<git hashes>
--- a/plugins/rss/action.php
+++ b/plugins/rss/action.php
@@ -76,6 +76,10 @@ switch($cmd)
                        $mngr->update(true);
                break;
        }
+       case "get":
+       {
+               $mngr->update(true);
+       }
        case "refreshgroup":
        {
                if(isset($_REQUEST['rss']))

@lottelucky
Copy link
Author

我已经彻底放弃使用群晖中的组件模式安装rtorrent_rutorrent,改用docker仓库中的最新镜像,省时省力。谢谢以上专家的答疑!
I have completely given up using the component mode in Synology to install rtorrent_rutorrent, and use the latest image in the docker repository instead, saving time and effort. Thank you for your answers!

@lostnihilist
Copy link

Why'd you close this? I was discussing an ongoing issue that's described by this report. Just because you are no longer affected doesn't make the discussion closed if others still are.

As for my testing, it does not appear that RSS works w/o the UI loaded into the browser.

@lottelucky lottelucky reopened this Sep 20, 2024
@lottelucky
Copy link
Author

please continue

@stickz
Copy link
Collaborator

stickz commented Sep 21, 2024

@lostnihilist Please submit a pull request to master. I will merge this fix and push a hotfix. Ensure to add a break to the case statement, so "get" does not follow through to the next case.

@lostnihilist
Copy link

Whoops! I did forget the break! But since this still isn't working on rtorrent startup w/o manually opening the browser, I'm going to wait for a more proper fix (or figuring out whatever might be wrong with my configuration, though I don't see any documents saying that anything should have changed b/w 3.9 and 4.x). I did just notice another issue: the trafic plugin isn't updating stats. Makes me think something may be wrong w/ my setup? Or are there just a lot more broken things than I expected?

@stickz stickz closed this as completed in edb429c Sep 22, 2024
@stickz stickz added Confirmed and removed need feedback Waiting for additional information. labels Sep 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants