I have not included any logs, as I don't really need help at this stage, this is to report a curious anomaly.
Having had a failed print due to the filament snapping at the feeder I tried to see what was happening through Octoprint. That was a fail with a timeout occurring, which is not the first time I have had dropout of Octoprint connection.
However on this occasion, on a whim, I then decided to try connecting with the Cura connection with Octoprint. Immediate success.
I then went back to the browser to try connecting to Octoprint, which I have done many times in the past, again Octoprint fails to connect but strangely enough the Cura connection is still there.
P.S. After a number of retries Octoprint did connect, but it does not make sense that Cura connection is rock solid and browser connection is dodgy.
Ya, this can be frustrating... Especially since it starts to work eventually. There are so many possible good reasons this could be happening. I have a complex network setup and I have run into a lot of things that cause just what you are seeing. Mind you all of them could be explained with a bit of work and a good network monitor.
Here are a few things to help you think about what might be happening on your machine/network.
Are you using the IP or a FQDNS when accessing OP? Using the IP can eliminate a lot of the things that could cause this issue. Not all of them though.. and its just not as nice so I am not advocating going that path but I would say that if you are Using FQDNS, you might want to compare the results with the direct IP when you see these issues.
Are you using the same (IP/FQDNS) for both?
Are you trying to use Cura and your browser from the same machine?
Was your browser already working and Cura had to be started or vs versa? Both the browser and Cura will have different DNS caching strategies.
Do you connect to anything like a VPN from this same client machine?
If so were you connected at the time? Were you connected at some point where the browser was open and was still open when you found that you could not connect? I ask about he VPN because this can cause some application to route to a different DNS Service or even a different routing assignment all together. Then you have a split brain as far as DNS goes. Some apps may have a cache DNS from before the VPN connection was made.
If your VPN setups a low level Proxy in the route, some apps might natively use a proxy for HTTP Traffic others will completely ignore one if not explicitly assigned in the app.
What is the source of your DNS responses if you are using FQDNS? Is it a firewall or a router or something else. Could there be more than one source of truth on your network? Failover or competing services. If you think there might be and your client machine is using DHCP, that could cause some routing differences and name lookup inconsistencies.
I use Win10 and directly access via the IP address. Whenever I use Octoprint I use a dedicated Firefox profile just for anything 3D.
As far as Cura is concerned I have no idea how it connects. I just set it up to access the RaspberryPi.
Cura was already running given it had a failed print, which I had cancelled, then closed Cura down to inspect and fix the printer filament break.
Once I had that sorted, I tried to connect via the IP with a dedicated Firefox profile and as stated before the connection failed, I then restarted Cura and connected to Octoprint through Cura straight away. Then returned to the dedicated FF profile to connect to the Pi which again failed. Multiple retries with a decent lapse of time between retries and it eventually connected.
I have no idea about network protocols or how Cura connects other than the initial steps in doing so.
Cura uses the OctoPrint API, which access the pi via the same URL you would in firefox with some additional paths at the end of the URL. That's why it's odd that one would work and not the other.
interestingly enough the word logs becomes a link here in the forum, so if you click on it you can find out how to get the logs. but to make it a little easier for you ~/oprint/bin/octoprint systeminfo . (make sure to include the . at the end).
Yes interesting, if only I could connect, to get to download those.
Somewhat remiss, placing those files on a server that cannot be reached.
However from what I have read on the forums, this could just be a simple matter of corrupted files.
I did have a power dropout for a few minutes which could be the issue.
I thought you said in last message that you could ssh in. You can use a tool like filezilla ftp client or winscp to connect and transfer files to your local Windows machine.
I use PuTTY for ssh which asked for user name and password , which looked like it had connected, but given the command sequences typed in from the page that said that the server was not running, failed to do anything, then I assumed that there must be corruption of files in the O.S.
I tried to burn Octopi to the SD card but I got a failure notification.. After a reformat then reloading Octopi the system booted up with the exception that the camera no longer works.
Still no wiser, but ordered new micro SD card so will try again when that comes.
At the moment I have a serial cable linked and using Cura for test printing