Piracy: ꜱᴀɪʟ ᴛʜᴇ ʜɪɢʜ ꜱᴇᴀꜱ

54424 readers

336 users here now

⚓ Dedicated to the discussion of digital piracy, including ethical problems and legal advancements.

Rules • Full Version

1. Posts must be related to the discussion of digital piracy

2. Don't request invites, trade, sell, or self-promote

3. Don't request or link to specific pirated titles, including DMs

4. Don't submit low-quality posts, be entitled, or harass others

Loot, Pillage, & Plunder

📜 c/Piracy Wiki (Community Edition):

💰 Please help cover server costs.


Ko-fi	Liberapay

founded 1 year ago

MODERATORS

[email protected]

126

Why so many *arr services? Why not 1 service that works with all media types? (lemmy.dbzer0.com)

submitted 1 year ago by [email protected] to c/[email protected]

37 comments fedilink hide all child comments

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.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 70 points 1 year ago (5 children)

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.

[–] [email protected] 6 points 1 year ago* (last edited 1 year ago) (3 children)

*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.

[–] [email protected] 5 points 1 year ago (1 children)

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...

[–] [email protected] 2 points 1 year ago

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.

load more comments (1 replies)

load more comments (2 replies)