August 7, 20169 yr 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.
August 7, 20169 yr oh, and the update is ready. look at the other thing regards the webui tomorrow, watching a movie.
August 7, 20169 yr Success on all counts. When I figure out how to successfully reduce the autowatch interval (as opposed to the schedule interval in the rc) I'll post back. Thanks so much. Enjoy your movie!!!
August 12, 20169 yr 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 ^ _ ^)
August 12, 20169 yr 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?
August 15, 20169 yr Problem not solved And how to prevent the creation of folders (completed incoming sessions and watched)? If I change rtorrent.rc = rtorrent crash
August 15, 20169 yr 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
August 16, 20169 yr 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
August 16, 20169 yr 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
August 16, 20169 yr Ok thanks. I am trying to put my old session folder in, and it appears to recognize all of the torrents in the webui, but none are connecting or show up to be sorted in the "State" portion, though I can sort them by tracker. Here is an error it is reporting: [16.08.2016 08:07:08] JS error: [http://192.168.1.50:81/js/webui.js : 1847] TypeError: s is undefined
August 16, 20169 yr 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.
August 16, 20169 yr 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
August 26, 20169 yr 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
August 26, 20169 yr 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.
August 26, 20169 yr Well I never had this issue before this update. I could start and stop it and it would never have to recheck the torrents. Any ideas for a fix? I can't really have it recheck 1TB+ of torrents each time it restarts.
August 26, 20169 yr 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).
August 26, 20169 yr Good info, so in theory if I run docker stop -t 120 <containerid> for rutorrent when I know I need to shut it down for whatever reason, that might be more graceful. Trying it now as I need to add another drive to my array.
August 26, 20169 yr 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
August 26, 20169 yr 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.
August 26, 20169 yr 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.
August 26, 20169 yr 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.
August 26, 20169 yr 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.
August 26, 20169 yr 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.
August 27, 20169 yr 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
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.