aclarke

joined 3 years ago
[–] aclarke@lemmy.world 1 points 3 weeks ago

Thanks for letting me know! I'm look into this tomorrow!

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

By popular demand, Loki is now Coyote!

I've just released a new version with the full rename.


Thanks to @minticecream for the suggestion!


All the docs are updated except for the screenshots and gifs. I'll update those tomorrow (since they don't do any harm right now and don't require another release to be updated).

For almost a year I've been using Loki as the name but it never really satisfied me. Not to mention it's already the name of an extremely popular logging system by Grafana, which makes Loki hard to discover.

Got some great feedback and the rename was born! Thanks again everyone who gave suggestions and for all the positive feedback!

[–] aclarke@lemmy.world 6 points 1 month ago* (last edited 1 month ago) (1 children)

Do you have a GitHub and would you be willing to share it with me so I could credit you with the name? No worries if not, I can just link to your Lemmy profile instead of you prefer. I just don't want to change it without giving credit.

[–] aclarke@lemmy.world 1 points 1 month ago

Looking forward to it! Heads up in case you missed it: I had settled on renaming it to Coyote, so sometime this week will be a breaking change and release to get that done.

Biggest pains are just going to be updating the repo tokens for Crates.io and renaming the homebrew repo.

[–] aclarke@lemmy.world 5 points 1 month ago

Works for me. I'll refactor that and rename it tomorrow and hopefully have a new minor release sometime this week. It'll be another baking change release so I'll need to attach a couple commands to the release notes to make it easy to migrate.

[–] aclarke@lemmy.world 2 points 1 month ago (2 children)

Looking at Llama-swap, since it says it supports OpenAI-compatible API, it should just work natively already. Just set up the client to be type: openai-compatible and fill in the URL and provide the models. Should work out of the box!

[–] aclarke@lemmy.world 3 points 1 month ago (3 children)

After sitting with Coyote for a while, I'm really liking the name. Before I get too attached, any other ideas? (Just to make sure I stay objective 😛)

[–] aclarke@lemmy.world 18 points 1 month ago

OpenCode is specific to coding workflows. Loki is built to be a general LLM runtine/workflow engine for any problem domain, not just code. An example use I have for it is a cron job that runs at boot to

  • See if the cause of the reboot was power loss (LLM)
  • If it was, check all services to ensure they're up and running (tool)
  • If a service isn't up, then use an LLM to see what happened (LLM)
  • Try out the usual methods for getting that service started (tool + RAG)
  • If none of those work, try figuring out what's ultimately wrong (LLM)
  • Send me a ntfy notification on my phone to let me know what service isn't running, and the suspected cause with some context (tool)
[–] aclarke@lemmy.world 6 points 1 month ago

When it comes to writing code, OpenCode is my go-to as well. It's my ultimate benchmark for how well optimized and reliable I can make local models function in Loki.

[–] aclarke@lemmy.world 22 points 1 month ago (6 children)

Ooh I like Coyote! That's definitely in the running now. Not to mention that's really a really cool allusion to Native American mythology!

[–] aclarke@lemmy.world 4 points 1 month ago

It was just the one gif I had available and also the model that worked fast enough to fit into a gif without taking forever between prompts so I could demo Loki well. You make a good point though. It's an old build and is slightly outdated. I'll update that. Thanks for pointing that out.

[–] aclarke@lemmy.world 8 points 1 month ago (2 children)

Yes it does. By default, any of the execute_command or fs_write/fs_patch/etc. tools all have guards around them that prompt for user confirmation before doing things. They can be disabled via the AUTO_APPROVE environment variable if necessary (like they are when using the sisyphus agent). For bash tools, I've included functions that can help do this when you write your own tools. For Python tools, you can use the usual input methods.

 

I've been experimenting with local models via Ollama for a long time now, but one thing kept frustrating me:

Smaller local models are actually a LOT more capable than people think, but they struggle with reliability.

They lose focus, drift over long sessions, stop halfway through problems, and aren't great at breaking apart larger tasks.

So, to try and fix that, I built Coyote.

Loki is a local-first command line tool and runtime for building and running LLM workflows locally. It's model agnostic, works well with Ollama, and includes things like:

  • Agents and delegation
  • Workflow scripting
  • MCP servers
  • RAG
  • Roles/personas
  • Custom tools
  • Macros

