austinried e142148b5a stop locating the playing queue entry by song id ...

The queue can hold the same song more than once (a song in both the context
and the up-next block, a duplicate album track, ...), so resolving the
playing entry by song id could match the wrong copy.

- `PlaybackController.move` and `removeAt` now derive the current track's
  new position from the edit (block index / context play, read back through
  the updated snapshot so a moved anchor is accounted for) instead of
  `combinedIndexOf`/`combinedContextIndexOf`.
- the queue view's playing highlight compares the row position to the
  playback position instead of the song id, so duplicates no longer both
  light up.

Regression tests cover a move and a remove with a duplicate song in the
context; both fail without the change.

Still id-based, deliberately: `undo`'s canMirror guard (already position-
guarded), the shuffle-state-changed branch of `shiftWindowLocked` (rare,
needs the id to find the track after an arbitrary reorder) and the view's
LazyColumn keys (cosmetic only).

2026-10-04 00:30:01 +00:00

..

schemas/com.subtracks.data.db.SubtracksDatabase

rework: derive the shuffle order from a seed on top of the up-next queue

2026-10-04 00:30:01 +00:00

src

stop locating the playing queue entry by song id

2026-10-04 00:30:01 +00:00

build.gradle.kts

parse Subsonic dates with java.time via core library desugaring

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