Tubifarry: a Lidarr plugin that treats Spotify as the index and YouTube as the source

An indexer that searches, and a downloader that fetches

Tubifarry is a plugin for Lidarr that adds multiple music sources to your library management, and the design decision that defines it is the separation between search and download.

It uses Spotify's catalog as an indexer, in the arr sense of the word, meaning it is the thing Lidarr queries to find out what exists and what a release should be called. The actual audio files come from YouTube.

That split is unusual enough to be worth sitting with. In a normal Lidarr setup, the indexer is a tracker and the download client is the thing that fetches from a tracker, so the two share a protocol and a release model. Here the metadata source and the file source have nothing to do with each other, and the plugin bridges them. A release found on Spotify has a name, an artist, an album and a release date, and then the YouTube downloader looks for audio matching that metadata and converts it.

The same pattern applies to Soulseek. Tubifarry supports Slskd, the Soulseek client, as both an indexer and a downloader, which lets you tap into the collection on the Soulseek network. Here the two roles are the same service, and the configuration is split across two Lidarr settings screens.

The project is MIT licensed, written in C#, and is a Visual Studio solution with a Directory.Build.props, a stylecop.json, a NuGet.config and a Submodules directory. The last push was on 2026-10-14 and the recent releases are v2.3.0.2 on 2026-10-14, v2.3.0.1 on 2026-10-12 and v2.2.0.5 on 2026-09-09.

What the C# solution is actually made of

The repository layout tells you the project is a normal Visual Studio solution with a few unusual details.

There is Tubifarry.sln at the root, the Tubifarry/ directory with the plugin itself, a Submodules/ directory, Directory.Build.props for the shared MSBuild properties, stylecop.json for the StyleCop analyzer settings, and a NuGet.config. The.gitmodules file and the Submodules directory are the interesting pair, because they mean some of the code is not in the main repository. The CHANGELOG is not present at the root but the release names carry an emoji prefix, so the release history is doing the work a changelog file would normally do.

The top level also has CONTRIBUTION.md rather than CONTRIBUTING.md, and a.github directory, plus the usual.gitignore and.gitattributes. The.gitattributes is worth noting in a project that vendors or generates files, since it is what keeps line endings and diff behaviour consistent across the submodules and the main tree.

The presence of stylecop.json says the project runs the StyleCop analyzers, which is the C# convention for enforcing the Microsoft style rules, and Directory.Build.props is the modern way to apply those settings and any shared package versions to every project in the solution at once rather than duplicating them per project.

For a plugin, the practical consequence of the C# choice is that it fits the arr stack natively. Lidarr, Sonarr and Radarr are.NET applications, and a plugin that shares their runtime, their HTTP stack and their configuration model drops into the existing infrastructure without a sidecar, a bridge or a separate process. The cost is the plugin's own version compatibility with the host, which is why the release numbering is dense, with v2.3.0.2 and v2.3.0.1 two days apart and v2.2.0.5 in the month before.

The Submodules arrangement is the other structural note. Whatever is pulled in as a submodule, it is code the plugin depends on but does not version itself, which shifts the maintenance of that dependency onto whatever upstream is doing.

Installing it, and the two sides of the Slskd setup

Installation is the standard Lidarr plugin flow, with no manual steps. In Lidarr you go to System, then Plugins, paste the repository URL into the GitHub URL box and click Install.

The Soulseek side needs two separate entries, one in each of Lidarr's two relevant settings screens, because Slskd fills two different roles.

As an indexer, you go to Settings, then Indexers, click Add, select Slskd from the list, and configure the URL of your Slskd instance, for example http://localhost:5030, the API key found in Slskd's own settings under Options, and a setting called Include Only Audio Files which filters search results to audio files only.

As a download client, you go to Settings, then Download Clients, click Add and select Slskd. The documentation notes that the download path is fetched from Slskd, and that if it does not match you should use the Remote Path settings instead. That last point is a small but real detail: the path Slskd reports and the path Lidarr expects have to agree, and when they do not, the fix is in the Remote Path field rather than in Slskd.

The YouTube side has the same two-part structure. As an indexer, Settings, then Indexers, then Add, and in the modal select Tubifarry, which is located under Other at the bottom of the list. As a download client, Settings, then Download Clients, then Add, select Youtube from the list, and set the download path and adjust other settings as needed.

