Improve importer success chance/ Partial imports

[ChrisAbra]

Problem

Unsure if this is Lidarr or Soularr but there's often issues with failed imports when Lidarr is monitoring a very specific (for some reason often Japanese or Deluxe) edition of the albums which isnt common in soulseek and that in many sense I don't particularly need. Importing then fails even though Soularr has found a reasonable match.

The problem is then Soularr keeps trying to get this, determines the same match and fills up the failed_imports folder with the same album over and over again.

Preferred Solution:

Soularr could force Lidarr to accept the import of albums either in a partial state where it is a sub-set of tracks, if the match quality is high-enough, with flags to show this has happened.

Describe alternatives you've considered:

Flagging in Lidarr and sub-foldering by username the failed imports so they're not downloaded identically again - I can manually import them from there.

Additional context:

I fear this is a bit of a hard problem in that Soularr is relying on Lidarr for whether an album is complete and partly this is more about Lidarr having sensible defaults for added albums, but the repeated downloads of the same complete folders from soulseek seems like a problem that can be prevented.

[insanemal]

Yeah. I'm working on a fix. Lidarr will match regardless of release, but it's super strict on matches. Specifically the way we do imports and how it's totally non-interactive. And Lidarr doesn't have another API we can call to do imports. I'm working on some enhancements that should help improve the match percentages.

There is another idea I have, but I don't really like it. So it will be the last resort

[bonsaibobby]

is there a way to handle the failed imports so that they don't just stack up in the slsk downloads folder until then?

[azgnetov]

Update readme plz about complete/incomplete dirs. If slskd use the same one, tracks are named with timestamps and lidarr drops identification rate up to import failure. I see it in debug logs only. So separate dirs are strongly required.

[surtarso]

Hi, jumping in this wagon. I've been using soularr a while, it works like a charm but the import part actually NEVER worked for me. I'm happy with just half the automation than I manually import the files... this is already a big step up on the game!

But yeah... no idea why my imports are failing.

If we could get an error message with some info I could trouble shoot, but this what I get:

[INFO|soularr|L979] 2026-02-16T11:32:50+0000: Completed download of Album: BBC Radio Broadcasts London 1969 Artist: Pink Floyd
[INFO|soularr|L804] 2026-02-16T11:32:50+0000: Attempting Lidarr import of Pink Floyd - BBC Radio Broadcasts London 1969
[INFO|soularr|L821] 2026-02-16T11:32:51+0000: Starting Lidarr import for: BBC Radio Broadcasts London 1969 ID: 395539
[INFO|soularr|L830] 2026-02-16T11:32:53+0000: Downloaded Albums Scan Failed to import from: /mnt/downloads/lidarr/Pink Floyd - BBC Radio Broadcasts London 1969 (2021)
[INFO|soularr|L1054] 2026-02-16T11:32:53+0000: Failed import moved to: failed_imports/Pink Floyd - BBC Radio Broadcasts London 1969 (2021)

than:

[INFO|soularr|L1031] 2026-02-16T11:32:53+0000: Download failed for Album: BBC Radio Broadcasts London 1969 - Artist: Pink Floyd

but than again.. it did download, all i need to to is tell lidarr to import and it will now, just the automation part and the error handling (information mostly) doesnt really work for me...

is it maybe a permission problem? Soularr runs on a media server here with same user-group as lidarr...

it tries to search for the album in /mnt/downloads/lidarr (thats lidarr torrent download folder)... its in config.ini as asked.. but the soulseek downloads go to /mnt/downloads/soulseek/. (also where /failed_imports) are created... so Im probably screwing something up here...

heres the relevant part of config.ini:

[Lidarr]
api_key = mimimimimimimimimimimimimimimimi
host_url = http://192.168.15.224:8686/lidarr
download_dir = /mnt/downloads/lidarr
disable_sync = False

[Slskd]
api_key = mimimimimimimimimimimmimimimimim
host_url = http://media.server.lan:5030
url_base = /soulseek/
download_dir = /mnt/downloads/soulseek

[insanemal]

Nah you're misunderstanding the config file.

The Lidarr "download_dir" is more accurately explained as "Where can lidarr see the slskd download folder"

We need a path to tell lidarr to look in to find the downloaded (from slskd not torrents or other stuff) files.

[surtarso]

hmm... that didn't do it. I changed the lidarr dir to "where it should look for soulseek downloads" to the same as the soulseek download folder (which feels weird...) but anyway:

[INFO|soularr|L979] 2026-02-16T15:30:19+0000: Completed download of Album: Battery Check Artist: Millencolin
[INFO|soularr|L804] 2026-02-16T15:30:19+0000: Attempting Lidarr import of Millencolin - Battery Check
[INFO|soularr|L821] 2026-02-16T15:30:19+0000: Starting Lidarr import for: Battery Check ID: 396022
[INFO|soularr|L830] 2026-02-16T15:30:29+0000: Downloaded Albums Scan Failed to import from: /mnt/downloads/soulseek/Millencolin - Battery Check (2003)
[INFO|soularr|L1054] 2026-02-16T15:30:29+0000: Failed import moved to: failed_imports/Millencolin - Battery Check (2003)

it did check correctly where the files actually are: /mnt/downloads/soulseek/ , but still failed to import.

Maybe I'm getting the idea wrong?
Soulseek downloads to /mnt/downloads/imcomplete and than move complete things to /mnt/downloads/soulseek....
Lidar watch folder for new stuff (incoming torrents for example) is /mnt/downloads/lidarr...

