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
2022-04-28 15:41:45 +09:00
v2
2023-04-28 12:26:02 +09:00
v2
2023-04-28 12:26:02 +09:00
2026-10-04 00:29:56 +00:00
2021-08-23 14:48:24 +09:00
2022-06-20 19:01:25 +09:00
S
Description
A music streaming app for Subsonic-compatible servers
GPL-3.0
58 MiB
Languages
Kotlin 99.1%
Nushell 0.7%
Nix 0.1%