This doesn’t sound like a MA problem as the Nvidia shield works? You say the physical device is crashing so seems like a device problem. Why don’t you just reduce the file size of the images?

Isn't there some sort of "MA applet" which runs on the chromecast while MA is casting to it? I assumed there was and that the bug would be in there somewhere (and is taking out the whole device due to lack of memory protection on the device or something).

It smells like either OOM or some sort of buffer overflow to me. Since the shield likely has a lot more RAM it isn't effected. According to some searches, Chromecast ultras have 1GB and Shields start at 8GB but can have lots more, I didn't check what mine actually has, I suspect that a shiled also has a full MMU capable process so an applet cannot crash the whole device in the same way as it appears it can on an Ultra.

I'd prefer not to downscale the images, if anything I'd want to rescanning the lower res ones at higher resolution (but I doubt I'll ever bother). I don't think the high res images are especially unusual.

No MA just streams to the device.

It seems to activate MASS_APP_ID = "C35B0678" and stream to that, but I can't figure out where that "app" is defined or where the UI (album cover, title of the track etc) are defined. I'd be happy to report this again to wherever that code lives but I haven't been able to find it.

This all comes from the MA server code https://github.com/music-assistant/server/blob/10e13786601d84c6d1e89b458899861f0e8f1296/music_assistant/providers/chromecast/__init__.py#L63

That is sending a message to the chromecast device to tell it to launch that app. It is not (AFAICT) defining the app. It appears that the app is hosted at https://music-assistant.io/cast-receiver/, referred to by "https://clients3.google.com/cast/chromecast/device/app?a=C35B0678", and the source for that appears to be https://github.com/music-assistant/cast-receiver which I hadn't found until now.

Looks like most of the functionality comes from https://www.gstatic.com/cast/sdk/libs/caf_receiver/v3/cast_receiver_framework.js.

You will have to be patient until Marcel can comment then.

I hot patched my container image with the following and it seems to have worked around the issue.

Just the patch to chromecast didn't work, so I think the core player_queues one might be the one which matters, which is a shame since it seems like a too generic place to deal with a chromecast issue. Neither is the hardcoding a good solution IMHO

diff --git a/music_assistant/controllers/player_queues.py b/music_assistant/controllers/player_queues.py
index eb52f897..351a0498 100644
--- a/music_assistant/controllers/player_queues.py
+++ b/music_assistant/controllers/player_queues.py
@@ -1261,7 +1261,7 @@ class PlayerQueuesController(CoreController):
                 album.name if (album := getattr(queue_item.media_item, "album", None)) else ""
             )
             if queue_item.image:
-                media.image_url = self.mass.metadata.get_image_url(queue_item.image)
+                media.image_url = self.mass.metadata.get_image_url(queue_item.image, size = 1024)
         return media
 
     async def get_artist_tracks(self, artist: Artist) -> list[Track]:
diff --git a/music_assistant/providers/chromecast/__init__.py b/music_assistant/providers/chromecast/__init__.py
index fdd5ff54..cc1a2b38 100644
--- a/music_assistant/providers/chromecast/__init__.py
+++ b/music_assistant/providers/chromecast/__init__.py
@@ -675,7 +675,7 @@ class ChromecastProvider(PlayerProvider):
         # update metadata of current item chromecast
         if media_controller.status.media_custom_data["queue_item_id"] != current_item.queue_item_id:
             image_url = (
-                self.mass.metadata.get_image_url(current_item.image)
+                self.mass.metadata.get_image_url(current_item.image, size=1024)
                 if current_item.image
                 else MASS_LOGO_ONLINE
             )

If you think you have a solution then feel free to submit a pr so it can be properly reviewed.

As I said, it's a work around, I don't think this is appropriate as a committed solution. I'll have to dig in a bit more to figure out a path forward.

@marcelveldt may I have your advice on how best to fix this since it's a bit non-obvious what the right fix is. I'll have a some spare cycles of the holiday period to implement something.

If I understand the code correctly the items in a PlayerQueuesController are not aware of the type player they are "for" and due to things like the ability to transfer queues between players I don't think such a relationship can exist.

Given that constraint I can see a few options:

1. Enforce a maximum resolution for all PlayerMedia.image_url (either in player_media_from_queue_item or in get_image_url)
2. Add a second field like PlayerMedia.image_url_lowres which sets a hard coded "small enough for all uses" size field in the URL.
3. Push the call to get_image_url in player_media_from_queue_item down into the individual player providers somehow, perhaps by propagating QueueItem.image directly.

I think 3 is the most technically correct thing to do (out of that list at least) since it pushes the URL generation down to the place which is most aware of the capabilities of the device. OTOH it would involve touching every player...

Both 1 and 2 have the issue of having to decide what res to hardcode (and also deal with the possibility that the source image might be smaller than it).

I suppose there is a half-way-to-3 solution which is to add the image field to allow players to generate their own URL but also to keep the existing image_url for cases which just want the base resolution.

Or maybe you have a better idea or other preference?

If I understand the code correctly the items in a PlayerQueuesController are not aware of the type player they are "for" and due to things like the ability to transfer queues between players I don't think such a relationship can exist.

Actually, I'm having second thoughts about this. Maybe player_media_from_queue_item can actually safely know the target player since the result is always passed directly to an actual concrete player (self.mass.players.play_media or self.mass.players.enqueue_next_media)?

Not sure how that would work with groups though...

The other option is not to send such large images in the first place. A resolution for the cover of 1000x1000 is typically regarded as sufficient?