Pyatv: [tvOS12] Home Sharing disabled and manual pairing changes

Created on 14 Oct 2018  ·  20Comments  ·  Source: postlund/pyatv

Hiya,

I enabled Home Sharing on my Apple TV running tvOS12. However, using the 'atvremote scan' command returns:

# atvremote scan --debug
DEBUG: Discovering devices for 3 seconds
DEBUG: Auto-discovered service LivingRoom TV at 10.0.2.2. (no home sharing)
Found Apple TVs:
 - LivingRoom TV at 10.0.2.2 (home sharing disabled)

Home Sharing does work when attempting to access files on my Macbook. Both devices are on the same Network with no firewall blocking requests. Did something change with the tvOS12 update?

It seems that the procedures to manually 'pair'. the device have also changed. The Apple TV no longer shows a popup after executing:

atrvremote pair

Instead, you will have to navigate to the General Settings -> Remotes and Devices -> Remote-app and Devices and select the pyatv to allow API calls.

All 20 comments

Hey!

I don't think it has changed, I just scanned on my network and the device seems to show up just fine. Zeroconf seems to work very unreliable at times though, so maybe the service didn't show up as expected. Maybe you can run another zeroconf/bonjour/mdns browser on another device and see if it shows up? You have some instructions here:

https://pyatv.readthedocs.io/en/master/troubleshooting.html

Pairing manually seems broken, I believe Apple changed the algorithm used for verification. I might have to add a way to disable this check until the algorithm is reversed engineered again.

Pairing has always required that you navigate to "Remote-app and Devices", that's how the DMAP-implementation works. You will get the PIN-number on screen when using MRP however, which is default on the master branch. Based on the output above you are using the stable recommended version (e.g. via pip) and this is expected behavior.

I see the same behaviour as @d3vzer0 with homesharing, though I am using the 12.1 beta. I did not try to manually pair it.

@postlund when you tested with tvOS 12, had you ever been connected/paired to it before? If so could that be why it works for you, but not us?

A bunch of us over at Home Assistant having the same issue here

This issue still puzzles me - I have no idea what is going on. But I made it possible to bypass pin verification in 0.3.11, so you can use any PIN code when pairing. Just run atvremote -p non pair and it should work. Maybe you can try that instead of using home sharing?

The issue has somewhat changed for me after home sharing was disabled and re-enabled. I'm now seeing a timeout. If I try to curl http://<appletv>:3689/login?hsgid=<hsgid>&hasFP=1 it seems to connect but not get any answer from the apple tv. Stack trace from atvremote follows.

# atvremote --login_id <hsgid> --address <apple tv ip> --debug -v playing
DEBUG: GET URL: http://<apple tv ip>:3689/login?hsgid=<hsgid>&hasFP=1
/usr/local/lib/python3.5/dist-packages/pyatv/internal/apple_tv.py:509: RuntimeWarning: coroutine 'ClientSession.close' was never awaited
  self._session.close()
