Fixed crash when Chromecast publish an artwork#99
Conversation
…oo large and should not converted in base64. Tested successfully with the direct URL
| if status.images and len(status.images) > 0 and status.images[0].url != self._media_image_url: | ||
| self._media_image_url = status.images[0].url | ||
| update[MediaAttr.MEDIA_IMAGE_URL] = await encode_icon_to_data_uri(self._media_image_url) | ||
| update[MediaAttr.MEDIA_IMAGE_URL] = self._media_image_url |
There was a problem hiding this comment.
This makes sense and removes quite a bit of overhead. As the name implies, this should be an URL and usually the UI app will download and resize the image.
A base64 encoding should only be used for local images that he UI app cannot access. For example the app icons or the homescreen icon.
There's one more reference where the image URL is set in _apply_current_app_metadata on line 670:
However, the encoded image in icon_to_use is never applied with the inverse if not self._media_image_url logic:
elif self._media_image_url:
icon_to_use = await encode_icon_to_data_uri(self._media_image_url)
update[MediaAttr.STATE] = media_player.States.PLAYING.value
# Skip applying app icon if media image from cast is present
if not self._media_image_url:
if not icon_to_use:
update[MediaAttr.MEDIA_IMAGE_URL] = HOMESCREEN_IMAGE
else:
update[MediaAttr.MEDIA_IMAGE_URL] = icon_to_useFor consistency reasons I'll update it in this PR. It needs to be checked later what the correct logic should be: either be removed, because it's not needed, or fixed if the media image must be set as a fallback.
…ay be too large and should not converted in base64. Tested successfully with the direct URL
I don't know why but the artwork URL submitted by Chromecast protocol was converted to base64 data. This is not necessary and makes the websocket crash when the data is too large, which is the case with one report on discord : https://discord.com/channels/553671366411288576/1144203300091199539/1423920294028120075
I just removed the conversion to binary 64 and tested successfully : the image is displayed correctly on the remote with the direct URL.
I also updated the libraries (minor changes) in requirements