fix: show album art on Chromecast by sending a fetchable cover-art URL#852
Open
herrerad85 wants to merge 1 commit into
Open
fix: show album art on Chromecast by sending a fetchable cover-art URL#852herrerad85 wants to merge 1 commit into
herrerad85 wants to merge 1 commit into
Conversation
Media items carry their artwork as a content:// URI served in process by AlbumArtContentProvider. That is fine for the local player but useless to a Chromecast: the receiver is a separate device and cannot open another app's content:// URI, so no album art shows while casting (the local now-playing screen is unaffected because it reads the same URI in process). CastPlayer was built with the default MediaItemConverter, which forwards the content:// URI to the receiver unchanged. Wrap it in a CastMediaItemConverter that rewrites a content:// artwork to the server cover-art URL via CustomGlideRequest.createUrl(), which already builds a fully authenticated getCoverArt URL the receiver can fetch on its own. Radio covers (rl_/ir_) are left untouched. Verified at the converter level with a new instrumented test (CastArtworkConverterTest): the default converter emits a content:// image, and CastMediaItemConverter emits the getCoverArt URL. Also confirmed on a real Chromecast: album art now shows while casting.
Contributor
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #115.
Problem
Media items carry their artwork as a
content://URI served in-process byAlbumArtContentProvider. That works for the local player, but a Chromecast receiver is a separate device and can't open another app'scontent://URI, so no album art shows while casting. The local now-playing screen is fine because it reads the same URI in-process. The reporter confirmed it as a Chromecast issue.Fix
CastPlayerwas built with the defaultMediaItemConverter, which forwards thecontent://URI to the receiver unchanged. This wraps it in aCastMediaItemConverterthat rewritescontent://artwork to the server cover-art URL viaCustomGlideRequest.createUrl(), which already builds a fully authenticatedgetCoverArtURL the receiver can fetch on its own. Radio covers (rl_/ir_) are left untouched.Testing
CastArtworkConverterTest: the default converter emits acontent://image, andCastMediaItemConverteremits thegetCoverArtURL.:app:assembleTempusDebugon JDK 21.