[Support] Linuxserver.io - Rutorrent


Recommended Posts

OK very weird.

 

This rss feed has always worked as entered. I played around and removed the bookmark portion and it loaded, but of course with a butt load of torrents that I don't care about. I put back the bookmark bit and it failed again.

 

Of note is that right now I have no torrents to download because there is nothing new so my bookmarks list is empty.

 

Next I manually added a bookmark at the tracker site and BAM ruTorrent saved the feed and shows only that single bookmark as expected.

 

Soooo like I've said a few times now, this is my problem to deal with now not yours, but I'm adding this for any others that might have a similar problem.

 

In fact it is known: https://github.com/Novik/ruTorrent/issues/1068 it is also in theory fixed, but I wonder if a regression was introduced

 

the old container was pulling the latest git commit, this one is pulling the latest release.

Link to comment

Hello,

 

I have a problem, every time I restart my docker, my label disappears and rechecked all torrents.

 

I did not have this problem before the update

 

Where is that from ? how to set it?

 

(Sorry for my english ^ _ ^)

 

Are you using Unraid?  Which version?

Link to comment

Problem not solved

 

what is the problem ?

 

And how to prevent the creation of folders (completed incoming sessions and watched)?

 

they are created in /downloads on startup by default, you don't have to use them though, you can map another volume for instance and use that.

 

If I change rtorrent.rc = rtorrent crash

 

the rtorrent.rc config is very specific and for more details check out..

https://github.com/rakshasa/rtorrent/wiki/CONFIG-Template

Link to comment

I just updated the container and now am getting this 502 Bad Gateway error:

 

[16.08.2016 06:05:36] Bad response from server: (502 [error,getplugins]) Bad Gateway

[16.08.2016 06:05:36] Bad response from server: (502 [error,getuisettings]) <html> <head><title>502 Bad Gateway</title></head> <body bgcolor="white"> <center><h1>502 Bad Gateway</h1></center> <hr><center>nginx/1.10.1</center> </body> </html>

 

Have tried restarting a couple times, no change

Link to comment

I just updated the container and now am getting this 502 Bad Gateway error:

 

[16.08.2016 06:05:36] Bad response from server: (502 [error,getplugins]) Bad Gateway

[16.08.2016 06:05:36] Bad response from server: (502 [error,getuisettings]) <html> <head><title>502 Bad Gateway</title></head> <body bgcolor="white"> <center><h1>502 Bad Gateway</h1></center> <hr><center>nginx/1.10.1</center> </body> </html>

 

Have tried restarting a couple times, no change

 

read from here onwards.

http://lime-technology.com/forum/index.php?topic=47299.msg488637#msg488637

Link to comment

As someone who just did that ... hmmmm... is there a chance you didn't stop all torrents before you shut down the old docker? I can't be sure that is your problem but I have found sessions of most things don't like it if you don't close things out properly. In this case stop the torrents, then shut down the container, then copy session data, start the container, and start the torrents. Sort of how yuo have to stop the Plex server before you go copying the Library or it won't work; or used to not work at least.

 

Frankly I wish we had a more graceful shut down of the container because without stopping the torrents your tracker will not be notified of the stoppage and will register that you are seeding the same file twice until it ages out of their system. In a typical application shutdown like utorrent on windows at least exiting the application also first generates a torrent stop being sent to the tracker. We can't exit the application in the docker and docker shutdown just seems to kill it. Next thing I know my tracker is blocking me for too many seeds until they time out :( But that is a tracker issue and not related to your problem exactly.

Link to comment

Ok thank you, I tried that and was not having success, but while doing that I figured out my port was closed, and opening / mapping it appears to have solved all my issues.  I take it I was not supposed to use my old port mapping configuration that is saved as a docker template?

 

Should I start over without the template or is it fine now that I opened the port?  Thanks

Link to comment
  • 2 weeks later...

So I upgraded, copied over my session folder and despite having to check a handful of torrents, all seemed to be good.

 

However my settings don't seem to be saving, and I restarted it and it had to check a (large) handful or torrents again. So, again, it seems something is not saving with some files, like the state of a bunch of torrents. Are there some permissions that need to be fixed?

 

Here is my run command: docker run -d --name="rutorrent" --net="bridge" -e TZ="America/Denver" -e HOST_OS="unRAID" -e "PUID"="99" -e "PGID"="100" -p 8085:80/tcp -p 51413:51413/tcp -p 6881:6881/udp -v "/mnt/user/downloads/":"/downloads":rw -v "/mnt/user/":"/unraid":rw -v "/mnt/cache/appdata/rutorrent":"/config":rw linuxserver/rutorrent

Link to comment

So I upgraded, copied over my session folder and despite having to check a handful of torrents, all seemed to be good.

 

However my settings don't seem to be saving, and I restarted it and it had to check a (large) handful or torrents again. So, again, it seems something is not saving with some files, like the state of a bunch of torrents. Are there some permissions that need to be fixed?

 

