Media Control Card no cover art with Chromecast, Pandora

The Lovelace Media Control card shows only a light blue, no art.

Until v115 it reliably displayed album art for a chromecast device to which I cast audio using Pandora.
Now (with 115) it shows only a light blue, no art.
A search here for the relevant keywords shows a number of cases from the past, but none current, so since it was working until 115 I’m reporting here in case it’s a new bug.
I see log entries which may be related - example below.

Logger: aiohttp.server
Source: components/media_player/__init__.py:850
First occurred: 1:08:21 PM (81 occurrences)
Last logged: 6:18:41 PM

Error handling request
Traceback (most recent call last):
  File "/srv/venv3.7.3/lib/python3.7/site-packages/aiohttp/web_protocol.py", line 418, in start
    resp = await task
  File "/srv/venv3.7.3/lib/python3.7/site-packages/aiohttp/web_app.py", line 458, in _handle
    resp = await handler(request)
  File "/srv/venv3.7.3/lib/python3.7/site-packages/aiohttp/web_middlewares.py", line 119, in impl
    return await handler(request)
  File "/srv/venv3.7.3/lib/python3.7/site-packages/homeassistant/components/http/request_context.py", line 18, in request_context_middleware
    return await handler(request)
  File "/srv/venv3.7.3/lib/python3.7/site-packages/homeassistant/components/http/ban.py", line 72, in ban_middleware
    return await handler(request)
  File "/srv/venv3.7.3/lib/python3.7/site-packages/homeassistant/components/http/auth.py", line 127, in auth_middleware
    return await handler(request)
  File "/srv/venv3.7.3/lib/python3.7/site-packages/homeassistant/components/http/view.py", line 129, in handle
    result = await result
  File "/srv/venv3.7.3/lib/python3.7/site-packages/homeassistant/components/media_player/__init__.py", line 894, in get
    data, content_type = await player.async_get_media_image()
  File "/srv/venv3.7.3/lib/python3.7/site-packages/homeassistant/components/media_player/__init__.py", line 425, in async_get_media_image
    return await _async_fetch_image(self.hass, url)
  File "/srv/venv3.7.3/lib/python3.7/site-packages/homeassistant/components/media_player/__init__.py", line 850, in _async_fetch_image
    response = await websession.get(url)
  File "/srv/venv3.7.3/lib/python3.7/site-packages/aiohttp/client.py", line 483, in _request
    timeout=real_timeout
  File "/srv/venv3.7.3/lib/python3.7/site-packages/aiohttp/connector.py", line 523, in connect
    proto = await self._create_connection(req, traces, timeout)
  File "/srv/venv3.7.3/lib/python3.7/site-packages/aiohttp/connector.py", line 859, in _create_connection
    req, traces, timeout)
  File "/srv/venv3.7.3/lib/python3.7/site-packages/aiohttp/connector.py", line 963, in _create_direct_connection
    assert port is not None
AssertionError
1 Like

Further study led me to believe it’s a bug in the aiohttp library. It complains there’s no port set. Something is supposed (presumed by the library) to set 80 as a default port, but isn’t doing so (probably because it’s a new requirement by the lib).
I added a couple lines to it - temporarily working around the problem:

if port is None:
  port = 80

I have this exact issue as well. I kinda thought it would get fixed by now.

I run what was formerly known as hass.io. I suspect there is no simple way for me to fix this?

I just go over into …/lib/… and edit the py code to fix until they incorporate a fix in the release.

OK, I think I figured out the cause.

What application are you trying to stream when this happens? I am using SiriusXM. Can you use the developer tools and check on the attributes of the chromecast when streaming? Specifically I am looking for the value of entity_picture.

For SiriusXM it looks like

entity_picture: //albumart.siriusxm.com/albumart/0030/NDCA-000250211-001_m.jpg

Note is lacks the protocol (http:, https:) prefix. I think yours will show the same.

I usually stream from Pandora, and not all their cover art is via HTTPS. Some is un-ssl’d.
This bug appeared elsewhere, too. I’ll make a wild guess: The authors of the aiohttp library decided to drop the default assumption that port==80 unless specified otherwise, and the author of the HA integration didn’t notice that breaking change, or simply hasn’t adapted to it yet.
A simple enough cause/reason/solution.

I posted the issue here - https://github.com/home-assistant/core/issues/43876

Looking at all the change logs for HA, aiohttp, and YARL, it isn’t clear that this has worked in a while if ever. Or maybe things changed in a complicated way that I can’t decipher. But I am confident I have figured out the underlying cause, the lack of scheme. Now it is just a question of whether HA is going to accept the responsibility to apply a default scheme or if they are going to try and kick this down the road to aiohttp and assert that they should fix it.

that sounds more political than technical to me, so I’ll bow out of assigning responsibility, as I’m sure these two sane parties will sort it out.
If someone changes their API on me, I first want to confirm that it’s for a sane reason (while presuming it was so - innocent/sane until proven otherwise), and if they are sane then I would shift to wishing for a more accurate way of ensuring receipt of notices of breaking changes.
Not sure of which side of the river that responsibility lives on. Perhaps both.

Good news, a patch has been merged.