I have a new Pi 3 Model B, with a clean image install of OctoPi 0.15.1 (I only updated the wifi connection info). When I turn on the pi, with only the wifi connection, I can ping/SSH/browse using the bonjour linked octopi.local. However, after about 2 minutes, it stops working. If I reset the wifi connection (either by rebooting the pi or the wifi), the name resolution works again for a couple minutes.
I've tried this from a couple different Windows 10 machines on the same network, all with the Bonjour Print Services for Windows v2.0.2 installed. I've tried redownloading and reflashing the image. Initially after turning on the pi, when I ping octopi.local, I get responses from an IPv6 address. After a couple minutes when I ping octopi.local, I get no responses (only Request timed out) from 198.105.244.228 (I'm assuming this is the bonjour error IP address?).
Everything appears to work fine if I connect via IPv4 address or if I use an Ethernet connection, but both options are rather annoying. Any ideas?
I've given up using Octopi.local via Bonjour. I installed Bonjour on my PC and Samba on the RPi in order to create a "watched folder" on the RPi where I could drop my gcode files from my Windows desktop. This worked OK initially but, like you, the folder and name kept disappearing in Windows Explorer. I now only use the nailed IP address and don't use the watched folder at all preferring to export my files direct to OctPrint from within Cura. I'm connected via Ethernet so it's not a wireless issue.
Obviously the name may have changes from octopi to octopi???.
I tried to connect mine via octopi.local too, but no result.
With the IOS App "Net Analyzer" I've got another name for the IP the RasPi resides.
Now the name here is octopimk2mm.local. Obviously due to give OctoPrint server another name (MK2MM).
My router and Fing gave me the name with an underscore in it. You may have to leave it.
You can get the hostname via SSH too. Just enter "hostname". You also may get the name with the underscore there.
Lies and blasphemy. Windows will use the entries it sees in the hosts file. Try a ping octopi. and/or a ping octopi.local, noting the periods I just included. Try an nslookup octopi. (again, with the period). If that works but http://octopi.local doesn't, then fix the network adapter settings which are trying to suffix your own domain name to the end of octopi, as in octopi.mymsdomain.com or similar.
For you, I'd also suggest going to your router and dedicating an IP address to your octopi server.
It seems that I was wrong to suggest that octopi.local had stopped working and that adding it to hosts file failed to solve the problem. It seems that I named it Octopi, or it named itself and I was not using the upper case "O". In my defence, being new to Linux and being a Windows user I had forgotten that Unix/Linux is case sensitive.
I have "nailed" the IP address so that's why I'm OK using the IP address rather than the name. I have another issue now but have raised a new post in the hope it can be solved.
NETBIOS names don't include dotted extensions and sometimes Windows will work in the hybrid mode. It will try to do name resolution in one space (NETBIOS) and then fail over into another service (DNS). Also, all NETBIOS names are ALLCAPS, for what it's worth. Browsers and name resolution client will usually attempt to deal with this.
In the TCP/IP world of name resolution, sometimes it will just work out to use simply "octopi" and especially "octopi." with a period at the end. The second version indicates "don't add any default suffixes like ".com" or "myowndomain.com".
Thanks everyone for your replies! However, none of these actually help to solve my issue.
I agree that the root issue is that, on initialization, you don't know the IP address or MAC address for a headerless Pi. But, this is really a different question, and has been fairly well answered elsewhere (@OutsourcedGuru's name-resolution guide is probably the best and most complete I've found). So, there is really one specific question I'm asking: why did the bonjour based name resolution stop working after a couple minutes? Everything had been configured correctly (including my custom hostname), otherwise it wouldn't work at all.
As an aside, what I ended up doing was setting a static IP from my router (based on MAC address), and have found other, non bonjour based, workarounds for name resolution.
If you'd been on OSX, then I'm sure this would have worked just fine.
Since this is Windows, Bonjour really isn't a native name resolution service "out of the box", so to speak. Some people install Bonjour (or iTunes) to get this functionality in Windows. There are fringe cases where this isn't optimal; sometimes a network HP printer, for example, might fail to install if Bonjour is present.
That said, you ask why this worked for a few minutes and then stopped. My best guess would be that you do a ping octopi.local and this—in the first half second—turned up nothing since it wasn't in your DNS cache. Windows then looked in your arp cache (nothing). It then did a DNS lookup (nothing). And then, before giving up completely ping decided to do a network broadcast and found it by its MAC address and then updated its arp cache and its local DNS cache, I'd guess.
The next time it's working, do an arp -a and look for your Raspberry Pi by MAC address. You can get your Raspberry Pi's wi-fi MAC address by remoting into it and doing an ifconfig wlan0|grep ether|awk '{print $2}'. And the next time it's not working, do that arp -a again; it's likely that it won't be there.
Another thought could be that your router is "short-leasing" its IP addresses. Remote into the Raspberry and do a cat /var/log/syslog|grep "wlan0: leased".
May 11 16:17:12 charming-pascal dhcpcd[641]:
wlan0: leased 192.168.1.250 for 86400 seconds
That's 24 hours, as seen in seconds. So it's possible that you turned on the printer "Day 1" and on "Day 2" (24 hours plus 1 minute later), the router is issuing a new IP address to the printer. Your DNS/arp caches are stale and it's failing to connect.
Windows will use the entries it sees in the 
It seems that I was wrong to suggest that octopi.local had stopped working and that adding it to hosts file failed to solve the problem. It seems that I named it Octopi, or it named itself and I was not using the upper case "O". In my defence, being new to Linux and being a Windows user I had forgotten that Unix/Linux is case sensitive.