From what I got on your explanation, since soulseek downloads end up in /soulseek/... both dirs (lidarr/slskd in config.ini) are always the same? Am I missing a step or something?

It would be easier if we could get a [FAILED] couldn't move files due to: REASON. (permission... w/e)...

[mrusse]

I changed the lidarr dir to "where it should look for soulseek downloads" to the same as the soulseek

This will still be wrong. It needs to be a directory that is mounted INSIDE the lidarr container. Please send your lidarr compose.

Also converting to a discussion.

[surtarso]

I'm not using containers.

I have Lidarr installed using my server's OS own installer (DietPI), it's a regular service on the media VM.
Slskd and Soularr are also installed system-wide on the same VM... so they are all on the same system, group, user...

I have no problems whatsoever with lidarr or slskd as services:

● soulseek.service - SoulSeek slskd
     Loaded: loaded (/etc/systemd/system/soulseek.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-02-02 03:11:57 UTC; 2 weeks 0 days ago
   Main PID: 554 (slskd)
      Tasks: 52 (limit: 4653)
     Memory: 1.3G
        CPU: 1d 13h 11min 18.571s
     CGroup: /system.slice/soulseek.service
             └─554 /opt/slskd/slskd

● lidarr.service - Lidarr (DietPi)
     Loaded: loaded (/etc/systemd/system/lidarr.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-02-02 03:11:58 UTC; 2 weeks 0 days ago
   Main PID: 911 (Lidarr)
      Tasks: 17 (limit: 4653)
     Memory: 736.0M
        CPU: 2h 27min 23.044s
     CGroup: /system.slice/lidarr.service
             └─911 /opt/lidarr/Lidarr -nobrowser -data=/mnt/dietpi_userdata/lidarr

now, to run soularr im just using a bash script (lazyness) while I can't make it auto import and create a cron for it.... a simple:

#!/bin/bash

if ps aux | grep "[s]oularr.py" > /dev/null; then
    echo "Soularr is already running. Nothing to do."
else
    cd /root/soularr/
    source venv/bin/activate
    python3 soularr.py
    deactivate
fi

files go to the same HD (a transitional download hdd):

root@media:~# l /mnt/downloads/
total 24
drwxr-xr-x 2 dietpi dietpi  4096 Feb 16 17:36 incomplete
drwxrwsr-x 3 lidarr dietpi 16384 Feb 16 11:26 lidarr
drwxrwsr-x 5 lidarr dietpi  4096 Feb 16 17:36 soulseek

while the lidarr main music library (sorted files) are on another HDD on that same VM: /mnt/music/

I don't usually use containers when I have a VM for a single purpose...

[surtarso]

It's odd coz all I have to manually do to complete the process is to mv the failed_imports/ folder contents to /mnt/music and refresh lidarr...

[insanemal]

In your case, much like mine, yes both path's would be the same. There are different config options because Soularr needs access to the files to move them around and examine them before submitting them to Lidarr. And all three of these things might be in different containers or even on different hosts.

Lidarr then grabs them from the download location and moves them into your library, after doing it's own verification and identification passes.

Now there is almost nothing more I can say without the lidarr debug logs after a failed import. But it's worth noting that sometimes things will fail to import because of a bunch of different reasons. BUT by moving them into place, you kinda force Lidarr's hand, It assumes you've checked it and in the past it was part of a lidarr collection or otherwise processed with Picard or something so it will just import things that wouldn't normally be accepted.

[HVR88]

I'm seeing import success of maybe 7% max.

Lidarr recognizes the metadata as complete. Recognizes it as musicbrainz matched. Even recognizes the release. But then rejects based on it not being the release it wants.

So does Lidarr accept any release? Not right now it doesn't. Lidarr is generally a terrible importer and a mess of a platform, but while I'm seeing better "complete" download performance with Solarr vs Tubifarry, the import success rate makes this a non-viable path.

At the end of the day the solution is clear - get rid of Lidarr. It's always where everything falls down. Even running Tubifarry, I'm pulling multiple TB of downloads per day just to get a handful of releases. Unfortunately, there's nothing else right now available to take care of the management side of the puzzle.

[insanemal]

That's not how that works at all.

[HVR88]

That's not how that works at all.

Quesque le fuq?

[insanemal]

I've got a 99.8% accept rate. Lidarr will take any release that it recognises.

I've no idea what you've done but none of what you've said is remotely accurate

[HVR88]

I believe you. But don't assume I'm not familiar with how Lidarr works. Collection sitting at 8TB right now.

This is what you have set:

Having gone through possibly 100TB of downloads, I know why Lidarr rejects any specific download.

[insanemal]

So you're complaining that downloading tools that literally cannot determine which release you have set, can't download that specific release, which is also something they cannot determine from the metadata provided by the tracker/search results?

Yeah that's a totally valid and not insane request

[HVR88]

I think you might not as much about Lidarr as you think you know. How many lines of code have you written against its API? I'm up to about 100k spread across a number of different projects. 🤷

Anyway when you have that box checked, you are expressly not setting a release. When you have it UNCHECKED is when Lidarr will require a specific release. And a download tool can absolutely know which release Lidarr is looking for and can also check for best-case matches before downloading and exact matching afterwards.

Like I said earlier, the problem isn't the download tools, at the end of the day there are a lot of issues getting even the correct releases into Lidarr.

I'm happy to know your success rate is so high. It doesn't track with what most people experience, otherwise you wouldn't see the countless posts about that very subject on reddit etc. Including the OP's issue here.

[insanemal]

Ok chief.