Feature/external torrent client #945
Conversation
|
Forgot to add ss of what the changes in UI look like. I also kept the logic for the built in client the same. I don't understand how the translations for each language are inputted - if you have a team to input them or if its up to the author of PR. I only speak/write English, but I can use google translate to the best of my ability if that's something you require.
|
|
If this change is accepted, I feel like #946 would be a good option to add to the structure as well. All it would require is ORing the client object with a new TorrentBox Object/Entity, and then build the python api object out for it. I think one thing that needs discussed (if this is aproved) is the ability to download the files once they are done from the external client. AFAIK, there is no inherit way to do this via qbittorrent, but there is with torrentbox. One potential way to solve this is with a checkmark box that's automatically enabled whenever you are adding a client, and this checkmark would control whether files are downloaded or not, from the client, once they are done Then there could be a corresponding object that's controlled/created for the download method. For TorrentBox, this could be an integration with their existing download solution, and for qbittorrent, this could be an implementation of the sftp protocol to use ssh to download the files. All of this combined with a checkmark box on wether to delete the torrent from the torrent once its completed, should solve all edge cases with downloading files. |
|
Very nice commit, happy to see something like this, although in its current state, there is no simple way to move the file(s) from the external client (even locally hosted) to the client which has Hydra installed. You mentioned that TorBox does this automatically, which is a benefit, and mentioned that SFTP is an option. My suggestion is that there should be an easy to follow guide or even a pre-built qbittorrent docker container already setup with everything you need to download from the external client. You could put qbittorent + webdav host into a simple container which has a completion script ready and set up. This in my opinion would be the simplest way as a qbittorrent instance is already in a docker container. If docker containers arent an option, maybe an rclone instance hosted with webdav that a user can set up. Many seed boxes already support this. It would require much more setup as well as a very thorough guide but would work. In the end I don't honestly see the benefit other than not having to use a VPN on the host system, especially if you already have a home server. It would only be one-time setup and I am sure many users will appreciate it, so in the end I like this idea. Good work, hopefully an author will give more insight than me. |
Yeah, I had a few ways I wanted to try and do this, but I felt that it was best left to try and discuss. I honestly don't even know if a change like this will be accepted.
I was thinking we could maybe do a list of all available download methods per client. Like, if we created a torbox entity/object, we could have a variable inside of the object labeled something like "download method" where it could be an enum of all available download methods for that client. For torbox, it would just be the built in implementation, but for qbittorrent, there could be a list of either sftp, ftp, http, etc. Then as the API is built out to allow for more integrations, this list would grow and so will the amount of implementations per client.
This is a very good idea on how it could work for the end user. However, I feel like we shouldn't limit the possibilities here. A big reason why I did this was so that people with more complex setups could integrate this into their setup. It feels a bit backwards to take this and then limit the possibilities down to a container that the end user has to use. I feel like that as long as it's marketed in the UI for more advanced setups, the end user can do whatever they want with the client, and hydra would step back at that point. Ex: qbittorrent running on a remote seedbox, webdav server running on a raspberry pi, etc.
Another solution might be to have a remote paths setting similar to the arr services. Where you just provide a GUI for mounting remote filesystems in a directory the application can reach. I feel like this limits the possibilities of services that have ddl capabilities, but just another idea. |
|
pls merge |
|
@Masong19hippows could you update your branch fixing the conflicts? |
There was a problem hiding this comment.
also, typo on name file: "preferencesz.ts"
Adding support for external torrent client support as in #667. I only did it with qbittorrent, but i made it so that it is easily expandable. This did also require me to make UI changes to the settings page. I put all of my changes in the "advanced" section. This is where you can select to use a different client.
The UI for changing clients with the dropdown is ugly. The current styling isn't applied to the HTML DataList element for some reason. I tried to make it better, but was unable to do so. This might be something that someone more experienced with webdev can help with.
I definitely want to add more feedback to the user when adding an external client. Something like a test to see if the client is up or not and handling when its not. I just wanted to grab feedback on if a change like this was even welcome before I polished anything.
All of this was tested using my qbittorrent setup running on ubuntu server 20.04. Libtorrent version 2.0.11 and qbittorrent version 4.6.5.