Sonarr Movie Support Discussion & Planning

This is a forum post kicking off the discussion from Issue 298.

I’ve created a small Google Doc so that we can have a single source of truth for the work that needs to be done and why. Please add information as you see fit with some description of what it means.

Also, if you’re interested in contributing, add your Github username and what you’d like to do.

Note: Please be sure to understand the difficulties in front of us by reading comments such as this.

1 Like

@fedoranimus Thanks for starting this!!! I am definitely down to help start this and maintain it as my time allows.

Since the designers mentioned that support is their primary concern, ours should first be to guarantee that the developers here are willing to support their own work for a period of time. I imagine with the capability in place some level of support will eventually swell.

Once that is out of the way we need to dip our toes in. Use cases are a good direction once you have a foundation in place. The first steps should be (each of these is basically a milestone):

  1. Design Documentation: Familiarize ourselves with the core code. What can be leveraged, especially in the download characteristic field. Quality should be comparable, but what about size for example? We’d have to use bitrate or MB per hour or some such. There’s plenty more to consider.
  2. Proof of concept: Entering a movie database id to populate search queries and queue automatic download. This would give us a standardized test set and should help minimize the impact of naming conventions and exceptions for a first draft.
  3. Alpha: With that in place (likely poorly), the next move would be to address the naming exceptions Taloth mentioned. This is not something I’m experienced with but I expect a working foundation would go a long way to refining the implementation. This would be a good time to consider things like release windows.

If we were to get this far I would expect we have a pretty solid foundation to start hammering out the nitty gritty headaches which will undoubtedly be the hardest part and the bulk of the time on the way to a beta.

I don’t want to disregard a founder’s desired use-case, but Taloth’s is not the first step. There are some complicated aspects of interacting with the user in the process, especially in the multi-case scenario he mentioned with auto/manual downloads. It’s also very difficult to build tests for user-intimate interactions. It’s all good stuff, but we need to start somewhere and that’s a use case for a more mature project.

Thanks @rcketscientist.

I’m planning to spend some time this upcoming week digging into the Sonarr code to (attempt) to understand what is going on and how we can start chipping away. Any help in this would be very welcome!

Could you give an example of what you’re expecting for the Design Documentation?

I wouldn’t want to put a strict definition of the design doc as I’m not sure how all fields do them. In aerospace it’s a really stiff and painful-to-read document with a bunch of “The system shall”. Let’s not do that, lol.

Basically the goal of the document is to focus our efforts. It will be a living document as I’m doubtful we have any guys with a ton of experience organizing a bunch of folks and it will have to change as we mature with the project.

Basically I’d like to see some very fundamental goals, constraints and structures we need in order to have a marginally functional product. For example:

Query format is where we will need to be most strict. A desired search query consists of x, y, and z. Constraints are a, b, c. A proper newznab search query would consist of these 6 variables in a certain format. For this kind of thing we’ll want to be rather clear. This sort of documentation will convert directly to code documentation.

Other things we can shoot from the hip. What do we want to expose to the user, what can be default. As the project matures these aspects start to emerge as UI.

Long story short I don’t have a specific format in mind, but it’s basically herding cats trying to organize strangers online, so there needs to be some central mandate we can all go to to cuddle when we get lost ;-).

Hey, I’m very interesting in adding movie support to Sonarr as well - or at least forking a movie version of Sonarr. I’m willing to help out in any way I can. I’ll take a look at the doc above and start perusing the code base.

I used to do .NET programming back in the day but it’s been a few years. Last thing I did was HdBrStreamExtractor - a GUI from eac3to. Looking forward to the challenge tho. :slight_smile:

I wonder why you guys dont work with sonarr dev on this feature ?
I hope mark help you on this

I would be more than happy to get help from an existing Sonarr dev!

Someone who knows the code-base and can provide guidance, even if they’re not doing the grunt coding effort, would go a very long way to realizing this feature.

If there is an existing Sonarr development member who wishes to help/lead, I would be grateful.

I spoke to them a few months back. They’re understandably resistant to helping as they view the capability as a potentially unsupportable feature. While they’re able to help, they rely heavily on outside help to support the project. Support for a new major feature may not be tenable with their current manpower.

Which is why I emphasized anyone working on this needs to be able to make a long term commitment to also supporting it. Once the foundation is in place we could expect a lot more help and support shouldn’t be an issue, but we’d need to be self-sufficient for some time at least.

