Most releases found are missing tracks

[neilanthonystuckey]

Is there a way to make lidarr-youtube-downloader more strict on album matches ? I am finding that most albums are missing tracks compared to what Lidarr albums release shows. Or is there a way to have lidarr-youtube-downloader fail the download if it does not match the lidarr release for missing tracks and try another release on YT ?

[neilanthonystuckey]

I let this run overnight looks like 7 out 112 albums were not missing tracks. I am using docker i had to move the download location out of my library as it was making a mess of things pretty quickly with the missing tracks.

[dmzoneill]

PR's are welcome

[chaquetashop]

i have got this problem because the lidar rely on ID3 tags (metadata inside the MP3 artist, album, track, etc.), not just filenames. I have fixed by creating script and run it using scheduler to fix the metadata.

#!/usr/bin/env bash
# Simple in-place auto-tagger for LYD downloads
# Usage: ./lyd_auto_tagger_no_backup.sh /path/to/music

set -uo pipefail

BASE_DIR="$1"
if [[ -z "${BASE_DIR:-}" ]]; then
  echo "Usage: $0 /path/to/music-downloads"
  exit 1
fi

# find eyeD3 (try user's pipx install first, fallback to PATH)
EYE="$(command -v eyeD3 || true)"
if [[ -z "$EYE" ]]; then
  EYE="/home/$(whoami)/.local/bin/eyeD3"
fi
if [[ ! -x "$EYE" ]]; then
  echo "eyeD3 not found at '$EYE'. Install it and re-run."
  exit 1
fi

echo "Base: $BASE_DIR"
echo "eyeD3: $EYE"
echo "Tagging in-place (no backup)."

find "$BASE_DIR" -type f -iname "*.mp3" -print0 | while IFS= read -r -d '' file; do
  dir="$(dirname "$file")"
  filename="$(basename "$file")"

  artist=""
  album=""
  title=""
  tracknum=""

  # Pattern: "NN - Title.mp3"
  if [[ "$filename" =~ ^([0-9]{1,2})[[:space:]]*-[[:space:]]*(.+)\.mp3$ ]]; then
    tracknum="${BASH_REMATCH[1]}"
    title="${BASH_REMATCH[2]}"
    album="$(basename "$dir")"
    artist="$(basename "$(dirname "$dir")")"

  # Pattern: "Artist - Album - Title.mp3"
  elif [[ "$filename" =~ ^(.+)[[:space:]]-[[:space:]](.+)[[:space:]]-[[:space:]](.+)\.mp3$ ]]; then
    artist="${BASH_REMATCH[1]}"
    album="${BASH_REMATCH[2]}"
    title="${BASH_REMATCH[3]}"

  # Pattern: "Artist - Title.mp3"
  elif [[ "$filename" =~ ^(.+)[[:space:]]-[[:space:]](.+)\.mp3$ ]]; then
    artist="${BASH_REMATCH[1]}"
    title="${BASH_REMATCH[2]}"
    album="$(basename "$dir")"
  else
    echo "Skipping (unrecognized pattern): $file"
    continue
  fi

  # Trim whitespace
  artist="$(echo "$artist" | sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//')"
  album="$(echo "$album" | sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//')"
  title="$(echo "$title" | sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//')"

  cmd=( "$EYE" )
  [[ -n "$artist" ]] && cmd+=( -a "$artist" )
  [[ -n "$album" ]]  && cmd+=( -A "$album" )
  [[ -n "$tracknum" ]] && cmd+=( -n "$tracknum" )
  [[ -n "$title" ]]  && cmd+=( -t "$title" )
  cmd+=( "$file" )

  # Use sudo if file is not writable
  if [[ -w "$file" ]]; then
    "${cmd[@]}" || echo "ERROR: eyeD3 failed for $file"
  else
    sudo "${cmd[@]}" || echo "ERROR: eyeD3 failed for $file (even with sudo)"
  fi

  echo "Tagged: $file"
done

echo "All done!"

dont forget to install eyeD3 and make your account can run without sudo

pipx install eyed3
sudo visudo
user ALL=(ALL) NOPASSWD: /home/user/.local/bin/eyeD3

[dmzoneill]

Thank you for reporting this issue! This is a common problem with lidarr-youtube-downloader. Let me break down what's happening and provide some solutions.

Root Cause Analysis

The issue occurs because YouTube videos are often partial or mismatched releases compared to what Lidarr expects. The downloader's matching logic has two limitations:

1. Weak track count validation: The code downloads tracks based on a fuzzy string match (default 0.8 threshold) between the search query and YouTube video title, but it doesn't verify that the downloaded track actually matches the Lidarr release's metadata or track count.

2. No pre-download validation: Before downloading from a YouTube result, the script doesn't check if that video is likely to contain all tracks from the album or if it's a partial/compilation version.

Looking at the code in lyd.py (line 406-410), the matching is purely title-based:

if SequenceMatcher(None, searchFor, song["title"]).ratio() > best:
    if skip_youtube_download(song["link"]) is False:
        best = SequenceMatcher(None, searchFor, song["title"]).ratio()
        bestLink = song["link"]
        bestTitle = song["title"]

Debugging Steps

To diagnose this on your setup:

1. Check the downloaded files: Are the tracks actually missing from the YouTube downloads, or are they being downloaded but not recognized by Lidarr?

   # List what was downloaded
   ls -la /path/to/music/Artist/Album/

2. Verify ID3 tags: Lidarr relies on ID3 metadata, not just filenames. Check if your downloads have proper tags:

   eyeD3 /path/to/music/Artist/Album/Song.mp3

3. Enable verbose logging: Run with --verbose flag (if supported) or add print statements to see which YouTube results are being selected.

4. Test specific albums: Try running the downloader on a single album to see which YouTube videos are being selected and whether they're complete versions.

Solutions

Option 1: Adjust Match Threshold (Strictness)

Increase the MATCH_THRESHOLD environment variable to require closer matches:

export MATCH_THRESHOLD="0.95"  # Higher = stricter matching
lyd

This will skip videos with titles that don't closely match, reducing false positives. However, this may cause more "Unable to find" results.

Option 2: Add Keyword Filters (via BLACKLIST_KEYWORDS)

Use the existing BLACKLIST_KEYWORDS env var to skip low-quality results:

export BLACKLIST_KEYWORDS="playlist,compilation,mix,remix,cover,live,karaoke,instrumental"
lyd

Option 3: Fix Metadata Post-Download (Recommended)

As noted in an earlier comment, the real issue is often missing/incorrect ID3 tags. Use the provided tagging script to fix metadata after download:

pipx install eyed3
# Then run the auto-tagger script from the issue comments
./lyd_auto_tagger_no_backup.sh /path/to/music

Option 4: Feature Request - Pre-Validation

A better long-term fix would be to:

• Fetch YouTube video duration and compare to expected track duration
• Skip results where the title contains obvious red flags ("full album", "playlist", etc. but treat "full album" as valid)
• Validate against Lidarr's release track count before accepting a match

Recommended Workaround

For immediate relief, I'd suggest:

1. Manually curate your first batch by checking YouTube manually for correct versions (full albums vs. compilations)
2. Add blacklist keywords to avoid obvious mismatches
3. Use a post-download metadata fixer to ensure Lidarr can properly index the files
4. Consider opening a PR with enhanced validation logic (checking video duration, validating against Lidarr track counts, etc.)

Would you be interested in contributing a PR with stricter album matching? The validation could check if a YouTube video's duration roughly matches the expected album length.

[addmix]

Why all the AI generated comments, man?