Here is my run command: docker run -d --name="rutorrent" --net="bridge" -e TZ="America/Denver" -e HOST_OS="unRAID" -e "PUID"="99" -e "PGID"="100" -p 8085:80/tcp -p 51413:51413/tcp -p 6881:6881/udp -v "/mnt/user/downloads/":"/downloads":rw -v "/mnt/user/":"/unraid":rw -v "/mnt/cache/appdata/rutorrent":"/config":rw linuxserver/rutorrent

 

 

permissions are all or nothing, all of your torrents would behave the same if that were the case.

i suspect it's more to do with the nature of docker itself , stop / restart the container on some instances can be likened to basically pulling the plug on a running computer.

Link to comment

So I upgraded, copied over my session folder and despite having to check a handful of torrents, all seemed to be good.

 

However my settings don't seem to be saving, and I restarted it and it had to check a (large) handful or torrents again. So, again, it seems something is not saving with some files, like the state of a bunch of torrents. Are there some permissions that need to be fixed?

 

Here is my run command: docker run -d --name="rutorrent" --net="bridge" -e TZ="America/Denver" -e HOST_OS="unRAID" -e "PUID"="99" -e "PGID"="100" -p 8085:80/tcp -p 51413:51413/tcp -p 6881:6881/udp -v "/mnt/user/downloads/":"/downloads":rw -v "/mnt/user/":"/unraid":rw -v "/mnt/cache/appdata/rutorrent":"/config":rw linuxserver/rutorrent

 

 

permissions are all or nothing, all of your torrents would behave the same if that were the case.

i suspect it's more to do with the nature of docker itself , stop / restart the container on some instances can be likened to basically pulling the plug on a running computer.

 

Sparkly I can't tell, are you this dockers dev / maintaner?

Was looking at wrong Git ... I see that you are sooooo

 

Would it be possible to modify the shutdown command to include a stop of all torrents with a wait period? that would have two benefits 1) give rtorrent a chance to notify the trackers and 2) let rtorrent itself set the torrent's state correctly

 

I don't think I'm telling you anything new but the start of my research leads me here:

 

https://www.ctl.io/developers/blog/post/gracefully-stopping-docker-containers/

 

The next question of course is, what does rtorrent need for a graceful shutdown

 

And sheesh I should just wait to write this stuff but I'm impatient and like to record what I learn in steps ...

 

rtorrent wants to see a SIGINT sent.

https://bbs.archlinux.org/viewtopic.php?id=118686

 

Here I go again ... thinking ... is this even controllable by the container? I feel like this might be more of an unRaid GUI issue for bonienl. He might need to make it possible for the docker author, or the user, to edit what is sent when we click the STOP option in the Docker UI.

 

This guys docker https://github.com/kfei/docktorrent has a note

docker stop can gracefully shutdown rTorrent if you give it more time by docker stop -t 120 (which means 120 seconds to time out).
Link to comment

yup. of course the easier way if you already have to do something manual is to select all your torrent, click stop, wait, then kill the docker as usual [shrug]. That should have the same effect of notifying the tracker and ensuring your state is clean. but of course then you have to restart the torrents and that can be annoying if you have choosen not to seed everything you have.

 

just a though for how little I know it is worth :)

Link to comment

Didn't seem to make a difference. It's still rechecking a bunch of torrents :(

 

I should add: These are torrents that existed before this docker was changed to a version that used a slightly different appdata structure. I copied the rtorrent_sess folder from my backup (that I did right before upgrading to 6.2-RC4 and thus updated the docker also).

Edit 2: Some of the torrents that need rechecking existed before the upgrade, and some were added after.

Link to comment

yeah you might have other issue i guess. Best i can say is a clean slate start as a test. keep your old session and appdata, but first eliminate any question that there is something bad left over from your old install.

 

I do know though that rtorrent still might benefit from some work on a graceful shut down given how my trackers claim I'm seeding from multiple locations if I don't stop all my torrents before a restart. I don't have that problem with my windows client when i shut it down because it isn't having its virtual plug pulled.

Link to comment

Renamed my appdata folder so I could start from scratch for testing. Added one torrent, checked it to 100% and started seeding it. Then I restarted the docker. Upon restart it was stopped, hit start and it rechecked it again. So that would imply that my old appdata folder doesn't necessarily have anything wrong with it.

 

Also on a clean appdata start, changing settings are still not sticking. Such as changing the default directory for downloads, it always reverts back. Clearly this new image has issues.

Link to comment

Clearly this new image has issues.

 

no it doesn't...

 

it has the hash set to check in the rtorrent.rc file. turn it off if it's a pain.

 

This one?

 

check_hash = no

 

I believe that option is only to do a recheck on completion of a download. Either way, the setting is off according to my rtorrent.rc file.

Link to comment

Clearly this new image has issues.

 

no it doesn't...

 

it has the hash set to check in the rtorrent.rc file. turn it off if it's a pain.

 

This one?

 

check_hash = no

 

I believe that option is only to do a recheck on completion of a download. Either way, the setting is off according to my rtorrent.rc file.

 

"The check_hash option executes a hash check when a torrent download is complete or rTorrent is started. When starting, it checks for errors in your completed files. "

 

source...

 

https://wiki.archlinux.org/index.php/RTorrent

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.