Stop Reinventing the Wheel and Start Contributing

[enoch85]

Hey,

I'm a bit disappointed that you didn't spend your time on contributing to Maintainerr instead. You were there, in the early stages of Jellyfin development - you had the chance to contribute, help us, and implement your ideas.

Now you instead spent countless hours on building this - which I'm sure is great, but adds even more clutter to the *arr stack. I have ranted about this in a few other Discord channels already, but the general pattern is usually something like this:

• One developer builds an app.
• Another developer starts using it and feels like a feature is missing.
• Instead of adding that feature to the original app, they build a separate app around it.
• Then someone else finds that second app, feels that it is missing something too, and ends up building yet another app on top of that one.
• Eventually, you have multiple apps that are all solving roughly the same problem in slightly different ways. That can get bloated and messy pretty quickly. First and foremost, several versions of the same thing - as an end user, which should I choose etc etc.

I would prefer if we could avoid that where possible. Just wanted to point that out. You are always welcome to the original project. 👍

[jessielw]

Hello,

First of all, I want to acknowledge the monumental amount of work you’ve put into Maintainerr - it’s truly impressive. I was there during the early stages and saw the dedication you brought to the project, especially with the addition of Jellyfin support.

The main reason I decided to create a new application rather than contribute directly was the architectural focus of Maintainerr. It’s designed to manage a single media server (either Plex or Jellyfin, but not both simultaneously). My use case required managing both at the same time, and I felt that adding this to Maintainerr would be outside its intended scope and possibly introduce complexity that didn’t fit the project’s vision. I also wanted a project that will be ready for Emby easily.

I absolutely respect the value of consolidating efforts and minimizing fragmentation in the ecosystem. My goal wasn’t to create clutter, but to address a specific need that wasn’t covered elsewhere. I hope Reclaimerr can complement the existing tools, and I’m always open to collaboration or sharing ideas to improve the ecosystem for everyone.

Thanks for your hard work and for keeping the door open!

[diablo581]

I want to thank you both for your work, because this is something I definitely couldn't do for myself, so I don't want either of you to take any of this from a negative point of view. Any issues with the software are probably entirely my own lack of understanding. I just wanted to express my experience with them.

I have both things spun up right now and I am just comparing the two of them to see which one I can use in my personal setup.

Reclaimarr to me seems way more simple to get going and get a rule configured. I guess maybe the reason is that it has less things that it can do right now, so the by its nature makes it easier to use. I do like the idea that maybe eventually I could give my JF friends access to it and when they are done with a show they can just mark that they are done and then it can get deleted. I honestly just wish this functionality was in Seer. It seems like it makes so much sense there. The filtering that Reclaimarr can do seems more limited though, which like I would like to target things that have been requested through Seer, but I don't see a way to do that.

Maintainarr is insanely powerful and I think that it might do what I ultimately would like, which is look for things that have been requested, watched and then have sat there for like a year with no one watching them, mark them for deletion, notify the requester, and then after like 30 days delete them, BUT I have no idea how to make it do it. I have successfully written one rule that looks for a tag and then if that tag exists it keeps like the 4 most recent shows and deletes the rest, so I have made a rule that works, but it was a struggle to accomplish. This was also partially because the community rules are written on an old version I guess and they don't import correctly at all for most of them, but I wasn't experienced enough to realize that for a long time. Also unlike Seer/Reclaimarr I am unsure if there is a system for people to stop the delete. Maybe I need to write that in the rule or something, like IS favorited or something like that.

I have recently been working with Tunarr to make smart collections for streaming TV channels and it's filter system is very well done or it feels that way at least. It feels like it sort of walks you through what you are looking for while providing quick feedback on what your results will look like.

Again I really appreciate the work that you have done. Both of you are great humans for spending your time doing this.

[enoch85]

Hey, thanks for the thoughtful write-up - this kind of side-by-side feedback is really useful.

What you described (requested → watched → idle ~a year → notify → delete after 30 days) is actually a pretty classic Maintainerr flow. It's a rule combining "request date" / "last viewed at" with the notification / handle-after delay, which gives that grace period before the actual delete. For "let users stop a delete," the usual pattern is that removing the item from the Plex collection exempts it — not super discoverable, fair point. Happy to help sketch the rule if you open a discussion on our repo.

The community rules breaking across versions is a fair hit. We've had schema changes and no import migration layer — that's on us to fix.

The Tunarr-style live filter feedback is a good call. Showing a live "this rule currently matches X items" preview while building has been on our wish list for a while; your comment nudges it up.

Thanks again — both for trying both tools and for writing it out. 👍

[jessielw]

Hello, and thanks so much for the thoughtful feedback and the detailed comparison. I fully agree with @enoch85 here - Maintainerr is definitely the more mature and powerful project at this stage, and that was actually by design. My priority with Reclaimerr was to build a clean, solid foundation that could support multiple media servers (all at once if desired) and the N *arrs as needed (this is not in yet).

Before deciding to start Reclaimerr, I actually spent a little over a weekend trying to see if I could add Reclaimerr’s core ideas directly into Maintainerr. What I found is that, without massive architectural changes, it just wasn’t practical - at least at the time. (And, at that point, enoch85's PR's for Jellyfin took quite a while to get any responses from the maintainers, which made me feel like they were un-welcomed originally.)

Now that Reclaimerr’s core is in place, I feel much more comfortable building further features on top of it, knowing everything is well-understood and carefully designed - not just auto-generated code (not at all implying Maintainerr is this way; just my personal approach).

I truly appreciate your feedback! And @enoch85, if there’s ever a way for Reclaimerr and Maintainerr to work together in a way that genuinely benefits the community, I’d love to help make that happen. I’m open to any suggestions or changes that would improve interoperability or bring the projects closer together.

Thanks again to everyone for your time and input - these discussions are what help all our tools get better!

[diablo581]

I really want to say that I really appreciate that both of you responded in positive ways. So often times it doesn't go that way, so to start that is just really nice.

Also I went to the maintainarr repo and discussions are not on, so I am hesitant to open a bug report since it isn't really a bug? What is the best way to do it @enoch85 ?