Protocols and IDs
What do you need help with?
Using ‘atvremote scan’ returns the info for each ATV and most do not list MRP as a protocol, which is as I expected since Apple are apparently removing it. However, another ATV also on 15.5 still reports MRP as an available protocol. How can the same version of TVOS vary in this way? Does this have any impact on how pyatv works?
Also, most report their MAC address as an identifier, but not all. Why would there be this discrepancy?
Being able to reliably use the MAC address to target commands would be ideal as I have that already stored elsewhere. But if it will not work for all ATVs, that’s not a usable mechanism.
Anyone suggest reasons for the above puzzling inconsistencies?
There seems to be no correlation between the ATV hardware and support (or not) of MRP.
However, the ATVs that report:-
tvOS 15.5.1
do NOT offer MRP. Whereas those that report:-
tvOS 15.5.1 build 19L580
DO still offer MRP.
So several aspects of that I do not understand.
- Why do some builds of tvOS not report their build number?
- Why does tvOS 15.5.1 build 19L580 still offer MRP?
- How can 2 identical ATV4K 6,2 with 64GB, have different builds of tvOS installed.
Since I only just updated one of the other ATVs, from 15.3 and ended up with "tvOS 15.5.1 build 19L580", that must be the latest. Is it possible that dropping MRP was a mistake and it is now being reintroduced?
The reason for MRP being announced by some devices and not others is something only Apple can answer, I guess. The service disappeared and re-appeared several times in the tvOS 15 betas, but the final call is that it has been deprecated and won't come back. I believe some people saw the service on their devices, performed a factory reset and then it disappeared. But as I said, Apple is likely the only one with answers and my educated guess is that if the service is announced, then it's a bug.
Technically MRP has not really gone anywhere. The exact same protocol is still used, but tunneled over AirPlay instead. So you cannot use it as a stand-alone protocol like before. I think this solution was introduced around iOS/tvOS 12-13, so it had been around (and used by Control Center) for a while before Apple decided to remove MRP.
As for pyatv, all of this doesn't matter much nowadays as pyatv supports MRP both in stand-alone mode (in case you have a device with pre-tvOS 15 laying around) but also tunneled over AirPlay. If the MRP service is found, pyatv will mark it as "disabled" (you will see this in the scan result) and not use it. But only for devices running tvOS 15 or later. Generally you should just pair all enabled protocols that pyatv discovers (that is possible and requires to pair) and refrain from hand-picking certain protocols. That makes life easier. I have however not been very clear in my documentation regarding how this is supposed to be done and I will try to clarify that over time. My current focus is persistent storage, which will allow storing credentials (and passwords) on disk. I will also create a new tool that guides a user through pairing of all protocols to simplify the process.
Regarding identifiers: they should be treated as opaques. Some protocols use MAC as identifies, but you cannot always trust that. The correct way would be to scan for all identifiers, but that is cumbersome right now. When persistent storage is in place, then I can generate an identifier to use that internally maps to all the unique identifiers belonging to a device.
Thanks Pierre, looks like pyatv will be getting even better. Any ideas on timescale, for persistent storage etc? Just some idea as if e.g. this is due to appear next week, I will delay looking further into it until then, next month possibly the same, but next year would mean I’ll get stuck in now. So a rough idea would be most helpful.
Sent from my iPad
On 18 Jul 2022, at 19:01, Pierre Ståhl @.***> wrote:
The reason for MRP being announced by some devices and not others is something only Apple can answer, I guess. The service disappeared and re-appeared several times in the tvOS 15 betas, but the final call is that it has been deprecated and won't come back. I believe some people saw the service on their devices, performed a factory reset and then it disappeared. But as I said, Apple is likely the only one with answers and my educated guess is that if the service is announced, then it's a bug.
Technically MRP has not really gone anywhere. The exact same protocol is still used, but tunneled over AirPlay instead. So you cannot use it as a stand-alone protocol like before. I think this solution was introduced around iOS/tvOS 12-13, so it had been around (and used by Control Center) for a while before Apple decided to remove MRP.
As for pyatv, all of this doesn't matter much nowadays as pyatv supports MRP both in stand-alone mode (in case you have a device with pre-tvOS 15 laying around) but also tunneled over AirPlay. If the MRP service is found, pyatv will mark it as "disabled" (you will see this in the scan result) and not use it. But only for devices running tvOS 15 or later. Generally you should just pair all enabled protocols that pyatv discovers (that is possible and requires to pair) and refrain from hand-picking certain protocols. That makes life easier. I have however not been very clear in my documentation regarding how this is supposed to be done and I will try to clarify that over time. My current focus is persistent storage, which will allow storing credentials (and passwords) on disk. I will also create a new tool that guides a user through pairing of all protocols to simplify the process.
Regarding identifiers: they should be treated as opaques. Some protocols use MAC as identifies, but you cannot always trust that. The correct way would be to scan for all identifiers, but that is cumbersome right now. When persistent storage is in place, then I can generate an identifier to use that internally maps to all the unique identifiers belonging to a device.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.
I can't make any promises, but a month or two is more likely then next year at least.
That's great. Thanks for the estimate, it helps me to plan.
Ken G i l l e t t
////////
On 19 Jul 2022, at 13:55, Pierre Ståhl @.***> wrote:
I can't make any promises, but a month or two is more likely then next year at least.
— Reply to this email directly, view it on GitHub https://github.com/postlund/pyatv/issues/1799#issuecomment-1189018507, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGOFPTXBTQSBF2TW3V6T4ETVU2QUHANCNFSM533TYF6Q. You are receiving this because you authored the thread.
Sure thing! 👍
Persistent storage kinda slipped into the future, but I think I will get on it soon as I see great potential in it. I however think the issue here is resolved to the degree it can be.