octaviospain
## Context `ItunesCompilationsLibraryE2E` imports ~1170 tracks and then asserts every item's artist catalog is present and the Artists view populates. On slower CI runners (deterministically on Windows, ~25% on Linux even at a 240s wait) the artist-catalog projection never fully converges within the wait — hundreds of catalogs remain missing — so the test fails. Root cause is a music-commons performance bug: `FXAudioLibrary.refreshCatalogProperties()` clears and fully rebuilds all three FX collections (artist catalogs, albums, genre indexes) on every debounce tick, so a large import does O(n²) FX-thread work that starves the catalog projection's own FX-thread build. It surfaced when the Genres feature added a third live projection. - music-commons bug: octaviospain/music-commons#176 - music-commons fix (incremental refresh): octaviospain/music-commons#177 ## Interim `ItunesCompilationsLibraryE2E` is temporarily `@Disabled` so the branch's CI is green while the fix lands upstream. ## To do once music-commons #177 is released 1. Bump Musicott's `music-commons` version in `gradle/libs.versions.toml` to the release containing #177. 2. Re-enable `ItunesCompilationsLibraryE2E` (remove the `@Disabled`). 3. Apply the observation fix that was prototyped: evaluate the `waitForArtistCatalogs` check **on the FX thread** (the catalog registry is mutated on the FX thread, so an off-thread poll can read a partial/stale view). With #177 the catalogs converge quickly and the FX-thread read makes the assertion reliable (verified locally: 5/5 green against the fix snapshot). 4. Restore the catalog wait to a normal timeout (the temporary long wait is no longer needed once the refresh is incremental).