navidrome/navidrome · error
getting last scan time: %w
Error message
getting last scan time: %w
What it means
Status wraps a failure from getLastScanTime with 'getting last scan time: %w', so any datastore error while fetching the last scan timestamp bubbles up as a ScannerStatus failure. The scanner itself is fine; the persistence layer answering 'when did we last scan?' failed.
Source
Thrown at scanner/controller.go:153
if running.Load() {
elapsed = time.Since(startTime)
} else {
// If scan is not running, calculate elapsed time using the most recent scan time
lastScanTime, err := s.getLastScanTime(ctx)
if err == nil && !lastScanTime.IsZero() {
elapsed = lastScanTime.Sub(startTime)
}
}
}
}
return scanType, elapsed, lastErr
}
func (s *controller) Status(ctx context.Context) (*model.ScannerStatus, error) {
lastScanTime, err := s.getLastScanTime(ctx)
if err != nil {
return nil, fmt.Errorf("getting last scan time: %w", err)
}
scanType, elapsed, lastErr := s.getScanInfo(ctx)
if running.Load() {
status := &model.ScannerStatus{
Scanning: true,
LastScan: lastScanTime,
Count: s.count.Load(),
FolderCount: s.folderCount.Load(),
LastError: lastErr,
ScanType: scanType,
ElapsedTime: elapsed,
}
return status, nil
}
count, folderCount, err := s.getCounters(ctx)View on GitHub (pinned to 4ed7494a32)
Solutions
- Check the wrapped inner error in logs ('getting libraries: ...') and fix the database connectivity issue
- Restart Navidrome to rebuild DB connection pools after a database failover
- Run migrations if the schema is out of date (e.g. after an upgrade)
- If using an external Postgres/MySQL, verify the server is up and network/firewall allows the connection
Defensive patterns
Strategy: retry
Try / catch
status, err := ctrl.Status(ctx)
if err != nil {
if strings.Contains(err.Error(), "getting last scan time") {
// DB unavailable; degrade gracefully instead of failing the endpoint
return &model.ScannerStatus{Scanning: false}, nil
}
return nil, err
} Prevention
- Wrap status endpoints with health checks on the database first
- Configure DB client timeouts and reconnect policies
- Degrade gracefully: return a partial status rather than failing the whole API call
- Verify migrations run at startup before serving the API
When it happens
Trigger: Calling controller.Status while the libraries table cannot be queried — DB unavailable, schema mismatch, or datastore error from getLastScanTime.
Common situations: Monitoring/dashboard endpoints hitting /api/scanner status during a DB outage; stale connection pools after a database failover; partially completed migrations.
Understand the failure class
Background: Database query failed: Internal Server Error 500s wrapping SQL, Prisma, and connection failures — what to check first — this error's family across 16 libraries.
Related errors
- getting library stats: %w
- getting libraries: %w
- library count: %w
- failed to match tracks by ID: %w
- failed to match tracks by MBID: %w
AI-assisted analysis of navidrome/navidrome@4ed7494a32 (2026-09-01).
Data as JSON: /api/errors/46ca69d6ec59f390.
Report an issue: GitHub.