austinried b171b0b33c stream sync with SAX and write the library per batch ...

The DOM-based sync materialised the whole library in memory before
writing: SubsonicSource accumulated every paged response into one list
and SubsonicClient built a full DOM per response, so peak memory grew
with the library size (hundreds of MB for large libraries).

Replace it with a streaming pipeline:

- SubsonicXml is now a SAX reader that maps entities straight from the
  stream. Album disc titles are accumulated from child elements and
  attached when the album closes.
- SubsonicClient exposes stream()/check() instead of returning a DOM.
- MusicSource returns batches as Flow<List<T>>; SubsonicSource emits one
  batch per response page with backpressure so only one batch is held.
- SyncService syncs each entity sequentially, commits one transaction
  per batch, and prunes with an existing-minus-seen stale set. Playlist
  song tails are pruned once the whole flow has been counted, and
  orphaned playlist_songs rows are removed with a single delete.

Sync is no longer atomic: on failure the committed batches remain and
the queue's library cache is now invalidated on failure too.

2026-10-04 00:29:58 +00:00

..

schemas/com.subtracks.data.db.SubtracksDatabase

show album disc titles instead of generic disc numbers

2026-10-04 00:29:57 +00:00

src

stream sync with SAX and write the library per batch

2026-10-04 00:29:58 +00:00

build.gradle.kts

parse Subsonic dates with java.time via core library desugaring

2026-10-04 00:29:55 +00:00