116

I present: Managarr with Sonarr support! (github.com)

submitted 1 week ago* (last edited 1 week ago) by aclarke@lemmy.world to c/opensource@lemmy.ml

18 comments fedilink hide all child comments

I was recently furloughed from work, so in between job applications, I decided to polish off Sonarr support in my Managarr TUI. Thus, I'm very proud to announce the beta release of Managarr with Sonarr support!

TL;DR: Managarr is a TUI and CLI for managing your Servarr instances. As of now, it now supports both Radarr and Sonarr and all the features that are available in the UI are also available in the CLI for scripting and additional automation.

The new version has the following features:

Wider platform support (Windows, Mac, Linux, x86_64 and arm64)
View your library, downloads, blocklist, episodes
View details of a specific series, or episode including description, history, downloaded file info, or the credits
View your host and security configs from the CLI to programmatically fetch the API token, among other settings
Search your library
Add series to your library
Delete series, downloads, indexers, root folders, and episode files
Trigger automatic searches for series, seasons, or episodes
Trigger refresh and disk scan for series and downloads
Manually search for series, seasons, or episodes
Edit your series and indexers
Manage your tags
Manage your root folders
Manage your blocklist
View and browse logs, tasks, events queues, and updates
Manually trigger scheduled tasks
Manually trigger scheduled tasks
And more!

Here's some screenshots of the Sonarr tab:

Thanks to everyone's feedback when I first posted the alpha release here, this version sports a handful of additional performance improvements and platform support.

This is now technically in beta, so if anyone encounters any issues, please let me know!

top 18 comments

sorted by: hot top controversial new old

[-] Laser@feddit.org 1 points 6 days ago* (last edited 6 days ago)

So I'm currently building the package, and there's one thing that irks me a bit about it, which is that you first tagged your release as 0.4.1 and then changed your Cargo.toml… which means that if you check out that tag on GitHub, the information is always one release behind. This also seemed to be the case with other releases (0.4.0 shows as 0.3.7, 0.3.7 as 0.3.6…). From the commit history, this also seems to affect Cargo.lock, so we're always getting the lock file for the previous release when checking out the tag. Not ideal

An issue with the program itself: it will always show servers for both radarr and sonarr, regardless if you have them configured or not. Switching to an unconfigured one will yield an error for missing configuration. The program itself looks nice, though I'd prefer if there was the option to respect my shell's color theme.

[-] aclarke@lemmy.world 1 points 5 days ago

Thanks for pointing out the tagging bug. I just pushed out the fix to the release pipeline to correct that.

As for the configuration, it's quite funny you mention that because I just earlier today pushed out the fix for that and I plan to have it as part of the next release. The fix being, that the UI dynamically changes based on what Servarrs you have in your config file.

And as for the color theme, that's an interesting thought. I'll look into it now!

Thanks for the feedback, I really appreciate it. And seriously, thanks for catching that tagging bug. That's definitely not ideal...

[-] Laser@feddit.org 2 points 5 days ago

No worries, I look forward to using this in the future :) (though probably rarely, I don't use my *arr stack often)

Once you have pushed your next release, I'll submit the package definition I wrote to nixpkgs, currently worked around the ordering by checking out two commits after the tag, but since there's no rush to push this, I'll wait for the next release.

[-] aclarke@lemmy.world 1 points 5 days ago

Oh and that next release is going to be a minute. I realized a massive race condition bug between the networking thread and event thread that I want to resolve. It's going to take a minute since I'm going to have to move a good amount of logic from the networking thread to the even thread to send parameters to the networking channel. So the next patch will be that fix, the release fix, and the dynamic UI based on the config. If you want, I can ping you when I'm going to do it so you can open your MR and we can get the Nix package into the next release.

[-] aclarke@lemmy.world 1 points 5 days ago

That was literally going to be one of the things I was going to ask someone to help me out to do. I wanted to make it available for Nix as well so I have no idea how to write a package definition for it, though I'm sure I could figure it out. I'm seriously stoked you did that! Thanks!

[-] Laser@feddit.org 1 points 5 days ago

It's rather simple in good cases, here's my version:

{
  lib,
  fetchFromGitHub,
  rustPlatform,
  perl,
}:

let
  pname = "managarr";
  version = "0.4.1";
in

rustPlatform.buildRustPackage {
  inherit pname version;
  src = fetchFromGitHub {
    owner = "Dark-Alex-17";
    repo = pname;
    rev = "df9bba32cb1628fe0bdf33c71089d7ae085066d4";
    hash = "sha256-2KWuqv0nxMc+H+lmuNQ0lbEm5yE2akuZTa7PT5JcvBs=";
  };

  cargoHash = "sha256-hB4uRgVUp6YngMoXqd03U/n+HdlcYdL5bwvTxI4xCLE=";

  nativeBuildInputs = [ perl ];

  meta = {
    description = "A TUI and CLI to manage your Servarrs";
    homepage = "https://github.com/Dark-Alex-17/managarr";
    license = lib.licenses.mit;
    maintainers = [ ];
  };
}

[-] aclarke@lemmy.world 1 points 3 days ago

Did you happen to have a GitHub action to go with this too? Turns out that refactor took a lot less time than I expected.

[-] Laser@feddit.org 1 points 3 days ago* (last edited 3 days ago)

No, but I will try to incorporate the nixpkgs update script into it now that the metadata is fixed for the release. I'm not a nixpkgs maintainer (yet) though but usually this is close to automatic.

If you want, you can also submit and maintain the package, or I can put us both as maintainers

[-] aclarke@lemmy.world 1 points 3 days ago

Given that I can't really see what would change in Managarr that would require additional changes in the Nix package, I see no reason not to have us both as maintainers, especially since I don't currently have Nix installed. (It's high up on my to-do list, don't worry! I know I'll like it!)

Are there any files that would need to be checked into the repo so we can maintain an official package for it?

[-] Laser@feddit.org 1 points 3 days ago

No, Cargo.lock is the only relevant optional one for Rust packages and that is already there, so we should be good. I'll request it tomorrow if someone else doesn't beat me to it ;)

[-] aclarke@lemmy.world 1 points 3 days ago

Sounds good, let me know! Also give me some links to track it too so I can also add it to the repo!

[-] Laser@feddit.org 1 points 1 day ago

I have opened a pull request at https://github.com/NixOS/nixpkgs/pull/367042, there might be more changes needed as I had an error in the meta section of the package which I rectified according to the reviewers proposed changes. Not sure this is the end of it, but the request is open

[-] aclarke@lemmy.world 1 points 1 day ago

Thanks for doing the legwork on this! I would definitely be a bit out of my depth on that PR without actually having Nix installed 😂.

Once it's merged I'll update the README to mention the Nix installation method.

[-] trevor@lemmy.blahaj.zone 7 points 1 week ago

I've been using Managarr ever since you shared it here, and it's awesome!

[-] aclarke@lemmy.world 5 points 1 week ago* (last edited 1 week ago)

Thank you so much! I was wondering if anyone had been using it more consistently because I was waiting for more bug reports to come in but haven't yet. I started thinking, "There's no way I didn't miss something. I gotta figure out how to break it! 😂

I'm so glad you like it and use it!