You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
*arr log file ingestion produces no log entries (Sonarr/Radarr/Prowlarr/Whisparr) #63
File ingestion for the *arr apps never creates log entries, even when log paths are configured correctly and the files are discovered and tailed. Jellyfin, Emby and Plex file ingestion is not affected.
Why
There are two independent causes.
Timestamp regex. The *arr apps write their log files with the NLog layout yyyy-MM-dd HH:mm:ss.f, which has one fractional digit, e.g. 2026-10-10 12:00:01.2|Info|RssSyncService|…. NLOG_LINE_REGEX in packages/provider-arr/src/arr.parser.ts requires exactly three digits (\.\d{3}), so real lines don't match.
Context-parser contract.LogFileProcessor finalizes its pending entry before asking the provider to parse a new header line, as the parseLogLineWithContext contract in packages/core/src/types.ts describes (the Emby parser follows it). parseArrLogLineWithContext instead returns the previous entry and stores the current one in the context object, which the processor discards. As a result, no entry is ever emitted. A blank line between a message and its exception (NLog writes one) also used to drop the stack trace.
To reproduce
Mount a Sonarr or Radarr logs/ directory, enable file ingestion for that source, and watch the Logs page: tailing starts, but no *arr file entries appear.
Fix
#57. It fixes both causes and moves exception extraction into an optional finalizeLogEntry hook. It also skips the apps' *.debug.*/*.trace.* rolling logs. Once ingestion actually works, Radarr alone typically has 50+ debug files, and backfilling them exhausted a 384 MB container's Node heap in my deployment. The PR includes end-to-end LogFileProcessor tests with real SonarrProvider and EmbyProvider instances.
Activity