@bharper/atv-js 0.2.6 → 0.3.4

package/pyatv/docs/support/faq.md

@@ -0,0 +1,214 @@
+---
+layout: template
+title: FAQ
+permalink: /support/faq/
+link_group: support
+---
+# Table of Contents
+{:.no_toc}
+* TOC
+{:toc}
+
+# General Questions
+
+## My device is not found when scanning?
+
+See [Troubleshooting](../troubleshooting/) for some hints on locating the issue.
+
+## My Apple TV turns on every time I send a command with atvremote (it turns on my TV, receiver, etc). How do I disable that?
+
+You can't. The device will turn itself on whenever a request is made to it
+(and of course `atvremote` does that). It is how Apple has designed it. The only
+thing you can do is to disable CEC so that your other devices doesn't wake up too.
+That's about it.
+
+## Is it possible to "see" if a device is turned on before sending a command?
+
+"Yes". Since version 0.7.0 it is possible to see (when scanning) if a device
+is in deep sleep mode. A device can however be asleep (appear off) without being
+in deep sleep, so it's not fully reliable. This is still also considered an
+experimental feature.
+
+## Why is all or some metadata missing when I am playing some media on my device?
+
+Sometimes the Apple TV does not provide any metadata and in those cases there
+is no metadata available. Unfortunately, there is nothing that can be done about
+this. If you, however, can see for example a title or artwork in the
+*Remote app* on your iPhone or iPad, then something is likely wrong. In this
+case, you should write a bug report.
+
+## Streaming with AirPlay does not work. It says "This AirPlay connection requires iOS 7.1 or later, OS X 10.10 or later, or iTunes 11.2 or later." on the screen. What's wrong?
+
+The device authentication process has now been reversed engineered and implemented
+in pyatv. In order to get rid of this message, you must perform AirPlay pairing with
+the device and use the obtained credentials with playing media. See
+[pairing with atvremote](../..//documentation/atvremote).
+
+## When I scan, other devices like AirPlay speakers and iTunes libraries show up. Why is that?
+
+~~Apple has reused several protocols across different products. AirPlay is AirPlay and
+there's no practical difference if it's on a speaker or an Apple TV: it's the same
+thing. Because of this, they might show up in the scan results. In the future some
+devices might be filtered (like pure AirPlay devices, since you can't connect to them
+anyway), but for now they are there.~~
+
+This is no longer the case. From pyatv 0.5.0, pure AirPlay devices are no longer included in the scan result.
+
+## Is there a synchronous version of the library?
+
+No, the library is implemented with asyncio, introduced in python 3.4. A plain
+synchronous library is currently out of scope and not a priority.
+
+## Unicast scanning does not work if my device is on a different subnet (NonLocalSubnetError), why?
+
+To obtain the information pyatv needs to connect to a device, Zeroconf is used
+for "scanning". Zeroconf is designed to only work within the local network. If a
+request is received from a host on a different subnet it will be silently dropped. This
+is the reason why it is not possible to use unicast scanning between subnets and
+it's not possible to work around this.
+
+If you need to keep the network separation, you can still rely on regular scanning
+and configure an mDNS repeater (try "mdns repeater" on your favorite search engine).
+
+## It is really slow to send commands to the device with atvremote. It takes several seconds, is pyatv really this slow?
+
+From version 0.8.x, scanning for a particular device has been optimized. Normally a scan
+is performed for a specific time and filtering done after that. This has been changed
+so that scanning is aborted once the requested device has been found, making the discovery
+phase a lot shorter.
+
+The information below reflects all versions prior to 0.8.x (although everything except
+for bullet two applies to 0.8.x as well):
+
+It is a common misconception that pyatv is slow because atvremote takes its time.
+The fact is this: *every* time you run atvremote, this happens:
+
+1. pyatv and its dependencies are loaded into memory
+2. A scan is performed with a default timeout of three seconds
+3. A (TCP) connection is established to the device
+4. Authentication is performed and encryption enabled
+5. Command is executed
+6. Connection is torn down
+
+Once a connection has been established and authentication performed, issuing commands
+are more or less instant. But since atvremote exits after executing a command, everything
+must be done from the beginning again for the next command. This behavior is by definition
+slow.
+
+To get instantaneous feedback, the connection must remain active and commands sent by
+reusing the connection. This can be done in many ways, e.g. by implementing a daemon
+that maintains the connection in the background and receives commands via some interface
+(maybe REST). Currently, pyatv does not ship with such a tool since it's first and foremost
+a library. You will have to implement a solution that fits your needs.
+
+A small tip is to use unicast scanning to speed up the process (to at least make the situation
+better):
+
+```shell
+$ atvremote -s 10.0.0.3 stop
+```
+
+## I get an error about "ed25519 is not supported", how can I fix that?
+
+For cryptography, pyatv relies on the `cryptography` package. This package
+wraps crypto routines in OpenSSL, so if a given routine is missing then that
+crypto routine simply won't work.
+
+For MRP this means that you need to have decently new version of OpenSSL with
+support for ed25519 compiled in. Otherwise you get this error:
+
+```raw
+pyatv.exceptions.PairingError: ed25519 is not supported by this version of OpenSSL.
+```
+
+It is still a bit unclear which version of OpenSsl that added support for ed25519,
+so grab the latest one. Please refer to your operating system community on
+how to upgrade.
+
+## My Apple TV crashed/lost network connection/... and the connection in pyatv just hangs, why?
+
+To discover dangling connections, i.e. when the other device disappears without
+properly closing the connection, TCP keepalives are used. The support for this
+in python varies on different platforms. It might be the case that your operating
+system or version of python does not support TCP keep-alive properly, in which
+case this is a problem pyatv currently does not solve.
+
+A log point will indicate if configuration of keep-alive succeeded:
+
+```raw
+2020-06-10 22:31:28 INFO: Configured keep-alive on <asyncio.TransportSocket fd=8, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=6, laddr=('10.0.10.254', 60849), raddr=('10.0.10.81', 49153)> (Linux)
+```
+
+Or a warning if not supported:
+
+```raw
+2020-06-10 22:32:28 WARNING: Keep-alive not supported: System does not support keep-alive
+```
+
+Most versions of macOS and Linux should work with no problems. For Windows, you need at
+least Windows 10 build 1709.
+
+pyatv.
+
+# When using pyatv on a Raspberry pi, e.g running atvremote, I get "Illegal instruction". How do I fix that?
+
+It seems like the wheels (prebuilt binaries) for miniaudio does not work properly. You can fix this
+by manually uninstalling miniaudio and building it from source:
+
+```shell
+pip uninstall miniaudio
+pip install --no-binary :all: miniaudio
+```
+
+You might have to install some additional system packages (like a C-compiler) for this.
+
+Reported in this issue: {% include issue no="1249" %}
+
+# Known Issues
+
+Some apps behave in unexpected ways that are out of control of this library (including general things in tvOS), i.e. nothing can be done in pyatv to circumvent these behaviors. This sections lists the known ones. If you are experiencing issues with an app, feel free to add it here (write an issue, make a PR or just press *Edit this page* at the bottom of this page).
+
+## Idle state during previews
+
+The deveice generally moves to {% include api i="const.DeviceState.Idle" %} when playing trailers or "what's next"
+sequences. For now, there's no known solution to circumvent this. This might change in the
+future, so a solution should be re-evaluate every now and then.
+
+Reported in these issues: {% include issue no="994" %}
+
+## Power state is not updated when using external speaker (e.g. HomePod)
+
+The power state is derived from the number of connected output devices (as there seems to be no
+"real" power state). This however fails when using an external spekar for audio, e.g. a HomePod,
+as the connection seems to remain active even when putting the Apple TV to sleep. So it is not
+possible to detect if a device is sleeping or nog in these cases. No solution or workaround is
+known so far.
+
+Reported in these issues: {% include issue no="958" %}
+
+## Netflix (com.netflix.Netflix)
+
+* Previews in the main menu yields play status updates (usually with what was played most recently,
+  not content of the preview). A workaround is to disable these previews, see
+  [this](https://help.netflix.com/sv/node/2102) page.
+* During episode intros and "next episode" screens the device goes to idle state.
+
+## com.cellcom.cellcomtvappleos
+
+Does not seem to report any state. This app likely implements its own media player, bypassing
+the metadata management used by MRP meaning that no information is available when this app is used.
+
+Link to app in App Store: https://apps.apple.com/il/app/%D7%A1%D7%9C%D7%A7%D7%95%D7%9D-tv/id1159313682
+
+Reported in these issues: {% include issue no="1160" %}
+
+## playbackRate issue
+
+Some apps incorrectly set the metadata item "playbackRate" as 0.0 instead of 1.0 which causes
+pyatv to report the media as paused at all times. A workaround for this issue has been pushed at
+{% include issue no="673" %}, seeking, fast-forwarding or rewinding will still return a "paused" state.
+
+Apps known to cause this issue are listed below
+
+* Amazon Prime Video (com.amazon.aiv.AIVApp)
+* BBC iPlayer (uk.co.bbc.iplayer)

package/pyatv/docs/support/migration.md

@@ -0,0 +1,138 @@
+---
+layout: template
+title: Migration
+permalink: /support/migration/
+link_group: support
+---
+# Table of Contents
+{:.no_toc}
+* TOC
+{:toc}
+
+# Migration
+
+This page contains details on how to migrate between different versions
+of pyatv. Beware that these guides are written according to "best effort"
+and might be incomplete or missing some details. If you find something
+to be unclear, please help out by writing an issue or creating a pull
+request
+
+# From 0.9.0-0.9.7
+
+## General Changes
+
+* Each service now has {% include api i="interface.BaseService.enabled" %}, indicating if pyatv
+  should connect to the service or not. Generally this is of little importance, but it must be
+  verified before initiaing pairing. Pairing should never be initiated for disabled services.
+
+## Deprecations
+
+None
+
+# From 0.8.2-0.9.0
+
+## General Changes
+
+* To restore support with tvOS 15, make sure to provide AirPlay credentials. Credentials obtained with earlier versions of pyatv are incompatible (pair again).
+* The `password` property previously present in `conf.RaopService` is now part of `interface.BaseService` instead.
+* Make sure to verify {% include api i="interface.BaseService.pairing" %} before calling {% include api i="pyatv.pair" %} (in case new credentials are needed).
+* Check {% include api i="interface.BaseService.requires_password" %} if a password needs to be provided
+* At least version 3.17.3 of {% include pypi package="protobuf" %} is now required.
+* {% include pypi package="mediafile" %} replaced {% include pypi package="audio-metadata" %} as a dependency
+
+## Deprecations
+
+* Service specific configurations, e.g. {% include api i="conf.MrpService" %}, have been replaced by {% include api i="conf.ManualService" %}. Scheduled for removal in 1.0.0.
+* {% include api i="interface.RemoteControl.volume_up" %} and {% include api i="interface.RemoteControl.volume_down" %} are now replaced by {% include api i="interface.Audio.volume_up" %} and {% include api i="interface.Audio.volume_up" %}. Scheduled for removal in 1.0.0.
+
+# From 0.7.1-... to 0.8.0
+
+## General Changes
+
+* The push updater interface is now considered a feature and availability
+  (via {% include api i="interface.Features.get_feature" %} and
+  {% include api i="const.FeatureName.PushUpdates" %}) should now be performed
+  before using it.
+* {% include pypi package="audio-metadata" %}, {% include pypi package="bitarray" %}
+  and {% include pypi package="miniaudio" %} are new dependencies in this
+  release (used by RAOP).
+* At least version 3.14 of {% include pypi package="protobuf" %} is now required.
+
+## Deprecations
+
+* Passing `protocol` to {% include api i="pyatv.connect" %} is no longer
+  needed and its value will be ignored. Scheduled for removal in version 1.0.0.
+
+# From 0.7.0 to 0.7.1
+
+## General Changes
+
+* Unicast scanning (i.e. passing `hosts` to {% include api i="pyatv.scan" %}) will
+  not verify if hosts are on the same network anymore (`NonLocalSubnetError` will
+  not be thrown). Requests will just time out. See {% include issue no="775" %}
+  for more details.
+
+## Deprecations
+
+* `NonLocalSubnetError` is never thrown and shall not be checked for. It
+  will be removed in 0.9.0.
+
+# From 0.6.0 to 0.7.0
+
+## General Changes
+
+* No library changes
+* MRP arguments to atvproxy has been simplified (only credentials and IP to
+  Apple TV must now be provided)
+
+## Deprecations
+
+* None
+
+# From 0.5.0 to 0.6.0
+
+## General Changes
+
+  * {% include api i="interface.AppleTV.close" %} has been changed to a
+    regular function instead of a coroutine.
+  * All listeners are now stored as weak references
+
+# From 0.4.0 to 0.5.0
+
+## General Changes
+
+* None
+
+## Deprecations
+
+* Python 3.6 or later is now required
+* `suspend` and `wakeup` in {% include api i="interface.RemoteControl" %}
+  have been deprecated. Use {% include api i="interface.Power.turn_on" %}
+  and {% include api i="interface.Power.turn_off" %} instead.
+* {% include api i="helpers.auto_connect" %} is now a coroutine. The
+  [example](https://github.com/postlund/pyatv/blob/master/examples/auto_connect.py)
+  has been updated.
+
+# From 0.3.x to 0.4.0
+
+## General Changes
+
+* Device configuration has moved from `AppleTVDevice` to {% include api i="conf.AppleTV" %}
+* `pyatv.connect_to_apple_tv` has been renamed to {% include api i="pyatv.connect" %}
+* `pyatv.scan_for_apple_tvs` has been renamed to {% include api i="pyatv.scan" %}
+* Pairing has been made generic and is done via {% include api i="pyatv.pair" %}
+* Constants, e.g. media type, has been changed into enums
+* `play_state` has been renamed to `device_state`
+* AirPlay interface has been renamed from `AppleTV.airplay` to
+  {% include api i="interface.AppleTV.stream" %}
+
+## Deprecations
+
+* Arguments `abort_on_found` and `only_home_sharing` have been removed from
+  {% include api i="pyatv.scan" %}
+* The `Metadata.artwork_url` method has been deprecated and has no
+  replacement
+* All methods in the AirPlay interface has been deprecated in favor
+  of the generic pairing interface (except for `play_url`)
+* `pyatv.pair_with_apple_tv` has been replaced by {% include api i="pyatv.pair" %}
+  which can pair all protocols

package/pyatv/docs/support/scanning_issues.md

@@ -0,0 +1,110 @@
+---
+layout: template
+title: Scanning Issues
+permalink: /support/scanning_issues/
+link_group: support
+---
+# Table of Contents
+{:.no_toc}
+* TOC
+{:toc}
+
+# Scanning Issues
+
+Scanning for devices relies on the [Zeroconf](https://en.m.wikipedia.org/wiki/Zero-configuration_networking)
+technology stack. Simplified (and technically) it means that zeroconf devices acts
+as DNS servers and listens to requests on a specific multicast address (also using
+port 5353 instead of regular 53). When someone wants to find devices supporting a
+particular service, it sends a DNS request to the multicast address (on port 5353)
+and await response from other devices. This is an *extremely* simplified view of
+what is going on.
+
+There are a number of sources of errors to consider:
+
+* Firewalls or routers block multicast traffic
+* Timing issues: responses not received in time
+* Responses filtered by kernel (or somewhere else), not received in application
+
+The latter two seems to be most common. Lets break them down.
+
+# Timing issues
+
+Timing issues can happen because pyatv only scans for a small period of time. By
+saying "scan", we actually mean sending out requests and waiting for responses. The
+wait time should be long enough to receive all responses but short enough to not be
+annoying to the user. Waiting five minutes for a scan to finish *is* annoying. By
+default, pyatv scans for 3 seconds (with `atvremote`).
+
+Not receiving responses within the time frame obviously is problematic. To make the
+matter even more complex: pyatv relies upon several services. One for `MRP`,
+one for AirPlay and so on. They are requested *independently* of each other. This
+means that it is possible to get a response for AirPlay but miss `MRP` because of
+timing issues (or other issues as well). You might see this happen sometimes when
+scanning, that one or more service is missing. This is the reason why that happens.
+
+# Response filtering
+
+A behavior that has been observed is that the response is indeed received by the host
+(as seen with Wireshark), but it is never forwarded to the python process so `zeroconf`
+never receives it. Some filtering happens at some point for some reason. It is still
+unclear if this is a bug in python or not and should be investigated further.
+
+# Working around issues
+
+Issues with scanning has always plauged pyatv and it still does. To mitigate the
+problems, support for "unicast scanning" has been added. It is meant as a compliment
+to regular scanning, as it cannot replace that.
+
+Unicast scanning (which is an expression used here, it is not a commonly accepted term)
+works in the same way as regular multicast but the request is sent to specific hosts instead.
+You basically say: "scan *these* IP-addresses". This seems to work more relibly and it also
+comes with some other advantages:
+
+* It is fast because we know exactly which answers to wait for
+* All services can be obtained with *one* request, so no timing issues
+* All data pyatv requires, like unique identifiers, are present so it is more reliable than manual configuration
+
+Support for unicast scanning has been added via the `--scan-hosts` flag in `atvremote`.
+
+# Troubleshooting further
+
+If pyatv doesn't find your devices, you can try other Zeroconf tools to see if it is
+a general issue or not.
+
+For Linux:
+
+    $ avahi-browse --all
+
+For macOS:
+
+    $ dns-sd -B _appletv-v2._tcp.
+    OR
+    $ dns-sd -G -B _touch-able._tcp.
+    OR
+    $ dns-sd -G -B _mediaremotetv._tcp.
+
+If you get an error such as "command not found", you do do not have avahi
+installed. You will have to consult your distributions support channels
+(e.g. forum) for help on this.
+
+Here are some other possible sources of problems:
+
+- Bonjour/Zeroconf requires you to be on the same network as the devices
+  you are looking for. This means that you cannot scan for devices from
+  inside of a container or virtual machine, unless they are using a bridged
+  network interface.
+- If you are running a Mac or using an iPhone, try enabling AirPlay mirroring
+  or use the Remote app. Unless you can get that to work, it is highly
+  unlikely that pyatv will work either.
+- If you can see your Apple TV on your iPhone, you can try to install an app
+  suitable for Bonjour discovery. Just search for *bonjour* in the App store
+  (there might be alternatives for Android as well) and lool for your device.
+  If it's not found then pyatv will likely not fins it either.
+- Firewalls might block the necessary traffic for Bonjour. Make sure the
+  traffic is allowed or disable it when scanning.
+- We have seen that switching the Apple TV from WiFi to cable solves the problem
+  in some cases. It is recommended that you try it out.
+
+If you continue having problems scanning for devices, consider writing a
+[support issue](https://github.com/postlund/pyatv/issues/new?assignees=&labels=question&template=question-or-idea.md&title=).
+Remember to include debug logs (`--debug` if you are using `atvremote`).

package/pyatv/docs/support/support.md

@@ -0,0 +1,18 @@
+---
+layout: template
+title: Support
+permalink: /support/
+link_group: support
+---
+# :fire: Support
+
+If you are having problems or questions, this section aims to help you.
+Check out the subpages above.
+
+In case you have found a potential bug or need help, please write issues on GitHub:
+
+**:bug: [I have found a bug](https://github.com/postlund/pyatv/issues/new?assignees=&labels=bug&template=bug_report.md&title=)**
+
+**:raised_hands: [I need help](https://github.com/postlund/pyatv/issues/new?assignees=&labels=question&template=question-or-idea.md&title=)**
+
+**:question: [Something is missing...](https://github.com/postlund/pyatv/issues/new?assignees=&labels=feature&template=feature_request.md&title=)**

package/pyatv/docs/support/troubleshooting.md

@@ -0,0 +1,83 @@
+---
+layout: template
+title: Troubleshooting
+permalink: /support/troubleshooting/
+link_group: support
+---
+# Table of Contents
+{:.no_toc}
+* TOC
+{:toc}
+
+# Scanning does not find any devices
+
+Please see [this](../scanning_issues/) page on scanning issues.
+
+# No PIN code is displayed when I try to pair with AirPlay
+
+First check that you've got Apple TV assigned to a "room" in the correct HomeKit
+home. Go to Settings, Airplay and Homekit, and make sure that "Room" has a valid
+value assigned. Then retry pairing.
+
+If no screen is displayed with the PIN code, try navigating to the AirPlay
+settings menu on your Apple TV. The code should be visible there.
+
+# The exception "pyatv.exceptions.DeviceAuthenticationError: pair start failed" is thrown when I try to pair with AirPlay
+
+Make sure you have *Allow Access* set to *Anyone on the Same Network* for
+AirPlay on your Apple TV. For details, see issue {% include issue no="377" %}.
+
+# How do I get additional logs that I can attach when creating an issue?
+
+You can pass `--debug` to `atvremote` to get extensive debug logs. For more details, see
+the [atvremote](../../documentation/atvremote) page.
+
+# I do not receive updates in my listeners, e.g. when media state changes
+
+From version 0.6.0 of pyatv, *weak references* are kept to all listeners. This means that if a listener
+is not "reachable" from outside of pyatv, it will be garbage collected the next time the garbage
+collector runs. A typical situation when this would happen looks like this:
+
+```python
+class DummyPushListener:
+    @staticmethod
+    def playstatus_update(updater, playstatus):
+        pass
+
+    @staticmethod
+    def playstatus_error(updater, exception):
+        pass
+
+self.atv.push_updater.listener = DummyPushListener()
+self.atv.push_updater.start()
+```
+
+In this case, no one else has a reference to the instance of `DummyPushListener` (other than pyatv), so
+it will be freed when the garbage collector runs (which can be at any given time). Changing the code into
+this would work better:
+
+
+```python
+listener = DummyPushListener()
+self.atv.push_updater.listener = listener
+self.atv.push_updater.start()
+```
+
+Here a local reference is kept to the listener. Beware that the same issue will arise when `listener`
+goes out of scope, so make sure all your listeners live at least as long as they are used in pyatv.
+
+# Pairing requirement is listed as "disabled", what does that mean?
+<a name="pairing-disabled"></a>
+
+This either means that the service is turned off or an access restriction is in place
+that does not allow pyatv to pair (pyatv probably does not support this method of pairing). To solve this,
+you need to go to your device and change access settings to "Allow everyone on the same network".
+How this is done depends on device, here a few links to check out depending on device:
+
+* [Apple TV](https://support.apple.com/guide/tv/stream-audio-and-video-with-airplay-atvbf2be9ef7/tvos) -
+  Expand *Set who can use AirPlay to stream content to Apple TV* and pick *Anyone on the Same Network*
+* [HomePod](https://support.apple.com/guide/ipad/share-controls-with-others-ipad76474c82/ipados) -
+  Follow instructions under *Allow others to access your AirPlay 2-enabled speakers and TVs*, pick
+  *Anyone on the same network*
+* [macOS](https://support.apple.com/guide/mac-help/set-up-your-mac-to-be-an-airplay-receiver-mchleee00ec8/mac) -
+  Follow instructions and pick *Anyone on the Same Network*

package/pyatv/pyatv/protocols/mrp/protobuf/AudioFadeMessage.proto

@@ -0,0 +1,13 @@
+syntax = "proto2";
+
+import "pyatv/protocols/mrp/protobuf/ProtocolMessage.proto";
+import "pyatv/protocols/mrp/protobuf/PlayerPath.proto";
+
+extend ProtocolMessage {
+  optional AudioFadeMessage audioFadeMessage = 88;
+}
+
+message AudioFadeMessage {
+  optional PlayerPath playerPath = 1;
+  optional int32 fadeType = 2;
+}

package/pyatv/pyatv/protocols/mrp/protobuf/AudioFadeMessage_pb2.pyi

@@ -0,0 +1,37 @@
+"""
+@generated by mypy-protobuf.  Do not edit manually!
+isort:skip_file
+"""
+
+import builtins
+import google.protobuf.descriptor
+import google.protobuf.internal.extension_dict
+import google.protobuf.message
+import pyatv.protocols.mrp.protobuf.PlayerPath_pb2
+import pyatv.protocols.mrp.protobuf.ProtocolMessage_pb2
+import typing
+
+DESCRIPTOR: google.protobuf.descriptor.FileDescriptor
+
+@typing.final
+class AudioFadeMessage(google.protobuf.message.Message):
+    DESCRIPTOR: google.protobuf.descriptor.Descriptor
+
+    PLAYERPATH_FIELD_NUMBER: builtins.int
+    FADETYPE_FIELD_NUMBER: builtins.int
+    fadeType: builtins.int
+    @property
+    def playerPath(self) -> pyatv.protocols.mrp.protobuf.PlayerPath_pb2.PlayerPath: ...
+    def __init__(
+        self,
+        *,
+        playerPath: pyatv.protocols.mrp.protobuf.PlayerPath_pb2.PlayerPath | None = ...,
+        fadeType: builtins.int | None = ...,
+    ) -> None: ...
+    def HasField(self, field_name: typing.Literal["fadeType", b"fadeType", "playerPath", b"playerPath"]) -> builtins.bool: ...
+    def ClearField(self, field_name: typing.Literal["fadeType", b"fadeType", "playerPath", b"playerPath"]) -> None: ...
+
+global___AudioFadeMessage = AudioFadeMessage
+
+AUDIOFADEMESSAGE_FIELD_NUMBER: builtins.int
+audioFadeMessage: google.protobuf.internal.extension_dict._ExtensionFieldDescriptor[pyatv.protocols.mrp.protobuf.ProtocolMessage_pb2.ProtocolMessage, global___AudioFadeMessage]

package/pyatv/pyatv/protocols/mrp/protobuf/AudioFadeResponseMessage.proto

@@ -0,0 +1,11 @@
+syntax = "proto2";
+
+import "pyatv/protocols/mrp/protobuf/ProtocolMessage.proto";
+
+extend ProtocolMessage {
+  optional AudioFadeResponseMessage audioFadeResponseMessage = 89;
+}
+
+message AudioFadeResponseMessage {
+  optional int64 fadeDuration = 1;
+}

package/pyatv/pyatv/protocols/mrp/protobuf/AudioFadeResponseMessage_pb2.pyi

@@ -0,0 +1,32 @@
+"""
+@generated by mypy-protobuf.  Do not edit manually!
+isort:skip_file
+"""
+
+import builtins
+import google.protobuf.descriptor
+import google.protobuf.internal.extension_dict
+import google.protobuf.message
+import pyatv.protocols.mrp.protobuf.ProtocolMessage_pb2
+import typing
+
+DESCRIPTOR: google.protobuf.descriptor.FileDescriptor
+
+@typing.final
+class AudioFadeResponseMessage(google.protobuf.message.Message):
+    DESCRIPTOR: google.protobuf.descriptor.Descriptor
+
+    FADEDURATION_FIELD_NUMBER: builtins.int
+    fadeDuration: builtins.int
+    def __init__(
+        self,
+        *,
+        fadeDuration: builtins.int | None = ...,
+    ) -> None: ...
+    def HasField(self, field_name: typing.Literal["fadeDuration", b"fadeDuration"]) -> builtins.bool: ...
+    def ClearField(self, field_name: typing.Literal["fadeDuration", b"fadeDuration"]) -> None: ...
+
+global___AudioFadeResponseMessage = AudioFadeResponseMessage
+
+AUDIOFADERESPONSEMESSAGE_FIELD_NUMBER: builtins.int
+audioFadeResponseMessage: google.protobuf.internal.extension_dict._ExtensionFieldDescriptor[pyatv.protocols.mrp.protobuf.ProtocolMessage_pb2.ProtocolMessage, global___AudioFadeResponseMessage]

package/pyatv/pyatv/protocols/mrp/protobuf/AudioFormatSettingsMessage.proto

@@ -0,0 +1,5 @@
+syntax = "proto2";
+
+message AudioFormatSettings {
+  optional bytes formatSettingsPlistData = 1;
+}