Soulseek Search Options?

[patryksg]

Hey. Would it be hard to add an option to configure how Tubifarry searches for releases on Soulseek?

I.e. give people an option to set up their own way to search for releases:

1. ArtistName ReleaseName ReleaseYear Codec

2. ReleaseName ReleaseYear Codec

3. ReleaseName ReleaseYear ReleaseType Codec

4. Regular, should find most. 2. For banned artist searches on Soulseek's side. 3. For when an artist has an EP with the same name as an Album, for instance. All filtering out, for instance, non FLAC files.

Something like that. :)

[TypNull]

Hi,

Lidarr is designed to handle codecs and release details automatically, restricting its search would actually make it less effective. The current setup is broad for a reason: it parses every result to ensure nothing is missed, which is the intended behaviour. For blocked queries there is fallback search.

The same goes for release years. If you’ve set a specific release in Lidarr, it will match against that. If Tubifarry finds a release year, it passes that info to Lidarr, so you’re covered.

What if Lidarr mixes up an EP with an album?
That’s a Lidarr issue, not a search problem. You’d need to address it within Lidarr itself. Open a PR it seems like more people have a problem with that.

Let’s say you set a custom format that works for one release but breaks the search for others. That's at least not ideal. It is possible but I think the gain of it is minimal.

[patryksg]

I have messed around with it for a year or so now, and sometimes nothing will be found, no matter how many fallback metadata searches it tries, but then a manual search will actually get hits. But I will say that it most likely is my fault then.

I appreciate your reply. :)

[HVR88]

I have messed around with it for a year or so now, and sometimes nothing will be found, no matter how many fallback metadata searches it tries, but then a manual search will actually get hits. But I will say that it most likely is my fault then.

I can confirm this.

WRT the suggested abilities, I'd vote for that. I've never seen an automated search include the year. IMO, the distinction between release types, EP or Album is a search parameter not a Lidarr classification issue. If you're missing an EP but the search only ever returns an album to Lidarr, there's nothing to be done - and this is exactly what happens 100% of the time.

[TypNull]

I believe Lidarr handles selecting the best release on its own. When you search, Slskd returns all matching albums, and Lidarr then evaluates each result to find the best fit. My thinking is that including the year would narrow down the results, giving Lidarr fewer options to sort through.

[HVR88]

My thinking is that including the year would narrow down the results, giving Lidarr fewer options to sort through.

Sure, but less is more in this case.

However, that's not the issue. The issue is in the search query and indexer. What happens is the completely wrong release is downloaded. Then Lidarr correctly identifies it - but it's already too late, because that's not what was wanted in the first place. And then what can (usually) happen is that Lidarr deletes the previous release you had and replaces it with this one. And you still don't have what you wanted, the EP that shares the same name.

[TypNull]

So generally I should support a way to setup the primary search parameter yourself?

[HVR88]

Ultimately I haven't given enough thought to how to get the most meaningful search for any particular release type like EP that often messes up, but it's not something that Lidarr can deal with because it's at the end of the pipe when it's already too late.

The options I see are:

1. increase the specificity of the search - brings back less results, which is good if most of the other results are bad/wrong
2. filter the search results to pick the content best matching the release by looking at multiple properties like track count, etc.
3. both of the above

That can go lots of different ways, including the options from the OP, which rebases the entire search algo, or your own secret sauce without any additional options to create something more automated. That secret sauce can also be implemented as a toggle, like "Increase specificity" - helps weed out incorrect matches and separate releases with the same name - warning: reduces search results

etc.

[TypNull]

The main challenge is balancing the number of searches in Slskd to avoid getting blocked. If the automation uses overly specific searches, we risk fewer results and potential temporary bans.
As for your second point, Lidarr is designed to filter releases and find the best match. I could add an option for users to define their own search rules, as mentioned above, so everyone can experiment with what works best for them. However, this would be more suited to advanced users. For most people, triggering a broad search and letting Lidarr handle the filtering is sufficient.

