Skip to content

Support lidarr#18

Open
gbagnoli wants to merge 4 commits intowouterdebie:mainfrom
gbagnoli:lidarr
Open

Support lidarr#18
gbagnoli wants to merge 4 commits intowouterdebie:mainfrom
gbagnoli:lidarr

Conversation

@gbagnoli
Copy link

@gbagnoli gbagnoli commented May 6, 2025

This adds support for lidarr. It has been working for me well in the past few days.

main difference is that the API endpoint for history is slightly different (URL and returned json) and add support for AUDIO file type.

is_imported might get a slight improvement if to add the service only for audios, instead of checking all services (lidarr, sonarr, radarr, whisparr) for each file. But I tried to make the least amount of changes.

@wouterdebie
Copy link
Owner

Thanks for this! Rather than making an exception for lidarr you could pass in the application and make a decision based on that? It kind of looks strange to have a Boolean in a function signature to change it's behavior.

@JustSuperHuman
Copy link

Love seeing this project get worked on! 💪

@gbagnoli
Copy link
Author

@wouterdebie you are right, it wasn't great.

I took a stab into moving the code in the services::arr file into a struct, so now we have an enum for the type of app (lidarr, sonarr, etc) and can have different behaviour based on that. Not sure if I went too far - let me know in case

I still think we can avoid checking lidarr for video files and the other three (sonarr, radarr, whisparr) if audio, but I can open another pull for that.

gbagnoli added 2 commits May 10, 2025 15:00
Essentially, audio files are handled by lidarr, but not by the rest of
the supporter *arr (Sonarr, Radarr, Whisparr)
So this adds a MediaType enum for app to skip checking file types
not handled by them
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants