-
-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
servarr download #288
servarr download #288
Conversation
servarr mutator system query for download injection of servarr config
Thanks for this, some initial feedback: I think I misunderstood what you had in mind for this feature as it seems to be searching Sonarr and Radarr, when we'd already have the torrent we're after - it would just need sending to Prowlarr's client proxy. I think having that on its own would be a good first step for this feature. I wouldn't rule out some deeper integration with the other apps if it would add value, but if set up correctly Sonarr/Radarr should pick up the fact that you've downloaded a copy of something anyway? Could you maybe elaborate what you had in mind for the Sonarr/Radarr integration, perhaps it isn't needed for the first iteration of this feature? I expect we'll expose this feature as a generic client proxy that can integrate with any suitable client (e.g. qBittorrent), so in terms of the API surface it should be more generic, so the GraphQL parts would probably be under a Your client code is trying to do a lot at the moment, mainly because it's trying to be 3 different clients merged into 1. A good first step would be having that stripped back to do the most basic part of sending a torrent to Prowlarr. If there was going to be integration with Sonarr/Radarr too then they should probably be in separate client adapters or at least with the logic more decoupled. With the web app rewrite underway let's probably look to merge the UI elements into that once that's further along... |
I should explain the concept better. The prowlarr search end point and sonarr / radarr release end points are quite synonymous. GET caches from configured indexers, POST sends specific info hash to configured download client. It's mandatory to cache (GET) before POST. (Not doing GET before POST for all three results in an error stating info hash is not cached). The sonarr / radarr release GET request requires (seriesID, episodeID) or (movieID). Hence the GET requests to other end points to transform external ids that bitmagnet has to internal ids. One issue I have with release GET end point is that it's not possible to filter by indexer. Which means that in case of sonarr / radarr all indexers are searched (would be better if only bitmagnet was searched) Just prowlarr would mean that you would need to configure backdoor functionality in sonarr / radarr to pick up "manually" downloaded content by download client.
Ok -will change from servarr namespace to client name space across graphql specs. Interface spec would effectively be:
From download capability of a client, I noted on discord. I see the *arrs as providing capability to interface to any client. I switched from deluge to qbittorrent to transmission. All that was needed after changing docker compose to install was to do a little config in the *arrs which have UI and testing capabilities. Granted I am maybe thinking too narrow, just download when it comes to a client.
There is maybe a use case bias I am holding here. I regularly find myself using manual search capabilities of sonarr and radarr as they have not found some content I want (configured size constraints or quality profile, configs which I want for auto downloads). When I see something in bitmagnet that I want, I want to trigger download and inclusion in tv / movie libraries. As previously noted functionality wise that are very synonymous, for sonarr / radarr need to transform from external ids to internal ids. If in config only prowlarr api key is configure, prowlarr will be used for all content types. So from that perspective it's a user configuration not automatic that my bias is forced on all users. I switched from starr to resty because I didn't like the amount of code duplication with separate sub-modules for prowlarr, sonarr and radarr. I'll have a look to extract a
I'll move UI elements to a separate branch. |
Okay I haven't gone into depth on what these API's look like (and the documentation seems quite light).
I'm for minimizing duplication but having a lot of big This interface is just off the top of my head but it could be a start. It uses a context object and can return an error. I've put the request in a struct as it might need more parameters later:
|
Docs are quite light, have now coded in python, typesrcipt and go. So have become quite familiar with this specific capability of APIs. Explaining was very useful as it enabled me to see better ways to code it.
I've completely stripped out use of
I've coded this up - and changed servarr to use this interface. I haven't yet got round to stripping out webui changes into a separate branch. For my dev purposes it's been useful that have UI to validate as I went along steps of refactoring. |
Is there more we can add to golift.io/starr to provide all the features you need? Hate to see you writing all this boilerplate code. |
I'd be happy in principle for it to be used. I haven't had an in-depth look at the code yet so I can't give a view on @rraymondgh 's reasons for not using it. It is likely that we'll need a fraction of the functionality available in the API's, and it can be preferable to have full control over a custom implementations of just the bits we need. I've ended up going in that direction with the TMDB integration for example. It probably depends if the Starr libs are extensible in the ways we'd need them to be (and I can't answer that without looking into it properly). In the case of TMDB we needed things like rate limiting, API key validation and retry logic that just couldn't be done nicely with the main TMDB client library for Go. |
Sorry that question was really directed toward @rraymondgh. He opened a feature request in that library, I assume for this implementation. I'm happy to expose or explain any additional functionality you could need. |
Thanks for responding to that feature request. There are a few reasons I switched from starr to resty
Taking third point - this then allows functional code that implements download capability that is 100% common across arrs. There is no need to do any type coalescence between I did experiment with generics before refactoring code to use resty I just could not get it to work. This reasoning is maybe flawed - I'm new to go, the type strict approach is great. Possibly I'm just not seeing how to deal with heterogeneous structs that have very large overlap in an effective way. |
I'm going to move this conversation here so I don't keep clogging up your PR discussion. |
I have refactored to use starr on another branch. Would appreciate your thoughts on which approach you prefer resty or starr https://github.com/rraymondgh/bitmagnet/tree/starr_client_download/internal/servarr
|
Completely revamped to use new docker container. Example docker compose
|
Functionality to trigger download using prowlarr / sonarr / radarr
Notes
nix develop
environment needs following:Enhancements / feedback consideration
release
GET endpoint does not filter by indexer. This means all indexers are searched. One option could to be temporarily disable other indexers before search and re-enable after search (would also speed up call torelease
endpoint)