The YouTube downloader extracts audio and converts it to audio files using FFmpeg, and the FFmpeg path is optional to configure but has to be right somewhere, either in the system PATH or set in the plugin settings.

YouTube detects downloaders, and the plugin says so

The most useful thing in the documentation is the warning, because it tells you what to expect before you configure anything.

YouTube actively detects and blocks automated downloaders. To bypass this, the documentation says to configure the Trusted Session Generator and provide cookie authentication.

So the plugin does not attempt to be stealthy. It hands you the two mechanisms that work, a session that looks like a real logged-in session, and your own cookies, and it accepts that this is an arms race with the platform. If you do not configure them, the download client will be blocked, and the symptom will look like a download that fails rather than a policy notice.

The FFmpeg dependency has the same honest framing. It is required to extract audio from YouTube, and the plugin will attempt to download FFmpeg automatically if it is not found. Without FFmpeg, files are downloaded in their original format, which Lidarr may not properly import. The wording matters: the import failure is a downstream symptom of a missing audio conversion step, not a Lidarr bug.

The audio quality options are listed for the same reason. YouTube provides audio at various bitrates, with standard quality being 128kbps AAC for free users and high quality being 256kbps AAC which requires YouTube Premium. The plugin can convert to other formats, MP3 or Opus, using FFmpeg.

Put together, the download path is: an indexer gives the metadata, the downloader fetches the media, FFmpeg turns it into a file Lidarr can import, and a cookie plus a trusted session is what keeps the fetch from being blocked. Every one of those steps is optional in the configuration and mandatory in practice, which is why the documentation spends more words on the failure modes than on the feature list.

Web clients, soundtracks, and the housekeeping features

The web client section covers services that provide music over their own APIs. The listed ones are Lucida, a music downloading service supporting multiple sources, DABmusic, a high-resolution audio streaming platform, T2Tunes, a music downloading service that supports AmazonMusic, and Subsonic, a music streaming API standard with broad compatibility.

The plugin is explicit that it is not responsible for the uptime or stability of these services, which is the right thing to say since they are third-party endpoints you do not control. The architectural note is that all clients share the same base architecture, which makes adding a new one relatively straightforward, and the Subsonic indexer and client is described as a generic client, so any online service that speaks Subsonic can connect. The Subsonic specifications are documented on the API page, and if a service does not want to support Subsonic as a generic indexer, the request is to open a feature request.

The soundtrack feature pulls from the other arr applications. Tubifarry supports fetching soundtracks from Sonarr for series and Radarr for movies and adding them to Lidarr using the Arr-Soundtracks import list feature. To enable it you add an import list in Settings, then Import Lists, choose Arr-Soundtracks, point it at your Sonarr and Radarr instances, and give it a cache path for storing responses from MusicBrainz, which is for faster lookups.

Then there are the housekeeping features. The Queue Cleaner handles downloads that fail to import into your library, which happens for missing tracks or incorrect metadata. It can rename files based on their embedded tags, retry the import, blocklist the release, or remove the files, and the options are whether to blocklist, to remove, or to do both, whether to rename album folders and tracks using available metadata, and when to clean, for example when tracks are missing.

The table of contents also lists Codec Tinker for converting files between formats with FFmpeg, a Lyrics Fetcher, Search Sniper, custom metadata sources, and a Similar Artists feature, so the plugin has grown past the original indexer and downloader pair into a general utility for the arr stack.

Editorial conclusion

Tubifarry fits a Lidarr user whose library is incomplete or whose sources are spread across services that have no indexer, and who already runs the arr stack and is comfortable with FFmpeg, API keys and a Slskd instance. It is a poor fit if you only want one source of truth for your music, because the plugin adds a parallel path where Spotify is the catalogue and YouTube is the delivery, and a poor fit if YouTube blocks you, since the documentation is explicit that YouTube detects automated downloaders and needs a trusted session plus cookies. Before installing, read the bot detection section, and confirm you are comfortable with the legal position of the sources you point it at, since the plugin's whole purpose is to fetch files from services that do not hand them over.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. TypNull/Tubifarry on GitHub