How Plugins and Extensions Extend Lyrion Music Server

Updated

Plugins and extensions are how you add capabilities to Lyrion Music Server (LMS) that aren't built into the core — new music services, player-side apps, and integrations. LMS ships with a plugin system and an in-app plugin repository, so most additions are installed from inside the server rather than by editing files. The official documentation organizes this under Extensions (Applications and Plugins), with a separate Available Plugins page and a Repository File Reference for anyone publishing their own.

What "extensions" covers in LMS

The Lyrion documentation splits extensions into two kinds:

  • Applications — add-ons that run alongside LMS.
  • Plugins — modules loaded into LMS itself to change or extend its behavior.

There's also Applet Development for SqueezePlay-based players, which is a separate track from server-side plugins. If your goal is to change what the server does (scanning, metadata, music services, CLI/RPC behavior), you want a plugin. If your goal is to change what a software player shows or does, you want an applet.

What plugins actually let you change

Based on how the documentation is structured, plugins are the extension point for:

  • Music service integration — the docs include a dedicated Music Service Plugin reference, which is the path for connecting streaming or online catalog services.
  • Library and metadata behavior — the media library and metadata guides sit alongside the plugin docs, and plugins are the mechanism for altering how tracks are organized and presented.
  • Server-side features exposed through the CLI/JSON-RPC interface — the command-line interface reference lists the query categories (players, database, playlist, favorites, randomplay, alarms, and so on) that plugins and clients build on.

In short: if a feature isn't in the core server, the documented way to add it is a plugin, and the documented way to find one is the plugin repository.

Finding and installing plugins

The documentation points to an Available Plugins page and a Repository File Reference. The practical flow is:

  1. Open the LMS web interface and go to its plugin management section (the docs list Plugins → Overview and Available Plugins as the relevant pages).
  2. Browse or search the available plugins list.
  3. Enable the plugin you want and let LMS fetch it from the repository.
  4. Restart or reload as prompted, then configure the plugin in its own settings page.

The Repository File Reference matters if you're maintaining your own repository or want to understand where LMS is pulling plugin metadata from — it documents the file format LMS reads to discover plugins.

When you'd write your own

The docs include a Plugin Development section and a Contributing section (with bug reporting, DCO sign-off, and translation guidance). You'd go this route if:

  • No existing plugin covers the music service or behavior you need.
  • You want to expose something through LMS's CLI/JSON-RPC interface.
  • You're adapting an existing plugin for a new service or a new LMS version.

The LMS 9 changelog and LMS 8 changelog are worth checking before you start, since plugin APIs can shift between major versions.

A realistic example

Say you want LMS to pull from a music service it doesn't natively support. You'd check the Available Plugins list first — if someone has already published a music service plugin for it, you enable it and enter your credentials in the plugin's settings. If not, the Music Service Plugin reference is the starting point for building one, and the Repository File Reference tells you how to make it discoverable to other LMS users.

What to check before you commit

  • Version compatibility — confirm the plugin supports your LMS major version (8.x vs 9.x), since the changelogs show API changes between them.
  • Where it comes from — plugins are fetched from repositories; the Repository File Reference documents the format, so you can see what a repository entry contains.
  • Server vs. player — a server plugin won't change a SqueezePlay player's UI; that's applet territory.

The documentation doesn't state pricing or login requirements for plugins, so treat those as plugin-specific and check the individual plugin's page.