postlund
Fix (temporary?) for tvOS 18.4 for companion protocol disconnection
Fix for https://github.com/postlund/pyatv/issues/2656
If confirmed that Apple has blacklisted the hardcoded previous ID cafecafecafe it should be a definitive fix.
Sorry for the lack of response, I will look into this. I believe a random value is probably better than we have, but I want to investigate a bit further first. I believe _i is some kind of device ID and if it's important, then maybe a random one should be generated and saved among settings so it can be re-used for future connections.
No problem, we all have a life ! Yes it is certainly related to the device as it seems to be constant over time. I tried to look and convert some device ids in hexa but I didn't find anything close. But the more I think about it, more I believe that Apple blacklisted your static value, as any other values work. I don't understand why, what is the harm with this library ? this looks kinda mean from Apple policy if confirmed.
About storing the id in order to reuse it later, it means that it will be returned with pairing key at the end, and would be an optional parameter for connection (and if not provided generate a random one), something like that ?
No problem, we all have a life ! Yes it is certainly related to the device as it seems to be constant over time. I tried to look and convert some device ids in hexa but I didn't find anything close. But the more I think about it, more I believe that Apple blacklisted your static value, as any other values work. I don't understand why, what is the harm with this library ? this looks kinda mean from Apple policy if confirmed.
I have some leads, we'll see what I can dig up tomorrow. Hopefully something useful. Would be very strange if they black listed that. If you pick a very close ID, just changing like a single octet, that still works?
About storing the id in order to reuse it later, it means that it will be returned with pairing key at the end, and would be an optional parameter for connection (and if not provided generate a random one), something like that ?
I would put a new field in InfoSettings and store in as part of the storage model. Since it's a device identifier of some sort, other protocols could potentially need it so it makes sense to store it on "device level". Question is what to call it since we don't know what it is yet...
https://github.com/postlund/pyatv/blob/a6cb277e895c42f7d65d09abe9bf08aa5682e928/pyatv/settings.py#L76
Ok Yes if you submit cafecafecaf0 or anything close it works. Unless.... maybe having the same client (different clients actually but from atv point of view this is the same ) connecting with different pairing keys but same id cafe... make apple tv thinks that there would need some cleaning
@albaintor Yes, I do believe we should generate a unique identifier and re-use that. It seems to be device specific from what I can see. I'll draft something.