Repository navigation
feat(providers): add Lidarr integration - #60
Merged
Merged
Conversation
…amps *arr apps write log files with the NLog layout yyyy-MM-dd HH:mm:ss.f (a single fractional digit), so real Sonarr/Radarr/Prowlarr/Whisparr lines did not match the parser regex, which required exactly three digits, and were dropped or treated as continuations.
LogFileProcessor finalizes the pending entry before asking the provider to parse a new header line, as the parseLogLineWithContext contract in core expects (Emby and others return the current entry). The *arr context parser instead returned the previous entry and stashed the current one in the caller's context, which the processor discards, so file-tailed Sonarr, Radarr, Prowlarr and Whisparr logs produced no entries at all. - parseArrLogLineWithContext now returns the current entry for header lines, flags continuations, and ignores blank lines (NLog writes one between a message and its exception) - Exception extraction moves to finalizeArrLogEntry, invoked through a new optional finalizeLogEntry hook in LogFileProcessor; it strips the "[vX.Y.Z.W]" prefix so the exception type and message are populated - End-to-end LogFileProcessor tests with real Sonarr and Emby providers
…re finalizeLogEntry on core provider interface
Add @logarr/provider-lidarr on top of the shared provider-arr base, using Lidarr's v1 API. - v1 ArrClient with history and history/since (includeArtist/includeAlbum) - History normalization for all EntityHistoryEventType values, accepting numeric and camelCase event types; downloadFailed and unknown "*Failed" events are errors, albumImportIncomplete is a warning; stable lidarr-history-<id> activity ids - Reuses the existing LIDARR_LOG_FILE_CONFIG for lidarr.txt file tailing - Backend registration, env seeding (LIDARR_URL/LIDARR_API_KEY, /lidarr-logs), Dockerfiles, compose, turbo env - Frontend: Lidarr integration flipped to available, logs deep link - README updates
…h provider conventions
…ith sibling *arr providers
vbrzezina
force-pushed
the
feat/lidarr-integration
branch
from
October 10, 2026 18:46
8f1fa6a to
9dd27c6
Compare
Contributor
Author
|
Part of a set of integration PRs. Overview, merge order and design notes: #64 |
vbrzezina
marked this pull request as ready for review
October 12, 2026 16:43
itz4blitz
approved these changes
Oct 13, 2026
itz4blitz
left a comment
itz4blitz
left a comment
Owner
There was a problem hiding this comment.
Approving, and merging this after #57.
The Lidarr provider matches the Sonarr/Radarr shape: id lidarr, API v1, history events 0–10, log file lidarr.txt, registered in both ingestion.service.ts and servers.service.ts, and the frontend card is available with the standard API fields. I merged #57 first and checked the combined tree: ARR_LOG_EXCLUDE_PATTERNS stays on every *arr config, including Lidarr. Merging this branch by itself would have dropped that exclusion, because this branch does not contain 0808207.
Follow-up, not blocking: issue_source has no lidarr value, so Lidarr warn/error issues are stored as system. Whisparr, Emby, and Plex already take that path. Adding lidarr needs a migration.
This was referenced Oct 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a Lidarr integration (
@logarr/provider-lidarr) on the sharedprovider-arrbase, using Lidarr's v1 API.ArrClientsubclass for the v1 API readshistoryandhistory/sincewithincludeArtistandincludeAlbum.provider-arrhelpers from fix: *arr log file ingestion emits no entries (timestamp regex + context parser contract) #57 (resolveArrEventName,describeArrEvent,toArrItemId). The Readarr PR uses the same helpers and severity table, so the two behave the same.EntityHistoryEventTypevalue (0–10, checked against Lidarr source). Numeric and camelCase event types are both accepted.downloadFailedand any unknown*Failedevent are errors.albumImportIncompleteis a warning.lidarr-history-<id>.itemIdis left unset rather than set to"0".LIDARR_LOG_FILE_CONFIGto taillidarr.txt.LIDARR_URL,LIDARR_API_KEYandLIDARR_LOGS_PATH, mounted at/lidarr-logs;turbo.jsonenv;available, with a logs-page deep link;Testing
@logarr/provider-lidarrhas 103 unit tests covering:X-Api-Keyheader, retries, and 401 handling;pnpm build,lint,typecheckandtestall pass.pnpm install --frozen-lockfileis clean, and the lockfile diff only adds the new package.