[patryksg]

Giving advanced users an option to fiddle around is never a bad thing, provided a warning to the possible consequences would be stated.

…

On Tue, 13 Jan 2026, 11:49 TypNull, ***@***.***> wrote: The main challenge is balancing the number of searches in Slskd to avoid getting blocked. If the automation uses overly specific searches, we risk fewer results and potential temporary bans. As for your second point, Lidarr is designed to filter releases and find the best match. I could add an option for users to define their own search rules, as mentioned above, so everyone can experiment with what works best for them. However, this would be more suited to advanced users. For most people, triggering a broad search and letting Lidarr handle the filtering is sufficient. — Reply to this email directly, view it on GitHub <#99 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BS3OKIAYNCL3KS2FWWF4FH34GTETVAVCNFSM6AAAAACQA2HTIWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNBYGQ2DAMY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[HVR88]

I'm getting close to completing the collection I currently have defined and I'm at a good stage to comment on what's sorely needed in a search parameter to have any chance of finding the last items.

A universal deficiency in my collection has become very apparent, namely finishing off EPs and Singles. Especially those that share a name with an Album release - the chance of obtaining them with slskd via Tubifarry's search parameters is almost 0.

To greatly improve the likelihood of finding such releases the following are needed:

• Try searching with release year
• Include release type for "Single" / "EP" releases

As it stands today, I'm seeing mostly the incorrect releases downloaded while trying to capture the last EPs and Singles. A common one is grabbing the album when they share the same name. Then plenty of times something completely unrelated is grabbed. Anything from a different release from the same artist, to some other artist's random release.

[TypNull]

I will take a look next weekend. If and in what way I can restructure the search order.
Contributions are always welcome.

[HVR88]

Thanks. One HUGE problem exposed with this is with how Lidarr treats completed downloads.

If a duplicate release is downloaded due to the inability to search and match for what's really wanted, Lidarr will happily re-import a release that's already marked NOT WATCHED and send the existing release to the trash.

In the past 2 hours, Lidarr has trashed 9GB of flac releases that were all 100% matched. Thankfully it seems to have replaced them with equal matches and not random garbage.

[HVR88]

If you want some problem areas to test on, here are a few very specific cases that are almost always guaranteed to never find a match and/or download the correct content:

1. Self-titled (or close) releases:

• "The Red Hot Chili Peppers" by The Red Hot Chili Peppers
• "Mother" by Mother Mother
• "Razorlight!" by Razorlight

2. EP or Singles releases that have the same name as an Album

3. Single-digit releases (any release that has very short or ambiguous name):

• "9" by Public Image Ltd.
• "7" by U2

All of those examples above cause downloads of other (incorrect) files. In the case where a download is of a release that already exists, even if it's UNMONITORED, Lidarr will happily overwrite the existing tracks (!)

I ended up having to make a tool to unmonitor these types of releases to prevent the extra downloads and overwriting. As a bonus it can also just find and list offenders, here are come examples (program ignores articles and punctuation in titles):

[TypNull]

Does adding the release year prevent these incorrect downloads?
Soulseek operates entirely on text parsing, there are no structured fields like "AlbumName" to query against. This makes it nearly impossible to account for all naming conventions users might employ.
I understand the need to include the album type when multiple albums share the same name, and to add the release year as well. However, I'm struggling with edge cases like finding "9" by Public Image Ltd.—albums with very short titles.
Do you have a concrete suggestion for handling these cases? For example, should the system automatically fall back to track-based searching when an album title is shorter than 4 characters?

[HVR88]

You can sometimes find releases by using the year. I think it's vital especially when the release title matched the artist name - the way it is now, something is always matched in that case, and it's always something seemingly random.

But like OP mentioned, in many cases a manual search for simple Artist Title finds multiple matches that never seem to be recognized when Tubifarry searches on its own.

