Timing out? can not resolve ocotopi.local error

What is the problem?
If a certain amount of time has passed it seems like, the connection between the Raspi4 and PRUSA slicer or the network is dropped. When I go to send the Gcode to the printer it pops up with an error that reads "ERROR UPLOADING TO PRINT HOST:COULDNT RESOLVE HOST NAME:COULD NOT RESOLVE HOST:OCTOPI.LOCAL ( ERROR 6)
But once I reboot the computer and the RaspPi4, works fine, once.Then the exact same thing happens on the next print if I haven't recently rebooted.
I will attach system spec info for PRUSA and Octoprint
ANy input would be appreciated, this is frustrating to say the least.


What did you already try to solve it?
Assigned Static IP to RaspPi4: no change

Logs (syslog, dmesg, ... no logs, no support) I will include system info

Additional information about your network (Hardware you are trying to connect to, hardware you are trying to connect from, router, access point, used operating systems, ...)
Linksys Router
WIFI is set to Airtime fairness which mix's frequency on the network
Windows 10 pro 64bit
Firefox Web Browser

Have you tried to use the IP address rather than octopi.local? Sometimes Windows can struggle with hostname resolution.

within PRUSA slicer? No I have not. I didn't know that was an option.

Octopi.local is distributed over the network by the Bonjour protocol, which is apple. If nothing is running the bonjour protocol, after the arp queries stop to a device, octopi.local no longer has any definition, and fails. Where prusa asks for hostname, put in the IP address

Bonjour is also known as mDNS multicast name resolution, originally developed by Apple, its how Airprint works. Implemented on Linux systems under the name Avahi, https://avahi.org If networks don't have a proper DNS configuration - and most don't unless the router properly implements something like dnsmasq, then mDNS is the best alternative, it works, most of the time

I appreciate all the replies. I did get to the bottom of what was going on. So my network SSID had the same name for all 3 broadcast. The router was set to "Airtime" fairness and was conflicting when it would drop one connection for a better connection. So far so good. Self sabotage is always hard to deal with. lol
Thanks.

I've encountered the same issue with SuperSlicer, but I've found that if I just resend the same file it will send and start printing as it should.
I only found that out by going into the printer settings and 'testing' the printer connection and once it told me the printer is connected. Then I'd resend the print and it would work fine. Then I just circumvented the 'test' and resent the job and it works.

So somewhere, I believe in octopi or octoprint they are losing that handshake.