cross-seed
rtorrent injected torrents pause after ~10-20%
I've been seeing behavior where torrents injected via rtorrent start checking as they're injected, but then pause after 10-20% and aren't able to be checked. If I manually force recheck them the same thing happens. Sometimes when I manually recheck them they make it to 100%, but then when I start them they still end up pausing after a short period. The only thing that's able to get them to work is to download the .torrents via the rutorrent interface, delete the torrents, and then readd/move/recheck the torrents. Still an improvement over not cross seeding at all, but it's a bit less automated than I'd like it to be :)
It sounded somewhat similar to https://github.com/JohnDoee/autotorrent/issues/31, but I wasn't able to figure out the issue from there. I also found some threads citing autowatch, so I disabled the autotools plugin entirely but that didn't seem to do it.
I'm using this: https://github.com/crazy-max/docker-rtorrent-rutorrent as my rtorrent/rutorrent setup, so my thought was that it could be an issue on the rtorrent/rutorrent configuration side rather than cross-seed. Does anyone happen to know if https://github.com/crazy-max/docker-rtorrent-rutorrent/blob/master/rootfs/tpls/.rtorrent.rc or https://github.com/crazy-max/docker-rtorrent-rutorrent/blob/master/rootfs/tpls/etc/rtorrent/.rtlocal.rc do anything that would interact weirdly with the method cross-seed uses to inject torrents?
I'm going to continue investigating to see if I can uncover anything - as I said I don't even know which side the issue is on. If anyone has ideas I'd love to hear them!
Taking a cursory look at the config files you linked, I wonder if it's an issue with the files being moved. Do you have rTorrent configured to move files when they finish downloading?
do they say they have missing files?
I don't think so? For shows it can get through checking multiple files and then stall out in the middle of another. I don't see any messages that would indicate that it thinks there's a missing file though. Sometimes it even gets to 100% and then pauses after it starts.
Taking a cursory look at the config files you linked, I wonder if it's an issue with the files being moved. Do you have rTorrent configured to move files when they finish downloading?
Hmm, could be. I do have it configured to move files. Well technically that's part of the base config with the image I linked - it moves files to a folder like completed/<LABEL> when it's done. This like looks like it does the move: https://github.com/crazy-max/docker-rtorrent-rutorrent/blob/7eec97f0a71826f802ddb697706d6abf62815ce4/rootfs/tpls/.rtorrent.rc#L60. Normally I'd use autotools to do it but this image does it via this config.
To me, it's really weird that it makes it through partway and ends up pausing - I'd expect it to either stop at 0 or work entirely if it was some kinda location issue. And as I said, when I remove it and add the torrent back to the same location manually and recheck it all works perfectly. Anyways, I'm still digging into the rtorrent options, I feel like it probably is something to do with one of the schedules or moves.
Is there a way you can figure out whether cross-seed is being invoked before or after the files are done moving?
The solution might just be to add like a 15 seconds sleep if you can't have it wait
Is there a way you can figure out whether cross-seed is being invoked before or after the files are done moving?
The solution might just be to add like a 15 seconds sleep if you can't have it wait
Oh this is on me for not specifying, but it happens for torrents that are already completed and moved to their final destination. I normally run cross-seed every week or so on my whole instance.
Some rtorrent issues seem to stem from using fast-resume. As far as I can see it's enabled by default and not possible to disable?
rutorrent seems to strip fast-resume data from the torrent when you add via the UI (and don't use the fast-resume checkbox).
It might be worth making it possible to disable, at least it might also help debugging.
Speaking of fast resume actually, make sure cross-seed has access to your data files and that they're mapped to the same path as rtorrent has them if you're using docker. In order to prove to the client that the torrent can fast resume, cross-seed has to check the modification time stamps of each file
@mmgoodnow Hmm, I'm relatively sure I tried doing that when I was initially debugging this, but I had removed it because it didn't seem to change anything. I might be misremembering, so I can give it a try again. I also remember reading https://github.com/mmgoodnow/cross-seed/wiki/Docker which didn't list that shared volume as a requirement so I figured I'd be OK.
edit: Actually scratch that, turns out I didn't remove it I just forgot to push the config back up to my personal repo. I've validated via docker exec -it ... bash that both running containers (rutorrent and cross-seed) have access to the same files in the same place
And rtorrent has access to cross-seed's output directory as well I assume?
Any updates here? I'm afraid I don't have much more to offer in the way of debugging. If you can find a consistent minimal reproduction, please let me know
Someone on the Discord had this problem:
I had that issue kinda yesterday but was unable to start them at all, turned out all my other instances had the default rtorrent config with a schedule of untied_directory like that
schedule2 = untied_directory, 5, 5, (cat,"stop_untied=",(cfg.watch),"*.torrent")That has to be disabled ofc
Perfect, looks like that did the trick! Being unfamiliar with rtorrent generally I don't really know what 'untied_directory', or 'stop_untied' mean, but it looks to have worked 🤷 . Maybe this would be helpful to add to the troubleshooting page?