Rather than “Adding” Movie Support to Sonarr, why not fork it, take the foundation that has already been laid and rework it into a side by side tool that only handles movies and acts as a direct replacement for CP?

That way you guys would be solely responsible for your app and the sonarr team would be solely responsible for their side of things?

No crossover, no toes being stood on.

Just my two cents i agree with Harroguk, i think it will work better if a different application is build for movie support rather than adding it to Sonarr. Two apps, one for shows one for movies.

@rcketscientist Yeah, I remember that being mentioned in the Github issue. I would just really like a person on the Sonarr team coordinating available for code-reviews from the get-go. I also need to buckle down and start actually investigating the code - that may be a project that has to wait until after the holidays.

@Harroguk, @great I don’t necessarily have an issue with having a separate app, I don’t foresee this as being the best solution for the user. If there is no other way, then it’s better to have 2 working apps, of course. However, why, as a user, would I want to set up my indexers, download clients, notification systems, etc twice? Why would I want to set up two entirely separate systems that have 99% of the same information twice? This seems like a waste.

Additionally, if we just fork Sonarr, we’d be sitting on a lot of code that wouldn’t be used and we’d have to build a fresh UI no matter what. If we write something from the ground up, then we don’t have all of the nice decision engines and such that the Sonarr team has already built. Not to mention all of the community tools already in use by the Sonarr team.

I think our best bet is still integrating movie support into Sonarr.

@Harroguk @great We’ll be forking regardless. Fork is just a branch. You’re suggesting to make a commitment to never push back upstream which is silly. Ostensibly a fork solves the support conflict, but in actuality it doesn’t. It just gives the original designers plausible deniability if we were to build the app then neglect it. At the very least, it would shift the support to, “Why isn’t this in the main stream?” If we’re serious about the subproject then the support issue remains.

IF sonarr were a series of modules, we could pick and choose capabilities to leverage, but that’s not the case. It’s very hard to fork a project, gut it significantly, and still keep the projects sync’d.

Your idea that two make it work as a fork would need to make sonarr modular, silly question is how difficult would it be to make the movies and additional functionality modular ?

It would be quite difficult at this point.

Since I agreed with @Harroguk, I created a fork and started implementing searching for movies and downloading them. The first of my progress can be looked at here: https://github.com/galli-leo/Sonarr.

New movies can be added (even though they are just a series with one season and one episode in the background) and the rarbg indexer can be searched for movies. However, at the moment downloading fails. (So there’s that.)

@fedoranimus It is very possible that you can import the database from Sonarr so that you do not have to setup everything twice. Actually, I think it’s exactly the opposite. By forking Sonarr we have a lot of tools already layed out for us. I think the UI can stay pretty much the same.

And regardless, whether we keep the fork separate or not, we have to reimplement a lot of stuff already present.
Furthermore, as I have seen with my limited experience working on the fork, Sonarr is already pretty modular. Of course, changes to something like searching for a new series, we would not be able to sync. However, the rest (messaging system, indexers, etc.) should be no problem, if implemented right.
For example, someone just pushed a new messaging system to the main project and I should be able to merge that with my fork without a problem.

Additionally, I think a separate fork allows us more freedom. We could, for example, add more movie focused indexers (TorrentPotato) and change the way releases are searched for (predb). This could prove to be easier when working on a separate fork.

Lastly, after having worked with the code base a bit, I think it will be easier to gut the whole series stuff and build the movie stuff above it.

1 Like

I am not sure if anyone has seen this or not, but I just came across someone that is trying to build a CP alternative. He might have some of the code that is needed

hope that helps

@apperrault Thanks for the link! I had actually commented on the reddit thread introducing it earlier this week. I plan to take a look and try it out tomorrow.

@gallileo, nice job with the fork. I’ll have to check out that new messaging system; been out of touch for the holidays a bit. From a user perspective, I, personally, want a single, unified system. If that’s significantly more work or restricts building a well-constructed system, then I’m all for having two programs. I want the user’s perspective taken into account more than anything.

Honestly, I just want an alternative to CP; if someone is willing to offer that with or without having to extend Sonarr, I’m all for it.

@gallileo I took at look at your fork. The more I think about it, I don’t think it would be as horrible as I originally thought to have two separate apps that are REALLY good at doing their one thing. (Sonarr for Series, Radarr for Movies)

I think I’ll dig into your fork. Are you looking to change the UI to look different from Sonarr? You’re wanting to strip all of the series-specific stuff out?

The idea is to have the UI be very similar.

At the moment I am keeping the Series stuff, but it’s hidden away.