A lot of the architecture is specifically designed around improving the reliability of smaller models. So for example:

  • Auto-continuation to push models towards completion and prevent them from stopping halfway through a problem
  • Parallel agent delegation to reduce context overload and keep scope small
  • Workflow-based execution for more deterministic automations
  • Scoped agents to reduce context drift

My long term goal with this project is basically:

Get as close as possible to Claude Code-style reliability using fully local models.

I'd love feedback from other Ollama users experimenting in this space and any tips/pointers/ideas of other things to add to make it function even better!

Repo: https://github.com/Dark-Alex-17/coyote

 

Managarr - A TUI and CLI to help you manage your Servarrs.

Thanks to everyone who contributed to this release, be that in code, issues, or enhancement suggestions! You all help fuel my passion for working on this and it doesn't go unappreciated! 😄

As always, you can try out the changes yourself via the Managarr Demo Site

Breaking Changes

  • Managarr now supports multiple instances of the same Servarr with custom names and ordering. (See Features below) To accommodate this, configuration files must be updated so that all Servarrs listed beneath radarr, sonarr, etc., be updated to be lists, not individual Servarrs. For example: to migrate from the following config:

    radarr:
      host: 192.168.0.78
      port: 7878
      api_token: someApiToken1234
    sonarr:
      host: 192.168.0.89
      port: 8989
      api_token: someApiToken1234
    

    You would change the above configuration to the following:

    radarr:
      - host: 192.168.0.78
        port: 7878
        api_token: someApiToken1234
    sonarr:
      - host: 192.168.0.89
        port: 8989
        api_token: someApiToken1234
    
  • The --config flag has been renamed to --config-fileto make it more clear what it does.