Traceback (most recent call last):
  File "/usr/local/lib/python3.5/dist-packages/pyatv/__main__.py", line 420, in _run_application
    return (yield from cli_handler(loop))
  File "/usr/local/lib/python3.5/dist-packages/pyatv/__main__.py", line 257, in cli_handler
    return (yield from _handle_commands(args, loop))
  File "/usr/local/lib/python3.5/dist-packages/pyatv/__main__.py", line 331, in _handle_commands
    ret = yield from _handle_device_command(args, cmd, atv, loop)
  File "/usr/local/lib/python3.5/dist-packages/pyatv/__main__.py", line 362, in _handle_device_command
    atv.metadata, cmd, True, *cmd_args))
  File "/usr/local/lib/python3.5/dist-packages/pyatv/__main__.py", line 385, in _exec_command
    value = yield from tmp(*args)
  File "/usr/local/lib/python3.5/dist-packages/pyatv/internal/apple_tv.py", line 321, in playing
    playstatus = yield from self.apple_tv.playstatus()
  File "/usr/local/lib/python3.5/dist-packages/pyatv/internal/apple_tv.py", line 55, in playstatus
    resp = yield from self.daap.get(cmd_url, timeout=timeout)
  File "/usr/local/lib/python3.5/dist-packages/pyatv/daap.py", line 65, in get
    yield from self._assure_logged_in()
  File "/usr/local/lib/python3.5/dist-packages/pyatv/daap.py", line 127, in _assure_logged_in
    yield from self.login()
  File "/usr/local/lib/python3.5/dist-packages/pyatv/daap.py", line 51, in login
    resp = yield from self._do(_login_request, is_login=True)
  File "/usr/local/lib/python3.5/dist-packages/pyatv/daap.py", line 89, in _do
    resp, status = yield from action()
  File "/usr/local/lib/python3.5/dist-packages/pyatv/net.py", line 39, in get_data
    raise ex
  File "/usr/local/lib/python3.5/dist-packages/pyatv/net.py", line 30, in get_data
    timeout=DEFAULT_TIMEOUT if timeout is None else timeout)
  File "/usr/local/lib/python3.5/dist-packages/aiohttp/client.py", line 391, in _request
    await resp.start(conn)
  File "/usr/local/lib/python3.5/dist-packages/aiohttp/client_reqrep.py", line 770, in start
    self._continue = None
  File "/usr/local/lib/python3.5/dist-packages/aiohttp/helpers.py", line 673, in __exit__
    raise asyncio.TimeoutError from None
concurrent.futures._base.TimeoutError

>>> An error occurred, full stack trace above
ERROR: Unclosed client session
client_session: <aiohttp.client.ClientSession object at 0xb5d5e7b0>

tvOS 12.1.1 seems to have broken it, it will still discover devices, but throws the timeout issues like @mhalden described.

@geekofweek I will upgrade now and see if it's the same thing for me.

I have 4 I've confirmed it on, was going to try and do some more digging in what changed tonight. Be nice if they posted a change log for tvOS.

I see the same behavior, which is "good". I'm gonna investigate.

I found the issue! Apparently they filter the user agent now, so a client must send a proper user agent string. Changing it to Remote/1021 makes it work again. Both for Home Sharing and when pairing manually.

Give me a sec and I will make a PR with the changes needed.

@geekofweek Please check out #167 and let me know if it works.

@postlund that seem to do the trick. quick work of that one. My gut was telling me they changed something like that. Nice one.

@geekofweek Great, thanks for trying it out so quick! Since I've made a few bug fixes recently I'll try to get a new release out tomorrow that can be bumped to Home Assistant as well. Should probably make some people happy.

I’m having trouble keeping up - I just updated to 12.1.1 and my push updater is out. Still paired though!

Which branch is the “right one”? 0.3.x still?

Edit: ran the install for release 0.3.x and I appear to be back in business. I’m always impressed when things are fixed before I even get home from work to update.

Do we need to manually pair now? I still get home sharing disabled with atvremote scan?

I did a manual pair using -p none and got a new login_id but it doesn't work with HA. This new login_id is 0x2ABB6AFA16461579, does this look right? It is complete different length and style as the old one.

Edit...
Must be right since this works atvremote --address 10.0.0.21 --login_id 0x2ABB6AFA16461579 playing.

Edit 2...
Went to turn off home sharing and enable again... ONLY to find is disabled. Enabled it and good to go. Thanks.

The home sharing issue is still not really solved, but manually pairing should work. The login id you get had the form you mention, so it is correct.

worth mentioning if you are dropping the login id into HASS, use quotes since python will interpret the 0x2ABB6AFA16461579 as a number and not a string.

Still getting weird things happening. No Apple TV in HA again and decided to investigate.

My Apple TV home sharing is on in settings, but off according to atvremote scan.

Tried to turning home sharing off and on again to see if that corrects issue, nope.

Edit - I just noticed that I had my Apple TV setup under HA media_player, which it is supposed to be under base configuration according to the docs (not sure when that changed). Changed my config and it is working.

@bigkraig You are absolutely right, many people hava fallen into that pit. Good to mention.

@glassbase It moved form being a pure media player to its own platform in version 0.49, so a while back. If you have any other issues with home sharing, give manual pairing a go. Should work better.

I see no reason to keep this issue open any longer. Post a new issue in case of problems.

Was this page helpful?
0 / 5 - 0 ratings