pyatv: Help me squash bugs before 0.9.0 is released

What’s on your mind?

So, I’m getting very close to release v0.9.0 of pyatv, containing lots of updates. Especially under the hood. The biggest update is however the “MRP-over-AirPlay”-support, that is required to work with tvOS 15. Adding support for that also made it possible to support the HomePod with very little effort, so it is now possible to do that as well.

It would be really great to get some help testing things before shipping to iron out the last quirks (as I’m sure there are quite a few…). What mainly needs testing is tvOS 15 support and the HomePod, as mentioned. But general usage is also welcomed (other protocols, streaming, etc.) as a lot of improvements have been made that changes the general way pyatv works.

The HomePod does not require particular pairing or such, it should just work now. For instance to see what is playing:

$ atvremote -s 10.0.10.84 playing
  Media type: Unknown
Device state: Playing
       Title: Unpaid Intern
      Artist: Bo Burnham
       Album: Inside (The Songs)
    Position: 5/34s (14.7%)
      Repeat: Off
     Shuffle: Off

The Apple TV requires credentials however, so you need to pair with it first (atvremote -s <ip> --protocol airplay pair) and pass them via --airplay-credentials (atvremote -s <ip> --airplay-credentials <creds> playing). Only AirPlay credentials are really needed to test tvOS 15 support. Credentials obtained with previous versions of pyatv will not work, so you need to re-pair for this one.

This will work with tvOS 14 as well, but it’s tricky to know if MRP tunneled over AirPlay or if regular MRP is used. An easy way is to look for this line in the --debug log:

2021-09-09 06:18:36 DEBUG [pyatv.protocols.airplay.remote_control]: Setting up remote control connection to 10.0.10.84:7000

It’s also possible to limit to just testing AirPlay by specifying --scan-protocols:

$ atvrremote -s <ip> --scan-protocols airplay --airplay-credentials <creds> playing

One last thing: there are pre-built docker images now. So it’s possible to test pyatv without having to install anything other than Docker. Version 0.9.0 will be the first proper “container release”, but all commits to the master branch are automatically pushed as new images. It’s as easy as this to run from master:

$ docker run  --rm --network=host ghcr.io/postlund/pyatv:master atvremote scan

I will be so thankful for all the help I can get here, to thank you!

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 63 (30 by maintainers)

Commits related to this issue

Most upvoted comments

Your support for this software is outstanding. Ready to go when 15 was released!

Again, thanks!

@bcmitri That is expected as the integration now supports everything pyatv supports, including (basic) AirPlay support. Nice for TTS for instance.

I have pushed the first version of the integration to:

https://github.com/postlund/hass-atv-beta

Available via HACS soon. Be sure to read the instructions before upgrading!

I just reset the ATV and now the MRP service is gone and everything’s working as expected. The thing is that this ATV actually did the consumer upgrade. So it went from 14.7 to the stable release of 15.0 without any betas. So this might happen to more people…

Timing ^^

Yes, that is definitely it. The same thing seems to be reported in #1322, so we can continue there.

@Qonstrukt Maybe a case of “did you try turning it off and on again”? 😉 Can’t think of any changes I’ve made related to this, more likely a hiccup with tvOS. Seem to happen every now and then. Regarding name… that’s not anything I have even thought about. I know that it did work at some point as I have seen “pyatv” there. Will have to look into that. Thanks for mentioning it!

@mschwartz Sure! It will work with both tvOS 14 and 15. As mentioned before: make sure to (re-)pair AirPlay and provide those credentials for tvOS 15. For tvOS 14 there’s no difference from before.

That sounds like a potential bug in the play state management. You should definitely try to reproduce with atvremote ... push_updates. If you see the same behavior, add --debug, pipe the output to a file and send it to me. Hopefully I can see what’s going on. Finding these things are what this issue is all about 😊

Oh, yeah, right, now I understand. Legacy-wise I required that either DMAP or MAP was paired to consider everything OK. That is no longer necessary as pyatv is a log more generic now, so I need to remove that check.

Guess I will have a busy upcoming week then 😉 Thanks for the heads up!