A fallback to tracks is an interesting idea and could work to pull individual tracks from multiple shared resources to complete a release that would otherwise never complete.

Conceptually, I don't have an issue with something simply not coming up in search - but downloading a completely unrelated release is never a good alternative, and right now now, I think that's one of the significant problems.

For example, looking at my activity page I see this:

and clicking on the little person icon shows me this:

In this instance there don't appear to be any file - that's odd on its own, but more importantly is the text in the download title. There's no "7" there.

In this instance:

Having a year in there may have prevented this irrelevant folder from downloading:

Here's an unrelated, but really odd one. I have these releases all set to unmonitored. Take note of Stars of CCTV

But this keeps happening:

That's the album release - but the problem is it's been downloaded some 10 times in the past week while the releases have been unmonitored. Except this time, maybe not actually downloaded at all:

Weird.

[HVR88]

I just wanted to add.... sometimes, extra metadata isn't necessary in the search, but should be used in a negative fashion to unqualify search results. For example, if you do a broad search (the case now) and you're looking for a release from the year 1995, you can automatically disqualify any releases from the search that have years other than 1995.

Another one I just thought of is a complement to this:

If it can me made to work, offer an option to filter out releases with more tracks. That would help prevent selecting and downloading an album release that you already have, while searching for an EP with the same name.

[TypNull]

I think you misunderstood my point about track searching. It doesn't mean pulling tracks from multiple sources.

A fallback to tracks is an interesting idea and could work to pull individual tracks from multiple shared resources to complete a release that would otherwise never complete.

Tubifarry will never parse individual tracks, it's far too resource-intensive. However, searching for a track and then matching it to its album is possible.

Regarding the "7" issue, I believe it matched against the username that contains a 7. I already score all releases based on priority, but Lidarr ignores this scoring. The same appears to be true for years. Tubifarry exposes all the dates it finds, so Lidarr could easily match the correct one. As I mentioned, this is a Lidarr issue and would require either a Lidarr issue report or pull request. The best approach would be to notify jasonvelocity about the problem. I believe he wanted to redesign the Lidarr parser (he's also the Lidarr subreddit mod). He also left a discussion about something last week here. In my opinion, ordering releases by priority and providing Lidarr with metadata to determine the correct release is better than trying to give Lidarr only one option.

For short names, doing a direct song-based search is probably the best approach. I already have separate handling for self-titled releases, but for albums with names similar to the artist name, I don't think they should be treated like self-titled releases, but it could be worth a try, "Mother Mother" would never be similar enough to just "Mother." I also don't understand why Lidarr would allow a search on one release and then automatically import a different release. That's probably another issue that needs to be opened in the Lidarr repository. Blacklisting a release should always prevent it from being pulled again.

When an album with the same name exists, I append the type to the search. I'll improve the wildcard search functionality. I'll also filter out releases with too many songs when searching for an EP or single, even though I already assign them a low priority (which Lidarr seems to ignore). Additionally, I'll add a template-based primary search for power users with some configurable tags. I'm hoping this will yield better results. I'll push these changes to the develop branch sometime this weekend if that works for you.

That said, I believe the core problem lies with Lidarr, not with Tubifarry's search handling. If you could open issues on the Lidarr repository and explain the problem to people who have more capacity to work on Lidarr, it would probably help many more users. I'd do it myself, but I currently don't have the time to open a PR to improve Lidarr.

[HVR88]

Oh, I may have misunderstood some of what's happening. Are you simply passing the list of all search results to Lidarr and then it makes the decision on what folder to download?

If that's the case, then yes, Iidarr is at "fault" - but I don't expect that to be remedied any time soon as it's taken them close to a year to fix a simple database schema issue that frankly is a few days work at most, including troubleshooting and 100% re-indexing.

If the above is how Tubifarry is sending info to Lidarr, I'd recommend a more surgical option of pruning the slskd results before handing anything over to Lidarr.

Blacklisting a release should always prevent it from being pulled again

Lidarr doesn't work that way when exposed to your downloader though. It seems to blacklist the specific user/directory/path that comes up in the download. But that doesn't mean that 10,001 other people don't also have that same album available :)

I'm happy to put up a bug report for Lidarr - I'll pick bits of what we've discussed here to fine-tune it. I want to make sure I understand how Tubifarry is communicating the results of the slskd search though, as I just mentioned above. Otherwise, there's a huge risk someone just punts it back and that's not good for anyone.

[TypNull]

That's essentially correct. Tubifarry passes all search results to Lidarr, but it preprocesses them first because Lidarr can't handle Slskd's folder structure directly. Lidarr is designed to work with release groups and torrents, not file paths.

Tubifarry converts file paths into a format Lidarr can understand. Since many users have inconsistent folder structures, not everything can be matched perfectly. Anything that can't be converted is simply passed through as-is.
When Tubifarry detects a year in the release, it includes that in the metadata to pass to Lidarr for matching.

Album and episode matching problems are common across Lidarr, you're not alone in experiencing this and it is not a problem only for Slskd.

The search process and path-to-Lidarr conversion are both handled by Tubifarry. So when something like "9" by Public Image Ltd. gets mapped incorrectly, it's because Tubifarry can't reliably detect that album name in the path. As you can imagine, identifying such a short, generic name within a file path is quite challenging.

[HVR88]

Agreed.

On a manual search just now, "Public Image Ltd (1989) 9" (without the quotes) pulls up the right album for every result on the first page of results (5?) and 3 more on the next. :)

