Closed Crocmagnon closed 3 years ago
Hmm, since the last message is artwork, perhaps this is related to #609 somehow. Will have to check a bit more.
FYI I reproduced it today with how I met your mother on Netflix.
Don’t have a log though.
After quickly reading #609, yeah it seems related.
I didn’t notice it with older (but recent, like 1-2 weeks ago) releases of pyatv.
Would there be something I could do to help resolve this issue? 😊 It breaks a non-null amount of workflows for me 😛
It would kinda be interesting to narrow it down to see if artwork is the problem. If you could remove artwork support and try again, that would be great input. You just need to remove the media_image_hash
and async_get_media_image
methods from media_player.py.
I tried the following:
Here are the logs of the second attempt (the failed one): https://gist.github.com/Crocmagnon/39bfcb056bcf3f84eff23f818d817074
So I'd be tempted to say that the issue is indeed linked to the artwork :)
As a workaround, I'm keeping the methods commented for the moment.
Ah, that is excellent work! 😊 This at least gives me something to work with. I will have to dig a bit into the code to figure out what is happening.
If you want to help out some more, there's one thing to try out. I would like to know if we get stuck inside pyatv when requesting the artwork. So, if we add some log points before and after the artwork is fetched, then we can see if we get "stuck" by matching those log points. I'm thinking something along the lines of:
async def async_get_media_image(self):
"""Fetch media image of current playing image."""
state = self.state
if self._playing and state not in [STATE_OFF, STATE_IDLE]:
_LOGGER.warning("fetching artwork")
artwork = await self.atv.metadata.artwork()
_LOGGER.warning("artwork fetched")
if artwork:
return artwork.bytes, artwork.mimetype
return None, None
Using warning to make it easier to spot in the log.
I can't reproduce the issue this morning after having upgraded HACS from 0.24.3 to 0.24.4.
No luck reproducing after re-downgrading to 0.24.3 either. I'll re-upgrade and check later in the day.
Got it again tonight: https://gist.github.com/Crocmagnon/bca786061b941a0e954688953484d943
Didn't do anything special this time, but it's frozen to the second to last episode we watched ("Petits sabotages entre amis")
Hmm, based on the logs I don't see anything "strange", but state changes doesn't seem to come. I assume you watched mentioned episode and continued with the next? Based on that at least... you started to watch around 21:02:07 and the duration is 1316s=22min, so we should see some updates around 21:24. But there are none. Not really sure why or what is blocking here.
I assume you watched mentioned episode and continued with the next?
You are correct.
I noticed these were present both in you first and last log:
May 09 21:31:55 architect hass[18673]: 2020-05-09 21:31:55 ERROR (MainThread) [homeassistant.core] Error doing job: Fatal read error on socket transport
May 09 21:31:55 architect hass[18673]: Traceback (most recent call last):
May 09 21:31:55 architect hass[18673]: File "/usr/lib/python3.7/asyncio/selector_events.py", line 801, in _read_ready__data_received
May 09 21:31:55 architect hass[18673]: data = self._sock.recv(self.max_size)
May 09 21:31:55 architect hass[18673]: TimeoutError: [Errno 110] Connection timed out
Since no information is available that allows us to trace back to its source, we can't really draw any conclusions. But perhaps it's related to pyatv? Strange thing is that it's not signaled back to pyatv in that case. Any why does it even happen? Would it be possible for you to take a traffic dump with tcpdump (e.g. tcpdump -w traffic.pcap "host <ATV ip>
)? It could help me find if the connection is closed.
I just tried your suggestion but couldn't reproduce the bug. Sorry 😕
@Crocmagnon Just wanted to see if you are still running with my integration and if you still see these issues with latest update?
I’ve upgraded recently and haven’t had yet the time to test. I’ll be able to tell you more on Monday ! 🙂
I couldn't reproduce the bug on 31c334e today 👍 I'm closing this issue, I'll comment here later if I happen to reproduce it!
Running on integration commit 6e8190c, Home Assistant 0.115.0, tvOS 14 I reproduced the issue this morning. Unfortunately I don't have any logs to share.
It happened with the Music app.
I'll upgrade HA to 0.115.2 and will keep you updated if I encounter it again.
@Crocmagnon Can you please retry with latest version of Home Assistant (beta component not needed, but works as well)?
I haven't noticed any issue with the latest HA version (using the new stable integration). Again, I'll close the issue and I'll reopen it if I notice it again 🙂
Describe the bug Sometimes, the info of a played media "stick" in the home assistant media player view. I reproduced it with Netflix and Molotov.
It sometimes changes, sometimes not.
To Reproduce I don't know to reproduce, but I have debug logs of the last time it happened. See additional context.
Expected behavior The state should match the current state of the apple tv: displaying the currently playing episode OR paused/idle if it's not playing.
System Setup (please complete the following information):
Additional context
In the case described in the logs below, my roommate launched the TV around 21:00 yesterday night (2020-05-01) and was expecting a show. She first watched something else (Candice Renoir [...]) waiting for the other show to begin. Then she switched to the other show and this new show's info (Koh-Lanta [...]) are still on my media player card in HA now after a whole night (it's 07:31 now).
I just tried to launch another video in another app and nothing appeared in the logs + the state didn't change.
Here's the current state of the apple tv according to HA, while it's really off (idle).
It also happened yesterday morning, I was watching a Netflix show episode (let's call it A), when I switched to a completely other show (B), I still had infos from A in the media player card. Even after putting the Apple TV to sleep.
Here's my logging config (from the pyatv/HA integration repo):
And here are the logs:
Logs from 2020-01-05 21:00:00 to 2020-01-05 23:30:00