So there was a change to the zeroconf discovery in 1.5.0. HOWEVER, that only affects how OctoPrint announces itself for its own service identifier octoprint._tcp.local, and I don't see how that could influence the OS level avahi hostname announcement done on OctoPi (this octopi.local stuff is not a feature of OctoPrint but rather the OctoPi image).
I just tested it by letting my two update test Pis ping each other via their .local names. octopia running OctoPrint 1.5.0, OctoPi 0.17.0. octopib running OctoPrint 1.5.0, OctoPi 0.18.0rc1.
pi@octopiA:~ $ ping octopib.local
PING octopib.local (192.168.1.153) 56(84) bytes of data.
64 bytes from octopib.lan (192.168.1.153): icmp_seq=1 ttl=64 time=38.8 ms
64 bytes from octopib.lan (192.168.1.153): icmp_seq=2 ttl=64 time=23.8 ms
64 bytes from octopib.lan (192.168.1.153): icmp_seq=3 ttl=64 time=10.6 ms
64 bytes from octopib.lan (192.168.1.153): icmp_seq=4 ttl=64 time=74.7 ms
^C
--- octopib.local ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 9ms
rtt min/avg/max/mdev = 10.551/36.948/74.683/23.961 ms
pi@octopiB:~ $ ping octopia.local
PING octopia.local (192.168.1.184) 56(84) bytes of data.
64 bytes from octopia.lan (192.168.1.184): icmp_seq=1 ttl=64 time=21.1 ms
64 bytes from octopia.lan (192.168.1.184): icmp_seq=2 ttl=64 time=18.0 ms
^C
--- octopia.local ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 3ms
rtt min/avg/max/mdev = 18.002/19.569/21.136/1.567 ms
An additional check against the published services (not hostname but actually the things that OctoPrint itself controls and configured responses for) also shows nothing that hints at loopback addresses being reported by 1.5.0:
$ python tools/zeroconf_browser.py --fetch
Press enter to exit...
ADDED: OctoPrint instance "Ender 3 Pro"._octoprint._tcp.local.
SRV: ender3pro.local.:80
TXT: b'\x06path=/\rversion=1.5.0\x07api=0.1)uuid=ffa23bac-ec2a-4fb9-8242-20d6c92d1a7a'
Info:
Address: 192.168.1.57:80
ServiceInfo(type='_octoprint._tcp.local.', name='OctoPrint instance "Ender 3 Pro"._octoprint._tcp.local.', addresses=[b'\xc0\xa8\x019'], port=80, weight=0, priority=0, server='ender3pro.local.', properties={b'path': b'/', b'version': b'1.5.0', b'api': b'0.1', b'uuid': b'ffa23bac-ec2a-4fb9-8242-20d6c92d1a7a'})
ADDED: OctoPrint instance "Prusa MK3"._octoprint._tcp.local.
SRV: prusamk3.local.:80
TXT: b'\x06path=/\x07api=0.1)uuid=bb16bdd7-7864-4d53-8a3f-61ccdcd9f9c7\rversion=1.5.0'
Info:
Address: 192.168.1.56:80
ServiceInfo(type='_octoprint._tcp.local.', name='OctoPrint instance "Prusa MK3"._octoprint._tcp.local.', addresses=[b'\xc0\xa8\x018'], port=80, weight=0, priority=0, server='prusamk3.local.', properties={b'path': b'/', b'api': b'0.1', b'uuid': b'bb16bdd7-7864-4d53-8a3f-61ccdcd9f9c7', b'version': b'1.5.0'})
ADDED: OctoPrint instance on octopiA._octoprint._tcp.local.
SRV: octopiA.local.:80
TXT: b'\x06path=/\x07api=0.1)uuid=a697ab59-f163-4ba5-afe9-b1ce1f9bce6b\rversion=1.5.0'
Info:
Address: 192.168.1.184:80
ServiceInfo(type='_octoprint._tcp.local.', name='OctoPrint instance on octopiA._octoprint._tcp.local.', addresses=[b'\xc0\xa8\x01\xb8'], port=80, weight=0, priority=0, server='octopiA.local.', properties={b'path': b'/', b'api': b'0.1', b'uuid': b'a697ab59-f163-4ba5-afe9-b1ce1f9bce6b', b'version': b'1.5.0'})
ADDED: OctoPrint instance on octopiB._octoprint._tcp.local.
SRV: octopiB.local.:80
TXT: b'\x06path=/\rversion=1.5.0\x07api=0.1)uuid=e55eb8e6-92b0-42f3-ae28-ad0f188aa509'
Info:
Address: 192.168.1.153:80
ServiceInfo(type='_octoprint._tcp.local.', name='OctoPrint instance on octopiB._octoprint._tcp.local.', addresses=[b'\xc0\xa8\x01\x99'], port=80, weight=0, priority=0, server='octopiB.local.', properties={b'path': b'/', b'version': b'1.5.0', b'api': b'0.1', b'uuid': b'e55eb8e6-92b0-42f3-ae28-ad0f188aa509'})
Currently a bit at a loss of what is happening here for some of you.
It would be helpful to know though from which client operating system you are trying to resolve. Also, @Spybyte, please share your log as well. @audryhome your initial log excerpt actually does indicate there are some weird network issues (zeroconf tries to register the octoprint service, but can't reach the LAN at all), though I do not understand how that can be the case when connection via IP works just fine. Your second log does appear to be from another machine? At least I can't find the exception in that one. But your instance can't connect to the internet (though that should not interfere with name resolution, it could hint at network problems). Any infos you could give on your network setup?