Features

  • Users can now specify multiple instances of the same type of Servarr and give them custom names and ordering. This allows users to manage multiple instances of the same Servarr, such as an Anime and TV Show instance of Sonarr. To configure, add a list of Servarrs under the respective type (e.g. radarr, sonarr, etc.). (#17)

    • You can specify ordering of your Servarrs and how they will appear in the UI via the weight field. The lower the weight, the further to the left the Servarr will appear in the UI.
    • You can also name your Servarrs whatever you wish. This name will be displayed in the UI. For example, to name your Sonarr instances:
      sonarr:
        - name: Anime
          host: 192.168.0.89
          api_token: someApiToken
      
        - name: TV Shows
          host: 192.168.0.88
          api_token: someOtherApiToken
      
    • This change also required the introduction of a new CLI flag to specify which Servarr you wish to interact with: --servarr-name. This corresponds directly to the value of the name field in your configuration. If you did not specify a name in the configuration, then default names are provided for you corresponding to the Servarr; For example, if you defined two Radarr instances with no names, they will be named Radarr 1 and Radarr 2, respectively.
    • Omitting the --servarr-name flag with multi-instance configurations will default to using the first instance that appears in your config. For example, for the following configuration:
      sonarr:
        - host: 192.168.0.89
          api_token: someApiToken
      
        - host: 192.168.0.88
          api_token: someOtherApiToken
      
      Running managarr sonarr list series will default to interacting with the Sonarr instance at 192.168.0.89. This is the same as running managarr sonarr list series --servarr-name 'Sonarr 1'.
  • API tokens can now be fetched from files instead of needing to be hardcoded (#31). The following is an example config that loads the API token from a file:

    radarr:
      - host: 192.168.0.78
        api_token_file: /home/root/.config/radarr_token
    
  • Configurations now interpolate environment variables (#23). This allows you to load sensitive information from environment variables. For example, to load the API token from an environment variable, you can do the following:

    radarr:
      - host: 192.168.0.78
        api_token: ${MY_RADARR_API_TOKEN_ENV_VAR}
    

    This is available for all fields in the configuration file.

Security Updates

Miscellaneous

 

Managarr - A TUI and CLI to help you manage your Servarrs.

Thanks to everyone who contributed to this release, be that in code, issues, or enhancement suggestions! You all help fuel my passion for working on this and it doesn't go unappreciated! 😄

As always, you can try out the changes yourself via the Managarr Demo Site

Breaking Changes

  • Managarr now supports multiple instances of the same Servarr with custom names and ordering. (See Features below) To accommodate this, configuration files must be updated so that all Servarrs listed beneath radarr, sonarr, etc., be updated to be lists, not individual Servarrs. For example: to migrate from the following config:

    radarr:
      host: 192.168.0.78
      port: 7878
      api_token: someApiToken1234
    sonarr:
      host: 192.168.0.89
      port: 8989
      api_token: someApiToken1234
    

    You would change the above configuration to the following:

    radarr:
      - host: 192.168.0.78
        port: 7878
        api_token: someApiToken1234
    sonarr:
      - host: 192.168.0.89
        port: 8989
        api_token: someApiToken1234
    
  • The --config flag has been renamed to --config-fileto make it more clear what it does.

Features

  • Users can now specify multiple instances of the same type of Servarr and give them custom names and ordering. This allows users to manage multiple instances of the same Servarr, such as an Anime and TV Show instance of Sonarr. To configure, add a list of Servarrs under the respective type (e.g. radarr, sonarr, etc.). (#17)

    • You can specify ordering of your Servarrs and how they will appear in the UI via the weight field. The lower the weight, the further to the left the Servarr will appear in the UI.
    • You can also name your Servarrs whatever you wish. This name will be displayed in the UI. For example, to name your Sonarr instances:
      sonarr:
        - name: Anime
          host: 192.168.0.89
          api_token: someApiToken
      
        - name: TV Shows
          host: 192.168.0.88
          api_token: someOtherApiToken
      
    • This change also required the introduction of a new CLI flag to specify which Servarr you wish to interact with: --servarr-name. This corresponds directly to the value of the name field in your configuration. If you did not specify a name in the configuration, then default names are provided for you corresponding to the Servarr; For example, if you defined two Radarr instances with no names, they will be named Radarr 1 and Radarr 2, respectively.
    • Omitting the --servarr-name flag with multi-instance configurations will default to using the first instance that appears in your config. For example, for the following configuration:
      sonarr:
        - host: 192.168.0.89
          api_token: someApiToken
      
        - host: 192.168.0.88
          api_token: someOtherApiToken
      
      Running managarr sonarr list series will default to interacting with the Sonarr instance at 192.168.0.89. This is the same as running managarr sonarr list series --servarr-name 'Sonarr 1'.
  • API tokens can now be fetched from files instead of needing to be hardcoded (#31). The following is an example config that loads the API token from a file:

    radarr:
      - host: 192.168.0.78
        api_token_file: /home/root/.config/radarr_token
    
  • Configurations now interpolate environment variables (#23). This allows you to load sensitive information from environment variables. For example, to load the API token from an environment variable, you can do the following:

    radarr:
      - host: 192.168.0.78
        api_token: ${MY_RADARR_API_TOKEN_ENV_VAR}
    

    This is available for all fields in the configuration file.

Security Updates

Miscellaneous

 

Managarr - A TUI and CLI to help you manage your Servarrs.

Thanks to everyone who contributed to this release, be that in code, issues, or enhancement suggestions! You all help fuel my passion for working on this and it doesn't go unappreciated! 😄

As always, you can try out the changes yourself via the Managarr Demo Site

Breaking Changes

  • Managarr now supports multiple instances of the same Servarr with custom names and ordering. (See Features below) To accommodate this, configuration files must be updated so that all Servarrs listed beneath radarr, sonarr, etc., be updated to be lists, not individual Servarrs. For example: to migrate from the following config:

    radarr:
      host: 192.168.0.78
      port: 7878
      api_token: someApiToken1234
    sonarr:
      host: 192.168.0.89
      port: 8989
      api_token: someApiToken1234
    

    You would change the above configuration to the following:

    radarr:
      - host: 192.168.0.78
        port: 7878
        api_token: someApiToken1234
    sonarr:
      - host: 192.168.0.89
        port: 8989
        api_token: someApiToken1234
    
  • The --config flag has been renamed to --config-fileto make it more clear what it does.

Features

  • Users can now specify multiple instances of the same type of Servarr and give them custom names and ordering. This allows users to manage multiple instances of the same Servarr, such as an Anime and TV Show instance of Sonarr. To configure, add a list of Servarrs under the respective type (e.g. radarr, sonarr, etc.). (#17)

    • You can specify ordering of your Servarrs and how they will appear in the UI via the weight field. The lower the weight, the further to the left the Servarr will appear in the UI.
    • You can also name your Servarrs whatever you wish. This name will be displayed in the UI. For example, to name your Sonarr instances:
      sonarr:
        - name: Anime
          host: 192.168.0.89
          api_token: someApiToken
      
        - name: TV Shows
          host: 192.168.0.88
          api_token: someOtherApiToken
      
    • This change also required the introduction of a new CLI flag to specify which Servarr you wish to interact with: --servarr-name. This corresponds directly to the value of the name field in your configuration. If you did not specify a name in the configuration, then default names are provided for you corresponding to the Servarr; For example, if you defined two Radarr instances with no names, they will be named Radarr 1 and Radarr 2, respectively.
    • Omitting the --servarr-name flag with multi-instance configurations will default to using the first instance that appears in your config. For example, for the following configuration:
      sonarr:
        - host: 192.168.0.89
          api_token: someApiToken
      
        - host: 192.168.0.88
          api_token: someOtherApiToken
      
      Running managarr sonarr list series will default to interacting with the Sonarr instance at 192.168.0.89. This is the same as running managarr sonarr list series --servarr-name 'Sonarr 1'.
  • API tokens can now be fetched from files instead of needing to be hardcoded (#31). The following is an example config that loads the API token from a file:

    radarr:
      - host: 192.168.0.78
        api_token_file: /home/root/.config/radarr_token
    
  • Configurations now interpolate environment variables (#23). This allows you to load sensitive information from environment variables. For example, to load the API token from an environment variable, you can do the following:

    radarr:
      - host: 192.168.0.78
        api_token: ${MY_RADARR_API_TOKEN_ENV_VAR}
    

    This is available for all fields in the configuration file.

Security Updates

Miscellaneous

 

Managarr - A TUI and CLI to help you manage your Servarrs.

Thanks to everyone who contributed to this release, be that in code, issues, or enhancement suggestions! You all help fuel my passion for working on this and it doesn't go unappreciated! 😄

As always, you can try out the changes yourself via the Managarr Demo Site

Breaking Changes

  • Managarr now supports multiple instances of the same Servarr with custom names and ordering. (See Features below) To accommodate this, configuration files must be updated so that all Servarrs listed beneath radarr, sonarr, etc., be updated to be lists, not individual Servarrs. For example: to migrate from the following config:

    radarr:
      host: 192.168.0.78
      port: 7878
      api_token: someApiToken1234
    sonarr:
      host: 192.168.0.89
      port: 8989
      api_token: someApiToken1234
    

    You would change the above configuration to the following:

    radarr:
      - host: 192.168.0.78
        port: 7878
        api_token: someApiToken1234
    sonarr:
      - host: 192.168.0.89
        port: 8989
        api_token: someApiToken1234
    
  • The --config flag has been renamed to --config-fileto make it more clear what it does.

Features

  • Users can now specify multiple instances of the same type of Servarr and give them custom names and ordering. This allows users to manage multiple instances of the same Servarr, such as an Anime and TV Show instance of Sonarr. To configure, add a list of Servarrs under the respective type (e.g. radarr, sonarr, etc.). (#17)

    • You can specify ordering of your Servarrs and how they will appear in the UI via the weight field. The lower the weight, the further to the left the Servarr will appear in the UI.
    • You can also name your Servarrs whatever you wish. This name will be displayed in the UI. For example, to name your Sonarr instances:
      sonarr:
        - name: Anime
          host: 192.168.0.89
          api_token: someApiToken
      
        - name: TV Shows
          host: 192.168.0.88
          api_token: someOtherApiToken
      
    • This change also required the introduction of a new CLI flag to specify which Servarr you wish to interact with: --servarr-name. This corresponds directly to the value of the name field in your configuration. If you did not specify a name in the configuration, then default names are provided for you corresponding to the Servarr; For example, if you defined two Radarr instances with no names, they will be named Radarr 1 and Radarr 2, respectively.
    • Omitting the --servarr-name flag with multi-instance configurations will default to using the first instance that appears in your config. For example, for the following configuration:
      sonarr:
        - host: 192.168.0.89
          api_token: someApiToken
      
        - host: 192.168.0.88
          api_token: someOtherApiToken
      
      Running managarr sonarr list series will default to interacting with the Sonarr instance at 192.168.0.89. This is the same as running managarr sonarr list series --servarr-name 'Sonarr 1'.
  • API tokens can now be fetched from files instead of needing to be hardcoded (#31). The following is an example config that loads the API token from a file:

    radarr:
      - host: 192.168.0.78
        api_token_file: /home/root/.config/radarr_token
    
  • Configurations now interpolate environment variables (#23). This allows you to load sensitive information from environment variables. For example, to load the API token from an environment variable, you can do the following:

    radarr:
      - host: 192.168.0.78
        api_token: ${MY_RADARR_API_TOKEN_ENV_VAR}
    

    This is available for all fields in the configuration file.

Security Updates

Miscellaneous

 

Managarr - A TUI and CLI to help you manage your Servarrs.

Thanks to everyone who contributed to this release, be that in code, issues, or enhancement suggestions! You all help fuel my passion for working on this and it doesn't go unappreciated! 😄

As always, you can try out the changes yourself via the Managarr Demo Site

Breaking Changes

  • Managarr now supports multiple instances of the same Servarr with custom names and ordering. (See Features below) To accommodate this, configuration files must be updated so that all Servarrs listed beneath radarr, sonarr, etc., be updated to be lists, not individual Servarrs. For example: to migrate from the following config:

    radarr:
      host: 192.168.0.78
      port: 7878
      api_token: someApiToken1234
    sonarr:
      host: 192.168.0.89
      port: 8989
      api_token: someApiToken1234
    

    You would change the above configuration to the following:

    radarr:
      - host: 192.168.0.78
        port: 7878
        api_token: someApiToken1234
    sonarr:
      - host: 192.168.0.89
        port: 8989
        api_token: someApiToken1234
    
  • The --config flag has been renamed to --config-fileto make it more clear what it does.

Features

  • Users can now specify multiple instances of the same type of Servarr and give them custom names and ordering. This allows users to manage multiple instances of the same Servarr, such as an Anime and TV Show instance of Sonarr. To configure, add a list of Servarrs under the respective type (e.g. radarr, sonarr, etc.). (#17)

    • You can specify ordering of your Servarrs and how they will appear in the UI via the weight field. The lower the weight, the further to the left the Servarr will appear in the UI.
    • You can also name your Servarrs whatever you wish. This name will be displayed in the UI. For example, to name your Sonarr instances:
      sonarr:
        - name: Anime
          host: 192.168.0.89
          api_token: someApiToken
      
        - name: TV Shows
          host: 192.168.0.88
          api_token: someOtherApiToken
      
    • This change also required the introduction of a new CLI flag to specify which Servarr you wish to interact with: --servarr-name. This corresponds directly to the value of the name field in your configuration. If you did not specify a name in the configuration, then default names are provided for you corresponding to the Servarr; For example, if you defined two Radarr instances with no names, they will be named Radarr 1 and Radarr 2, respectively.
    • Omitting the --servarr-name flag with multi-instance configurations will default to using the first instance that appears in your config. For example, for the following configuration:
      sonarr:
        - host: 192.168.0.89
          api_token: someApiToken
      
        - host: 192.168.0.88
          api_token: someOtherApiToken
      
      Running managarr sonarr list series will default to interacting with the Sonarr instance at 192.168.0.89. This is the same as running managarr sonarr list series --servarr-name 'Sonarr 1'.
  • API tokens can now be fetched from files instead of needing to be hardcoded (#31). The following is an example config that loads the API token from a file:

    radarr:
      - host: 192.168.0.78
        api_token_file: /home/root/.config/radarr_token
    
  • Configurations now interpolate environment variables (#23). This allows you to load sensitive information from environment variables. For example, to load the API token from an environment variable, you can do the following:

    radarr:
      - host: 192.168.0.78
        api_token: ${MY_RADARR_API_TOKEN_ENV_VAR}
    

    This is available for all fields in the configuration file.

Security Updates

Miscellaneous

 

Managarr - A TUI and CLI to help you manage your Servarrs.

Thanks to everyone who contributed to this release, be that in code, issues, or enhancement suggestions! You all help fuel my passion for working on this and it doesn't go unappreciated! 😄

As always, you can try out the changes yourself via the Managarr Demo Site

Breaking Changes

  • Managarr now supports multiple instances of the same Servarr with custom names and ordering. (See Features below) To accommodate this, configuration files must be updated so that all Servarrs listed beneath radarr, sonarr, etc., be updated to be lists, not individual Servarrs. For example: to migrate from the following config:

    radarr:
      host: 192.168.0.78
      port: 7878
      api_token: someApiToken1234
    sonarr:
      host: 192.168.0.89
      port: 8989
      api_token: someApiToken1234
    

    You would change the above configuration to the following:

    radarr:
      - host: 192.168.0.78
        port: 7878
        api_token: someApiToken1234
    sonarr:
      - host: 192.168.0.89
        port: 8989
        api_token: someApiToken1234
    
  • The --config flag has been renamed to --config-fileto make it more clear what it does.

Features

  • Users can now specify multiple instances of the same type of Servarr and give them custom names and ordering. This allows users to manage multiple instances of the same Servarr, such as an Anime and TV Show instance of Sonarr. To configure, add a list of Servarrs under the respective type (e.g. radarr, sonarr, etc.). (#17)

    • You can specify ordering of your Servarrs and how they will appear in the UI via the weight field. The lower the weight, the further to the left the Servarr will appear in the UI.
    • You can also name your Servarrs whatever you wish. This name will be displayed in the UI. For example, to name your Sonarr instances:
      sonarr:
        - name: Anime
          host: 192.168.0.89
          api_token: someApiToken
      
        - name: TV Shows
          host: 192.168.0.88
          api_token: someOtherApiToken
      
    • This change also required the introduction of a new CLI flag to specify which Servarr you wish to interact with: --servarr-name. This corresponds directly to the value of the name field in your configuration. If you did not specify a name in the configuration, then default names are provided for you corresponding to the Servarr; For example, if you defined two Radarr instances with no names, they will be named Radarr 1 and Radarr 2, respectively.
    • Omitting the --servarr-name flag with multi-instance configurations will default to using the first instance that appears in your config. For example, for the following configuration:
      sonarr:
        - host: 192.168.0.89
          api_token: someApiToken
      
        - host: 192.168.0.88
          api_token: someOtherApiToken
      
      Running managarr sonarr list series will default to interacting with the Sonarr instance at 192.168.0.89. This is the same as running managarr sonarr list series --servarr-name 'Sonarr 1'.
  • API tokens can now be fetched from files instead of needing to be hardcoded (#31). The following is an example config that loads the API token from a file:

    radarr:
      - host: 192.168.0.78
        api_token_file: /home/root/.config/radarr_token
    
  • Configurations now interpolate environment variables (#23). This allows you to load sensitive information from environment variables. For example, to load the API token from an environment variable, you can do the following:

    radarr:
      - host: 192.168.0.78
        api_token: ${MY_RADARR_API_TOKEN_ENV_VAR}
    

    This is available for all fields in the configuration file.

Security Updates

Miscellaneous

 

Managarr - A TUI and CLI to help you manage your Servarrs.

Thanks to everyone who contributed to this release, be that in code, issues, or enhancement suggestions! You all help fuel my passion for working on this and it doesn't go unappreciated! 😄

As always, you can try out the changes yourself via the Managarr Demo Site

Breaking Changes

  • Managarr now supports multiple instances of the same Servarr with custom names and ordering. (See Features below) To accommodate this, configuration files must be updated so that all Servarrs listed beneath radarr, sonarr, etc., be updated to be lists, not individual Servarrs. For example: to migrate from the following config:

    radarr:
      host: 192.168.0.78
      port: 7878
      api_token: someApiToken1234
    sonarr:
      host: 192.168.0.89
      port: 8989
      api_token: someApiToken1234
    

    You would change the above configuration to the following:

    radarr:
      - host: 192.168.0.78
        port: 7878
        api_token: someApiToken1234
    sonarr:
      - host: 192.168.0.89
        port: 8989
        api_token: someApiToken1234
    
  • The --config flag has been renamed to --config-fileto make it more clear what it does.

Features

  • Users can now specify multiple instances of the same type of Servarr and give them custom names and ordering. This allows users to manage multiple instances of the same Servarr, such as an Anime and TV Show instance of Sonarr. To configure, add a list of Servarrs under the respective type (e.g. radarr, sonarr, etc.). (#17)

    • You can specify ordering of your Servarrs and how they will appear in the UI via the weight field. The lower the weight, the further to the left the Servarr will appear in the UI.
    • You can also name your Servarrs whatever you wish. This name will be displayed in the UI. For example, to name your Sonarr instances:
      sonarr:
        - name: Anime
          host: 192.168.0.89
          api_token: someApiToken
      
        - name: TV Shows
          host: 192.168.0.88
          api_token: someOtherApiToken
      
    • This change also required the introduction of a new CLI flag to specify which Servarr you wish to interact with: --servarr-name. This corresponds directly to the value of the name field in your configuration. If you did not specify a name in the configuration, then default names are provided for you corresponding to the Servarr; For example, if you defined two Radarr instances with no names, they will be named Radarr 1 and Radarr 2, respectively.
    • Omitting the --servarr-name flag with multi-instance configurations will default to using the first instance that appears in your config. For example, for the following configuration:
      sonarr:
        - host: 192.168.0.89
          api_token: someApiToken
      
        - host: 192.168.0.88
          api_token: someOtherApiToken
      
      Running managarr sonarr list series will default to interacting with the Sonarr instance at 192.168.0.89. This is the same as running managarr sonarr list series --servarr-name 'Sonarr 1'.
  • API tokens can now be fetched from files instead of needing to be hardcoded (#31). The following is an example config that loads the API token from a file:

    radarr:
      - host: 192.168.0.78
        api_token_file: /home/root/.config/radarr_token
    
  • Configurations now interpolate environment variables (#23). This allows you to load sensitive information from environment variables. For example, to load the API token from an environment variable, you can do the following:

    radarr:
      - host: 192.168.0.78
        api_token: ${MY_RADARR_API_TOKEN_ENV_VAR}
    

    This is available for all fields in the configuration file.

Security Updates

Miscellaneous

 

Managarr - A TUI and CLI to help you manage your Servarrs.

Thanks to everyone who contributed to this release, be that in code, issues, or enhancement suggestions! You all help fuel my passion for working on this and it doesn't go unappreciated! 😄

As always, you can try out the changes yourself via the Managarr Demo Site

Breaking Changes

  • Managarr now supports multiple instances of the same Servarr with custom names and ordering. (See Features below) To accommodate this, configuration files must be updated so that all Servarrs listed beneath radarr, sonarr, etc., be updated to be lists, not individual Servarrs. For example: to migrate from the following config:

    radarr:
      host: 192.168.0.78
      port: 7878
      api_token: someApiToken1234
    sonarr:
      host: 192.168.0.89
      port: 8989
      api_token: someApiToken1234
    

    You would change the above configuration to the following:

    radarr:
      - host: 192.168.0.78
        port: 7878
        api_token: someApiToken1234
    sonarr:
      - host: 192.168.0.89
        port: 8989
        api_token: someApiToken1234
    
  • The --config flag has been renamed to --config-fileto make it more clear what it does.

Features

  • Users can now specify multiple instances of the same type of Servarr and give them custom names and ordering. This allows users to manage multiple instances of the same Servarr, such as an Anime and TV Show instance of Sonarr. To configure, add a list of Servarrs under the respective type (e.g. radarr, sonarr, etc.). (#17)

    • You can specify ordering of your Servarrs and how they will appear in the UI via the weight field. The lower the weight, the further to the left the Servarr will appear in the UI.
    • You can also name your Servarrs whatever you wish. This name will be displayed in the UI. For example, to name your Sonarr instances:
      sonarr:
        - name: Anime
          host: 192.168.0.89
          api_token: someApiToken
      
        - name: TV Shows
          host: 192.168.0.88
          api_token: someOtherApiToken
      
    • This change also required the introduction of a new CLI flag to specify which Servarr you wish to interact with: --servarr-name. This corresponds directly to the value of the name field in your configuration. If you did not specify a name in the configuration, then default names are provided for you corresponding to the Servarr; For example, if you defined two Radarr instances with no names, they will be named Radarr 1 and Radarr 2, respectively.
    • Omitting the --servarr-name flag with multi-instance configurations will default to using the first instance that appears in your config. For example, for the following configuration:
      sonarr:
        - host: 192.168.0.89
          api_token: someApiToken
      
        - host: 192.168.0.88
          api_token: someOtherApiToken
      
      Running managarr sonarr list series will default to interacting with the Sonarr instance at 192.168.0.89. This is the same as running managarr sonarr list series --servarr-name 'Sonarr 1'.
  • API tokens can now be fetched from files instead of needing to be hardcoded (#31). The following is an example config that loads the API token from a file:

    radarr:
      - host: 192.168.0.78
        api_token_file: /home/root/.config/radarr_token
    
  • Configurations now interpolate environment variables (#23). This allows you to load sensitive information from environment variables. For example, to load the API token from an environment variable, you can do the following:

    radarr:
      - host: 192.168.0.78
        api_token: ${MY_RADARR_API_TOKEN_ENV_VAR}
    

    This is available for all fields in the configuration file.

Security Updates

Miscellaneous

118
submitted 2 years ago* (last edited 2 years ago) by aclarke@lemmy.world to c/opensource@lemmy.ml
 

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!

 

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!

 

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!

view more: next ›