rutorrent: upgrade 3.10 => 4.1.5 #5617
Conversation
|
Spotted issue: after upgrading from 3.10 to 4.0.2 the below message is shown in the web UI: |
smaarn
force-pushed
the
rutorrent/dsm-7/upgrade-to-4
branch
from
22f59c6
to
ad70345
Compare
|
Hey @smaarn, I was looking at this package for inspiration with more robust UI wizards. I found a logic bug in the install wizard logic which I pushed a commit 7820b1c for you as I'm using the same code in the Transmission 4 package I'm working on. Regarding the recent conversation on package dependencies, I also noted a few other things:
Let me know if you need any assistance. You can probably take a look at the work I'm doing in #5619 for some examples on the resource file if needed. |
Hey @mreid-tt
Issuing an MR to fix the various reported issues, feel free to elaborate on those. |
smaarn
force-pushed
the
rutorrent/dsm-7/upgrade-to-4
branch
from
42cac20
to
e88bc13
Compare
|
Just wanted to give my thanks for the dedication and hard work to make the v3 upgrade to v4 happen. |
Hello, I'm one of the ruTorrent maintainers. The reason for the first two errors is because the |
Thanks a lot for the hints! I must confess I haven't had time to work more on this MR in the past weeks but that's going to help a lot ! Will try having a look this week end / next week. |
|
Not a problem. Also, ruTorrent |
smaarn
force-pushed
the
rutorrent/dsm-7/upgrade-to-4
branch
from
e88bc13
to
1b85026
Compare
smaarn
changed the title
spk/rutorrent/src/service-setup.sh
Outdated
| echo ' $throttleMaxSpeed = 327625*1024; // DO NOT EDIT THIS LINE!!! DO NOT COMMENT THIS LINE!!!' >> ${RTORRENT_RC} | ||
| echo " // Can't be greater then 327625*1024 due to limitation in libtorrent ResourceManager::set_max_upload_unchoked function." >> ${RTORRENT_RC} | ||
| echo " \$al_diagnostic = true; // Diagnose auto-loader. Set to \"false\" to make composer plugins work." >> ${RTORRENT_RC} | ||
| echo " \$localHostedMode = false; // Set to true if rTorrent is hosted on the SAME machine as ruTorrent" >> ${RTORRENT_RC} |
There was a problem hiding this comment.
It's recommended to change $localHostedMode to true. It will call exec('command -v '.$exe); from PHP when looking for binary paths. This improves loading times by avoiding unnecessary XML requests to rtorrent.
The reason why this optimization is not enabled by default is because some people host ruTorrent on a different machine. It's required to maintain compatibility, so it works out of the box. This doesn't apply here.
There was a problem hiding this comment.
Thanks for the catch !
Will be also changing the default value (since this is solely focusing on upgrading 3.10 installations)
There was a problem hiding this comment.
Should be good now, unless I missed something ?
smaarn
changed the title
|
Are there any plans to support nginx as a backend or Apache will remain as hard dependency for rutorrent installation? |
|
@mreid-tt thanks for the testing for With regards to the dependency it's declared here, right ? |
|
Ahh, you are correct (I didn't re-run tests for nginx only but was recalling my experience with ownCloud - updated above). Sorry that I missed those P.S. Regarding the default web server being nginx, from my testing with ownCloud, regardless of whether Apache is installed or not the actual front-end server seems to be nginx. With Apache installed, nginx receives the request and then passes it onto Apache (again, from my testing with ownCloud) so that Apache specific page processing can occur. |
|
I submitted #5727. Waiting for this PR to know which |
|
@smaarn, is there anything else required before this is merged? |
|
Wonder, while a it do you want to bump to py311? I've started with deluge and other will have to follow eventually... |
@th0ma7 will be having a look at it. It seems that python adherence is minimal and I don't see why it wouldn't work. The only concern I could have is that the only used library (cloudscraper) isn't flagged as officially compatible with Python 3.11. To be fair it's not even flagged as compatible with Python 3.10 so it may be a nobrainer :D |
|
Let me know if you need assistance. Ideally it requires minimal changes to your makefile and service-setup script. |
It was indeed a no-brainer. Done. |
I'll do some testing in DSM 6 and 7 later this evening for my review. |
|
Not finished with my testing yet but I am unable to load the web interface when I upgrade from the current v3.10-14 on DSM 6.2. I did notice the following oddities during the upgrade: /var/log/packages/rutorrent.log /var/packages/rutorrent/var/rtorrent.log This results in the web interface just stuck on So I'm not quite sure why the file is being ignored but I suspect that without it the web interface does not load? EDIT: I think it was something screwy in my web browser. Did a clean install and the same warnings came up with the web page still not loading. I then opened the browser in a private window and the web interface loaded just fine. Proceeding with other testing. EDIT: I was able to confirm that both of the above warnings also occur on a clean install of v3.10-14 so nothing unique to this version. After clearing my browser cache and re-doing the same upgrade it was able to load the web interface just fine (despite the warnings). There was one warning in the server log: This appeared to be something in the config so I tried opening the settings and this screen failed to show with additional errors in the log: Could the new commands in the |
|
Further to the above, I re-did a clean install on DSM 6.2 and after the web interface loads, I attempted to open the settings page and the same errors came up in the log: Something about the configuration file is preventing the |
|
Wonder if this isn't the right time to stop providing dsm6 support when its becoming to much of a hassle to maintain. For instance deluge i dropped dsm6 support as older libtorrent doesn't build anymore with newer boost. The current rutorrent online version for dsm6 works, then lets keep it that way and only update dsm7 for now on. Just my two cents... |
|
Unfortunately the issue is not DSM specific but rather rutorrent version specific. On DSM 7.2 our deployment behaves pretty much the same: /var/log/packages/rutorrent.log /var/packages/rutorrent/var/rtorrent.log In the Web UI on opening we see the following errors when attempting to open the settings screen: None of the above errors in the Web UI were present in the previous version of rutorrent. |
Regarding the above issue, this is not in fact an error but a message advising that the default config file is not being used. See linuxserver/docker-rutorrent#88 (comment) for information on this. |
|
@smaarn... Okay, so I found the issue. Both with DSM 6 and DSM 7 the upgrades and install worked well. The main challenge was my local web browser cache. On upgrade I realise that it is trying to use some previously cached data that is causing the Web UI to throw several errors (as noted above). The main indicator was that the title of the browser window was still saying ruTorrent v3.10. When I clear my browser cache and reload the window the title changes to ruTorrent v4.1.5 and all the errors go away. If we have any reports of the above types of errors, we need to advise users to clear their cache (especially if they are using Firefox like me). |
It will not be required to clear your cache moving forward. ruTorrent |
mreid-tt
added
status/published
Description
Upgrade rutorrent 3.10 to 4.1.5 + migrated to python 3.11
Checklist
all-supportedcompleted successfullyType of change
Testing
Binaries are available here: https://github.com/smaarn/spksrc/releases/tag/rutorrent-4.1.5-rc-1