SearchSniper may be importing unmonitored albums?

[sn0skier]

I've been upgrading my entire collection to FLAC and I recently noticed that roughly 13 albums were added to my library even though I never selected them to be monitored and I didn't previously have any files for those albums. I think what happened is that someone on soulseek had multiple albums within one folder or that searchsniper mistook the unmonitored album for a similar monitored album and downloaded it. Usually if that happens lidarr doesn't import that album but for these albums it did. I'm not using Queue Cleaner. Does this seem possible with the way SearchSniper downloads and Lidarr imports? Clearly this isn't intended behavior, but it might be very difficult to always avoid, so I wanted to ask if this is possible before submitting it as a bug and trying to debug the issue further.

[TypNull]

The issue of Lidarr downloading unwanted content can stem from many sources. Common reasons include:

• An import list matching unintended releases
• A monitored release changes the Artist
• Items being set to “monitored” by mistake
• API errors or incorrect responses
• Songs lingering in your unmatched list

However, even if slskd downloads 100 tracks, Lidarr only matches what you’ve explicitly requested. Unwanted matches should only occur if your download folder is incorrectly set as your root folder, which shouldn’t happen. While some users may have messy libraries, not everyone uses Lidarr, so this is unavoidable.

If you find a solution, it could benefit many others, but this seems more like a Lidarr-specific problem.

[sn0skier]

My download folder isn't set as my root folder. I think I maybe didn't explain myself clearly.

To give you an example, I had some MP3's of Joan Baez's album/release group Joan Baez . This album was monitored and was set to a quality profile that tried to upgrade the album to FLAC. SearchSniper/Lidarr somehow imported the album/release group Joan Baez, Vol. 2 even though that album was not monitored nor did I have that album in my library. My assumption is that SearchSniper found it on slskd (or possibly through a torrent), thought it was a match because of how close the name is, and downloaded it. Once downloaded either SearchSniper or Lidarr (I'm not sure how it works exactly) found the best match for the downloaded album and imported it. I'm fairly certain that this all happened automatically and that I didn't accidentally manually import the wrong album.

Something similar has happened for 13 albums out of ~1300 that SearchSniper has upgraded so far. What I'm asking is if this is possible/easy to prevent or if it should already be prevented.

[HVR88]

Just a small update on this older thread.

However, even if slskd downloads 100 tracks, Lidarr only matches what you’ve explicitly requested

Unfortunately that's not the case. The filtering needs to be done at download time, because it's possible that if even so much as 1 extra track makes it into a release's folder Lidarr may not be able to import that release.

That's because lidarr tries to match the files against its db entries, and if that extra/wrong file gets picked up (common), it will say the release is invalid.

With the current setup, it's very common that folders get a lot of extra track content. Much of it stems from the way some people keep their folders, with mixed mp3 and flac together, or multi disks all together with or without decent filenames, etc. Then as I mentioned before, slskd can create duplicate files when the same content is downloaded multiple times (which is common if using the wanted list in batch. In this case slskd will make files with .net time "tick" codes on them - and this will cause Lidarr to fail import 100% of the time.

[TypNull]

Is there a way to resume file downloads on SLSKD if the file already exists? While I could clean up the files before marking them as completed, the behavior you described doesn’t make much sense to me. Since torrents and Usenet downloads all go into the same directory, wouldn’t other download clients also fail if there’s just one problematic file? In that case, this approach seems inconsistent, but I won’t be able to look into it further for the next two weeks.

[HVR88]

Since torrents and Usenet downloads all go into the same directory,

Not into the same download directory. The download directory is defined by SLSKD and any torrent directories would be defined by the torrent client. Then it's up to you to tell Lidarr where those are as part of the downloader plugin, because Lidarr doesn't have any concept of its own download directory.

So as far as Lidarr's concerned, the files exist in "A" dir where it will import them from, but that can be anything that's passed to it - so long as it's reachable from a mount in the container.