[Bug]: Offline cache is a frozen snapshot — never reconciles (playlists, albums, artists)

[artplan1]

What's wrong?

Offline cache snapshots track IDs at download time and never resyncs. If the source's contents change on the server afterwards, the cache silently goes stale.

Steps to reproduce

1. Cache a playlist offline.
2. On the server, add a track to that playlist (and/or remove one).
3. Reopen the playlist in Psysonic.

What should happen?

Cache reflects current contents — new track downloaded, removed track's file deleted.

What actually happens?

• Added track: never downloaded. Button stays on "Remove offline" — no way to pull the new track without delete + re-download.
• Removed track: file orphaned on disk, dead ID kept in meta.trackIds.

Root cause: downloadAlbum stores trackIds = songs.map(s => s.id) once; isCached checks that snapshot, not live contents. No resync path exists. Same applies to albums and artist downloads.

Suggested fix: resyncOffline(albumId, currentSongs, serverId) diffing meta.trackIds vs current IDs — download missing, delete removed, update meta. Call on opening a cached item.

Psysonic version

1.46.0

Operating system

macOS

Install source

.dmg (macOS)

Subsonic-compatible server

Navidrome

Server version

No response

Logs

Screenshots / video

No response

Anything else

Let me know if this makes sense and I'll work on PR

[cucadmuh]

Thanks for the detailed write-up — your root-cause analysis is spot on. The offline cache currently snapshots trackIds at download time and has no resync path, so added tracks are never pulled and removed ones are left orphaned, exactly as you describe. This applies to albums, playlists, and artist downloads alike.

Rather than patch the snapshot logic in isolation, we're building this on top of a shared local library index that's already underway. Offline-album tracking will hang off that index, so membership changes on the server are reconciled centrally — missing tracks downloaded, removed tracks cleaned up (file + metadata), and track-ID churn (e.g. Navidrome re-issuing IDs) handled gracefully. This is targeted for v1.48.

Because of that, a PR against the current snapshot mechanism would unfortunately be superseded by these changes and become moot once they land — so we'd suggest holding off on implementing it. We really appreciate the offer, though.

The important part: the scenario you outlined is now explicitly captured in the design, so we definitely won't lose track of it. Thanks again for the clear report and for offering to help.

PS: We can discuss the details in our Discord or Telegram.