It didn't work quite as well for "Madness (1981) 7" as I had to go down 4 pages to find 2 results with 1 set of flac.

In any case, I recommend for the first search try, always use the complete artist name, year and complete release title. It helps significantly.

[TypNull]

When I include the year in my search, the number of results drops significantly. While this reduces the workload for Lidarr, the real issue is Lidarr’s year-matching logic, which is only marked as a to-do and not implemented. I submit a pull request to fix this in Lidarr, since Tubifarry shouldn’t be responsible for filtering results based on the year. That is at least what I think.

[HVR88]

In case I hadn't mentioned it lately, Tubifarry's slskd integration works remarkably well to download the vast majority of a collection, and is probably the number one reason that Lidarr is even usable in the first place.

There are a lot of factors from slskd's odd search behavior to lidarr's, but the brute-force approach, while consuming n-times more throw-away downloads, does get us most of the way. I've got unlimited bandwidth, so that's not much of a concern. :)

But back to the topic: The significant drop in results is a good thing (at this stage), as it narrows down on the acceptable match.

The more results you have, the lower the signal to noise ratio is - it's only polluting the data and making it more likely that Lidarr picks an incorrect result.

What data can you send to Lidarr that might help it pick a particular result? For instance, if you're sending Lidarr a total of 10 results, what's available to you to try and hint that Lidarr should pick one specific result from those 10?

IMO, this gaming of Lidarr's behavior, by having the external tool influence what gets chose is how to improve the performance when there's mostly noise available from slskd.

I've been contemplating writing something to manually search and download from slskd and then push the folder/files to Lidarr, completely bypassing its indexer/downloader integration to try and get around this very issue. It may get done, depending on how much code I can pull and re-use from something else I'm working on (private custom-extended musicbrainz mirror that already has to ID releases that don't have MBID)

[TypNull]

Reducing noise may not be helpful when you already have a limited number of releases to choose from. Instead, improving the matching logic in Lidarr is likely the best approach. I’ll add a checkbox to append the year to searches. I will also ad a template based search for you to tinker with. And for Lidarr adding year parsing.

[TypNull]

Please test of the new Search system on develop.

I also opened a PR to include the release year in the parsing process.

[HVR88]

I'll give this a look tomorrow, thanks