mirror of
https://github.com/RandomNinjaAtk/arr-scripts.git
synced 2026-03-02 22:57:35 -05:00
Lidarr - Downloading Unmonitored Albums #54
Labels
No labels
Needs Triage
Not Reproducible
Upstream Issue
User Error
bug
documentation
enhancement
good first issue
help wanted
invalid
lidarr
lidarr
question
radarr
readarr
sabnzbd
sonarr
synology (host)
unraid (host)
waiting for logs
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/arr-scripts#54
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Simpuhl on GitHub (Sep 14, 2023).
Application
Lidarr
Host platform
Synology
Script
https://github.com/RandomNinjaAtk/arr-scripts/blob/main/lidarr/readme.md
Script Version
Latest
Describe the bug
Downloading and importing unmonitored albums that are not part of Missing/Cutoff Unmet.
To Reproduce
Not sure how-to re-produce exactly and it may be my fault, but I am just letting it do its thing and I keep finding new albums that don't even exist in my library to begin with.
Expected behavior
Only download monitored albums in Missing/Cutoff Unmet.
Logs/Screenshots
N/A - Can provide if needed but this might just be user error.
Additional context
The only thing I am thinking is because I have this:
matchDistance="10"
But my assumption that means 10 track difference? Like if i have a regular album, I'd prefer it to get the deluxe if its available. Let me know if this is the reason so I can just set this to 0.
NOTE
Your request will not be addressed without proper detail and logs. Always make sure you have updated to the latest script versions before opening an issue or your issue will not be reviewed.
@RandomNinjaAtk commented on GitHub (Sep 14, 2023):
matchDistance, is a distance calculation. It compares both album titles, with a match distance of 10, that means the album title can have 10 differences in case/lettering and still match...
So the higher the number, the less accurate it will be....
Example
Album 1 vs album 2 = 2 differences and is less than 10, so it would match... (Number and case is different)
For more information on it, see here: https://en.wikibooks.org/wiki/Algorithm_Implementation/Strings/Levenshtein_distance
The script tries to make the matching a bit easier by lowercasing everything and removing special characters, to just get letters and numbers for the comparison as a single string. So your probably better off leaving at the default or lowering it if you want to make the matches more accurate.
If you read the logs, you should see what the comparison is and what the distance was calculated at....
The script will only download what lidarr tells it to, but the matching process isn't perfect and your problem is most likely caused by your matchDistance setting. Lowering it should improve it, but there still may be small usecases where it's a problem.
I welcome any PR requests from anyone whom thinks they have a better way to improve the matching process.... A recent change was made that possibly made the process worse than it was previously, but that was to resolve a different issue and I couldn't think of another way to resolve that....
See this issue: #67
Edit:
A big problem with the current implementation is if you have multiple albums with almost the same name, like:
My Album 1
My Album 2
My Album 3
All 3 albums would result in a match distance of 1. So the script would just grab the first one, and you may have been searching for the 3rd album.... The script will likely eventually get to the 3rd album, but it would only most likely happen after downloading and processing the others as an attempt....
2nd Edit:
If you provide logs of examples, it will be easier to see what is going on, but what I stated above is most likely the problem...
@Simpuhl commented on GitHub (Sep 14, 2023):
Maybe pull the track listing and look for X amount of tracks comparison from what's in lidarr vs what it found. If it has atleast X same tracks then it can be used.
But also maybe add words like remastered, deluxe, extended as preferred (optional) if they are part of the title when searching? Idk just talking out of my ass
@RandomNinjaAtk commented on GitHub (Sep 14, 2023):
It already filters by track count.
@Simpuhl commented on GitHub (Sep 14, 2023):
Here some recent logs, I can't find any recent albums as I cleared all the previous albums out so it would retry them all... but I did catch something here:
https://privatebin.net/?ffa4c7f81b10a691#9svFN56SdFu1M9mHeMxj61MoyUEXup5CQpbv6nVXrLZZ
If you look at the album for Akon - Freedom
It download all the tracks successfully, but it never imports it?
I double checked and I still have v0 mp3 and no flacs. I found it interesting so I wanted to share it.
I managed to download the entire album from Deemix (deezer) without any issues, it does have UNMATCHED tracks, could that be why? If so, I am curious if we can have it do something in this scenario where it puts it in a different folder and waits for you to add these missing albums into MusicBrains?
https://i.imgur.com/JHMhW9Y.png
@RandomNinjaAtk commented on GitHub (Sep 15, 2023):
The script basically just downloads and tells lidarr a download finish and is ready for import, after that, it is all up Lidarr.... So when something does not import, you have to look at lidarr logs to identify the reason. Lidarr handles the entire import process and there is nothing that can be done on the scripts end...
FYI: the script is better at handling missing albums than upgrading them based on the cutoff list. Because when attempting to upgrade via cutoff, the script has to ignore the existing files, so it can try anyways and this can be result in problematic/undesirable results at times...