feat: index the library from Lidarr and match it against the scrobbles
Build and publish container / build (pull_request) Successful in 10m2s
Build and publish container / build (pull_request) Successful in 10m2s
Stage two. The scrobble history says what was played by name; Lidarr says what is owned, and where the files are. Neither is useful for curation until the two are tied together, and the quality of that join is what decides whether the later cull can be trusted at all. The index is a wholesale rebuild of every artist, album and track Lidarr holds, including file paths and the date each file landed -- the latter for the age floor a cull will need. It is rebuilt rather than reconciled because Lidarr is the authority and a deletion there has to disappear here, not linger as a library entry with no file behind it. Every call is a GET; nothing is written back. Matching runs at the level of the distinct artist/track pair rather than the individual play, because a verdict is a property of the name pair and there are three plays for every one of them. Two tiers: a MusicBrainz recording id, which Last.fm supplies per scrobble and Lidarr exposes as ForeignRecordingId, gives an exact join; everything else falls to a normalised name comparison. There is deliberately no third tier. A near-miss guess is worse than an admitted one, since the entire purpose of the resulting number is to state how far the matching can be relied on. Normalisation folds the ways the two sides habitually disagree: case, accents, guest credits that Last.fm puts in the artist field, trailing version suffixes, ampersands, and a leading article. Punctuation needs two opposing rules and both are load-bearing -- apostrophes are deleted so "Don't" meets "Dont", while every other mark becomes a space so "AC/DC", "AC-DC" and "AC DC" meet as well. It errs towards collapsing too much: a false match makes a track look played, a missed match makes it look abandoned, and only the second one loses music. The coverage report deliberately does not lead with matched versus unmatched. Most unmatched listening is music that was never in the library and says nothing about the matcher. The figure that matters is unmatched listening by an artist the library does hold: a track that was played, sitting next to a file it should have matched. The worst fifteen are listed by play count. The schema gains its tables additively and migrates a version 1 store in place, because rebuilding a nine-year history costs several thousand API requests.
This commit is contained in:
@@ -17,6 +17,10 @@ services:
|
||||
# enough, none of the endpoints used here authenticate a user.
|
||||
MUSIC_CURATOR_LASTFM_API_KEY: set-me-in-the-truenas-ui
|
||||
MUSIC_CURATOR_DB: /data/curator.db
|
||||
# Lidarr, for indexing the library. Read-only: every call is a GET.
|
||||
# Leave unset to ingest scrobbles and nothing else.
|
||||
MUSIC_CURATOR_LIDARR_URL: http://lidarr:8686
|
||||
MUSIC_CURATOR_LIDARR_API_KEY: set-me-in-the-truenas-ui
|
||||
# How long to wait between passes. Each one catches up on new scrobbles
|
||||
# and continues the backfill if it has not finished.
|
||||
MUSIC_CURATOR_INTERVAL: 6h
|
||||
|
||||
Reference in New Issue
Block a user