I get to cast.wait() and then get Failed to connect

[stefan52a]

>> import time
>> import pychromecast

>> chromecasts = pychromecast.get_chromecasts()
>> [cc.device.friendly_name for cc in chromecasts]
['Kantoor']

>> cast = next(cc for cc in chromecasts if cc.device.friendly_name == "Kantoor")
>> # Start worker thread and wait for cast device to be ready
>> cast.wait()

then get

Casting to: Kantoor
 
[record[a,in-unique,7c5d0363-398a-f3e9-f9be-3c12598063fa.local.]=120/119,10.57.4.8:8009] Failed to connect, retrying in 5.0s

What is wrong? Tried same pc and chromecast (which is a google nest hub BTW) in the same WiFi. Note: I use LAN range 10.57.4.x

[kcowgill]

Same; trying to connect to a Google Home on the same subnet.

$ python
Python 3.6.5 |Anaconda, Inc.| (default, Apr 26 2018, 08:42:37)
[GCC 4.2.1 Compatible Clang 4.0.1 (tags/RELEASE_401/final)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> import pychromecast
>>> chromecasts = pychromecast.get_chromecasts()
>>> [cc.device.friendly_name for cc in chromecasts]
['Upstairs Speaker', 'Basement Speaker', 'Living Room Home']
>>> cast = next(cc for cc in chromecasts if cc.device.friendly_name == "Living Room Home")
>>> cast.wait()
[record[a,in-unique,b6c5b718-6b2d-8767-c8dc-a7263f0ce36f.local.]=120/119,192.168.1.79:8009] Failed to connect, retrying in 5.0s

[kcowgill]

After some poking I'm thinking there's something up with discovery/get_chromecasts()...

$ python
Python 3.6.5 |Anaconda, Inc.| (default, Apr 26 2018, 08:42:37)
[GCC 4.2.1 Compatible Clang 4.0.1 (tags/RELEASE_401/final)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pychromecast
>>> cast = pychromecast.Chromecast('192.168.1.79')
>>> cast.wait()
>>> cast.status
CastStatus(is_active_input=False, is_stand_by=True, volume_level=0.4545454680919647, volume_muted=False, app_id=None, display_name=None, namespaces=[], session_id=None, transport_id=None, status_text='', icon_url=None)

... and now the code I've been working with can cast to my Google Home.

[stefan52a]

Confirmed working this way.

[guirem]

Hi,

It happens because of latest release of zeroconf dependency (version 0.24.4 released on 30th of December). Any other version of 0.24.X will work.

As a workaround, you can force installation of previous zeroconf version pip3 install zeroconf==0.24.3

[kcowgill]

Confirming zeroconf==0.24.3 lets the example code work.

[highwingers]

wow, spent 2 days banging my head why casting stopped. downgrading zeroconf fixed the issue for now.

[bronikowski]

pip3 install zeroconf==0.24.3

I was going back in stack trying to find what broke catt on my laptop and you've just saved me two layers of libraries to go through. Much love.

[fondberg]

There is a change in zeroconf which for some reason causes the host to be a record instead of an actual host (ipaddress or hostname).

[jstasiak]

There is a change in zeroconf which for some reason causes the host to be a record instead of an actual host (ipaddress or hostname).

The only patch between zeroconf 0.24.3 and 0.24.4 that may be connected to this is in the following commit: https://github.com/jstasiak/python-zeroconf/commit/8ccad54dab4a0ab7f573996f6fc0c2f2bad7eafe. If I'm right there's code somewhere in pychromecast that depends on DNSAddress.__repr__ returning a string representation of the IP address inside the record. I suggest accessing the address field of the record and converting to string.

BTW I'm moderately convinced DNSAddress is for internal use and if you're getting an instance of it you may be accessing some private API, but that's another story.

[fondberg]

@jstasiak I believe the code that gets the entry is https://github.com/balloob/pychromecast/blob/master/pychromecast/discovery.py#L70 which gets a DNSRecord. Is the method in DNSCache called entries_with_name which returns DNSRecord private or public?

[jstasiak]

I think the Zeroconf.cache attribute in general is private, but then again it's totally undocumented what's actually public so... :)

The API used by zeroconf examples (browser.py and registration.py) is safe to use, everything else is in limbo, I think we should (and will) document this in the near future.

[JonasVautherin]

I'm not completely clear on the state of this issue. Is it fixed by #337?

[JonasVautherin]

It seems to me that it is fixed, and could therefore be closed.

[fondberg]

Yes this can be closed