I am almost done building my first self hosted streambox through Docker. That’s a total of 16 instances, each fulfilling 1 specific role.
As I’m new to the *arr world, could you please help me understand why it is standard to deploy multiple *arr services for each media type (ex: readarr1 for books + readarr2 for audiobooks) instead of using 1 that does multiple media types?
Thank you.
In the software world, based on personal experience and the UNIX philosophy, software should aim to do one thing and do it really well.
Then there are also the bloat complaints (why should I download a whole stack of arr services when I only care for movies)
The most unfortunate one however can be them mixing. If my child looks up Star Wars but instead the suite ends up downloading a Star Wars porn parody… that’s just… bad
I do wish I didn’t need to run a second Radarr instance to have both 1080p and 4K media.
Not everyone has to, though. I use one instance for a wide variety of resolutions, depending on the show and consumption model; including 360,480,720,1080, 2160 (HDR/10-bit). But I run Plex on a box with quicksync that is doing my transcoding for me.
So why have you chosen to run different instances?
It’s not as relevant today as it used to be, that’s for sure. Originally it was to limit transcoding of 4K content (which used to be a lot harder), and also to avoid the HDR tone mapping issues with 4K content during transcoding, both of which are largely resolved with newer hardware and Plex software updates.
The only reason I keep them separated now is because most of the folks I share with can’t direct stream 4K content anyway, and so I only share out the 1080p libraries in Plex. It keeps bandwidth usage down and limits having to go to hardware transcoding, which can reduce quality and introduces startup delays. The library I use locally indexes both the 1080p and 4K content, so Plex will always prefer the 4K if it’s there.
If diskspace ever became an issue, I’d probably consider merging the libraries again.
Sure but they also seem to share quite a bit of GUI code at least. Couldn’t all of these just be plugins for a core *arr service?
That’s because of the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.
*arr apps don’t do one thing.
- They cook their own authentication system.
- They manage trackers, indexers, etc.
- They download files automatically.
- They track upcoming releases.
- They rename files automatically.
*arr apps don’t do one thing well.
- They require extensive configuration due to insensible defaults.
- They require manual intervention from time to time even with a good configuration.
- They can’t even fulfill their purpose. Bazarr shits the bed with anime.
*arr apps don’t handle text streams.
But I think the Unix philosophy is flawed anyways. It’s like the metaverse: When a metaverse succeeds, they attribute that success to the metaverse as a concept. When a metaverse fails, they attribute the failure to that metaverse, not the metaverse as a concept. Now substitute metaverse with unix utility and the metaverse as a concept with the unix philosophy.
You’re taking it too literally, and missing much of the nuance between philosophy of design and actual implementation details.
The movies app manages movies. That’s its one thing. No need to overcomplicate it. Unix ‘find’ for instance, finds files. That’s its one thing. ‘find’ also lets you filter the results, but that doesn’t change its purpose of finding files.
The fact that *arr apps don’t do things, or are bad at things, has nothing to do with the Unix philosophy. Were these apps combined into a monolith, the same issues would need to be addressed.
There is no right or wrong in a design philosophy. It’s all trade offs. I don’t know anyone who says Unix (or the metaverse) is successful because of a design philosophy. What matters is what you deliver.
There is literally not one singular(!) arr that does what you’re claiming, at least that I’m aware of. The indexing is done by a different thing than the tracking and the downloading.
That’s why you end up with 16 of them like OP after all…
Yeah, sonarr and radarr support some indexers but I ended up just setting up Jackett. They both use those indexers to search, but in different ways. They also don’t do the file downloading, your separate download client does that. They do both track future releases and rename files, but the way that works conceptually for movies and TV shows is pretty different since Movies are singular pieces of media while shows are broken up into seasons and episodes. They work with different data structures and so have to parse and present in different ways.
That will be one big bloated software extremely painful to maintain.
The simpler services are, the less likely to break down. Google SRE guidance
