You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Short feature/function description
There are some issues and quirks in pyatv (especially on master) that I am not very fond of. Since 0.4.x will be a breaking upgrade, I will take full liberty of changing whatever I want to make the library more clean and easy to use.
To my best ability, I will try to make notes of changes here as they happen. Most important is to not trust the documentation as it is utterly out-of-date.
What needs to be done? Changes that will be made but are not finished yet:
None
Changes that are on master:
The scanning API will change to be much simpler. The abort_on_found flag will be removed and replaced with something else later. Scans will thus always take a specific amount of time. (Use unique identifiers from zeroconf #223)
Connecting will revolve more around scanning and make manual connections more of a special-case. You are supposed to scan for devices before connecting. This simplifies API usage but also introduce issues sometimes when a device is not found (which will have to be dealt with). Making it like this is required for MRP but also for the unique identifiers to work. (Use unique identifiers from zeroconf #223)
Moving to a more scan-centric solution also means that autodiscover will be default in atvremote. So no need to specify -a anymore. Use -m or --manual to get old behavior. (Use unique identifiers from zeroconf #223)
Rename a few base functions to be less verbose. I'd rather have pyatv.scan instead of pyatv.scan_for_apple_tvs. (Cleanup and renaming #228)
The concept of "usable service" is also not something I'm very fond of. I will investigate if I can remove it somehow. (Cleanup and renaming #228)
Credentials to AirPlay are now loaded via service instead of its custom API (old API is still there). But all credentials are now specified via --XXX-credentials to atvremote where XXX is one of dmap, mrp or airplay. (Load AirPlay credentials via service #244)
How credentials are configured (or a service in general, really) will be made more "generic". It works more or less how I want it with DMAP and MRP. But AirPlay has its own special little API. My intention is that AirPlay credentials are loaded and saved in the service as well. (Tidy up AirPlay credentials #227)
Pairing and connecting is a bit of chicken-and-egg problem now. You "connect" with pyatv.connect (which doesn't make any connection, thus is misleading) in order to get to the paring handler. This gives all sorts of problems. I intend to add a new method for pairing, pyatv.pair and break out pairing code to that method. Credentials will be passed back via the config (it will fill in the credentials in the service). (Break out pairing interface and implement for AirPlay #240)
Will not be done/postponed
I currently mix-and-match the use of "service" and "protocol". This should probably be consolidated into either one of them to make it less messy.
Is this a breaking change?
Yes
Anything else worth knowing?
Not all changes might be on master, I add things as I go along.
The text was updated successfully, but these errors were encountered:
Identifiers are collected from the different services that the device expose. You can freely pick one of them, doesn't matter which. Then just run commands like this:
$ atvremote -i AA:BB:CC:DD:EE:FF playing
Media type: Unknown
Play state: Paused
Note that the old -a for autodiscover has been deprecated and is now default behavior. Specify -m for manual mode (previous default mode).
Short feature/function description
There are some issues and quirks in
pyatv
(especially onmaster
) that I am not very fond of. Since 0.4.x will be a breaking upgrade, I will take full liberty of changing whatever I want to make the library more clean and easy to use.To my best ability, I will try to make notes of changes here as they happen. Most important is to not trust the documentation as it is utterly out-of-date.
What needs to be done?
Changes that will be made but are not finished yet:
Changes that are on
master
:The scanning API will change to be much simpler. The
abort_on_found
flag will be removed and replaced with something else later. Scans will thus always take a specific amount of time. (Use unique identifiers from zeroconf #223)Connecting will revolve more around scanning and make manual connections more of a special-case. You are supposed to scan for devices before connecting. This simplifies API usage but also introduce issues sometimes when a device is not found (which will have to be dealt with). Making it like this is required for MRP but also for the unique identifiers to work. (Use unique identifiers from zeroconf #223)
Moving to a more scan-centric solution also means that
autodiscover
will be default inatvremote
. So no need to specify-a
anymore. Use-m
or--manual
to get old behavior. (Use unique identifiers from zeroconf #223)Deprecate artwork_url (Deprecate artwork_url #202)
Rename a few base functions to be less verbose. I'd rather have
pyatv.scan
instead ofpyatv.scan_for_apple_tvs
. (Cleanup and renaming #228)The concept of "usable service" is also not something I'm very fond of. I will investigate if I can remove it somehow. (Cleanup and renaming #228)
Credentials to AirPlay are now loaded via service instead of its custom API (old API is still there). But all credentials are now specified via
--XXX-credentials
toatvremote
where XXX is one ofdmap
,mrp
orairplay
. (Load AirPlay credentials via service #244)How credentials are configured (or a service in general, really) will be made more "generic". It works more or less how I want it with DMAP and MRP. But AirPlay has its own special little API. My intention is that AirPlay credentials are loaded and saved in the service as well. (Tidy up AirPlay credentials #227)
Pairing and connecting is a bit of chicken-and-egg problem now. You "connect" with
pyatv.connect
(which doesn't make any connection, thus is misleading) in order to get to the paring handler. This gives all sorts of problems. I intend to add a new method for pairing,pyatv.pair
and break out pairing code to that method. Credentials will be passed back via the config (it will fill in the credentials in the service). (Break out pairing interface and implement for AirPlay #240)Will not be done/postponed
Is this a breaking change?
Yes
Anything else worth knowing?
Not all changes might be on
master
, I add things as I go along.The text was updated successfully, but these errors were encountered: