Fix cloud artwork getting stuck on the placeholder (#138)

[lostf1sh]

Fixes #138.

What was wrong

The media session hands every controller (the app's own included) cloud covers as content://<pkg>.artwork/cloud/.... The player, the notification bitmap loader, and the widgets all loaded that URI through SharedArtworkContentProvider. The provider decodes the cover with the same Coil ImageLoader and streams it into a pipe, while the outer decode blocks reading that pipe.

Coil allows four concurrent BitmapFactory decodes. Once four of these outer decodes were in flight (player carousel + mini player + notification + theme extraction is enough), they held every slot. The inner decodes they were waiting on could never start, so every artwork load in the app stayed on its placeholder until restart. That matches both reports: it breaks after a song or two, and re-syncing doesn't help.

Reproduced on an API 36 emulator against Navidrome 0.64.2. A thread dump of the stuck app showed exactly four BitmapFactoryDecoder threads blocked in ParcelFileDescriptor$AutoCloseInputStream.read.

Changes

• SharedCloudArtworkMappers: Coil mappers turn our own content://…/cloud/… URIs back into navidrome_cover:// / jellyfin_cover:// before fetching. In-process loads no longer go through the provider. External apps still use it.
• RemoteArtworkCache, shared by both cloud fetchers:
  • Only bodies with an image signature are cached. Subsonic servers report getCoverArt errors with HTTP 200, and those bodies used to be cached as .jpg permanently. Poisoned files cached earlier are evicted.
  • Downloads go to a temp file and are then renamed into place. Concurrent requests for the same cover can no longer truncate a file another request is decoding.
• System UI artwork: System UI reads the platform session's artwork URI without connecting as a Media3 controller, so it never got the per-item grant and was refused on every track (3 failed opens per song in logcat). The provider now also allows callers holding MEDIA_CONTENT_CONTROL (signature|privileged; such callers can already read and control every media session). Other apps still need the explicit grant. Stock Android fell back to the session bitmap; System UIs without that fallback could show no artwork.

Testing

• ./gradlew :app:compileDebugKotlin :app:testDebugUnitTest passes.
• New RemoteArtworkCacheTest covers: error body not cached, atomic replace without leftover temp files, eviction of poisoned cache, format signatures.
• SharedArtworkContentProviderTest gains a case for privileged media surfaces.
• Device smoke test (emulator, local Navidrome with 8 albums):
  • Before: artwork stuck after a few skips.
  • After: correct covers and theme through 20 rapid skips. Thread dump shows no blocked decoders.
  • Media controls in the shade: 0 grant failures and the correct album colour across 5 tracks.
• lintDebug was already failing on main (UnsafeOptInUsageError in FadingPlayer.kt, Russian plural quantities, existing MissingTranslation). This PR adds no new lint errors.

Review follow-up (ae19bb4)

• Privileged reads are scoped. Callers holding MEDIA_CONTENT_CONTROL may open only the artwork the session currently publishes. MappingPlayer records it, keeping the last three entries, keyed by song id or raw cloud URI. The list is cleared when MusicService is destroyed.
• No deletion on a failed signature check. A cached body that fails the check is skipped instead of deleted, which removes the race with a concurrent rename. The next successful download replaces it.
• Verified: unit tests pass (SharedArtworkContentProviderTest now 14 tests). On the emulator, the media controls showed the current cover with no denied opens across 4 tracks.

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Fixes artwork loading deadlock in the image cache layer.

The PR appears safe to merge, though the previously noted cloud-cover sharpness reduction remains.

Findings

1.  Cloud covers lose resolution ▶

Fix with agent prompt

### Issue 1
app/src/main/java/com/lostf1sh/pixelplayeross/data/image/SharedCloudArtworkMappers.kt:26-27
The new mappers send in-process cloud artwork straight to the fetchers, but the mapped URIs have no size parameter. Both fetchers therefore request their 500-pixel default instead of the provider’s 1024-pixel artwork. Covers on larger player surfaces may look less sharp.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR routes in-process cloud artwork loads directly to their fetchers, validates and atomically replaces downloaded covers, and limits privileged System UI artwork reads to recently published session artwork.

• The follow-up removes a cache-eviction race and narrows the privileged artwork exception.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  S[Media session] --> M[Mapped artwork URI]
  M --> A[In-app image loader]
  A --> F[Cloud fetcher]
  F --> C[Validated artwork cache]
  M --> U[System UI]
  U --> P[Artwork provider]
  P --> G{Grant or published privileged artwork?}
  G -->|Yes| C
  G -->|No| D[Access denied]

Loading

_{Reviews (2) · Last reviewed commit: "Scope System UI artwork reads to the ses..."}

[greptile-apps]

Cloud covers lose resolution
The new mappers send in-process cloud artwork straight to the fetchers, but the mapped URIs have no size parameter. Both fetchers therefore request their 500-pixel default instead of the provider’s 1024-pixel artwork. Covers on larger player surfaces may look less sharp.

Prompt To Fix With AI

This is a comment left during a code review.
Path: app/src/main/java/com/lostf1sh/pixelplayeross/data/image/SharedCloudArtworkMappers.kt
Line: 26-27

Comment:
**Cloud covers lose resolution**
The new mappers send in-process cloud artwork straight to the fetchers, but the mapped URIs have no size parameter. Both fetchers therefore request their 500-pixel default instead of the provider’s 1024-pixel artwork. Covers on larger player surfaces may look less sharp.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[lostf1sh]

Not a regression. Before this PR the provider's inner request also loaded navidrome_cover://<id> with no size parameter, so the fetchers already requested 500 px. CLOUD_ARTWORK_SIZE_PX only set the decode target, not the server request, so the image and its resolution are unchanged. Raising the default request size would be a separate change.

[greptile-apps]

You're right — this is not a regression. Before this change, the provider's inner ImageLoader request already used navidrome_cover:///jellyfin_cover:// without a size parameter, so the fetchers requested their existing 500 px default. CLOUD_ARTWORK_SIZE_PX only controlled the decode target, not the server-requested artwork size. Mapping the URI directly therefore preserves the same source resolution; increasing the request default would be a separate improvement. I'll withdraw this finding.