Left the OctoPrint page open.
The page to stay responsive.
Version: 1.3.0.post0.dev0+g7f5d03d (master branch)
Wanhao Duplicator i3 v2.1, Repetier 0.9
Safari, 10.0.2 on macOS Sierra, 9.x on iPad iOS 9.
Nothing unusual, just Repetier doing its Recv: wait thing
Safari console, corresponding 404 for the sourcemaps when opening the console half an hour after the page was loaded and become unresponsive meanwhile, the rest in it is "normal":
I have read the FAQ.
Infos from IRC:
Potentially related to #1523 ?
Possibly yes, the only thing apart from the System menu and some local UI elements that became responsive was the Disconnect button in the Connnection accordion, and hitting Connect after that kicked it up. This was after several reloads of no socket activity, at which point I'd normally have restarted OctoPrint to get it going.
While the OctoPrint window on the Mac had started showing just 0°C / 0°C after reloads, the page on the iPad still read some ambient room temperature from the printer, but nothing there was any more responsive than on the Mac.
If the disconnect button works, it's not the communication with the backend that's the problem. Based on you saying that you "couldn't send commands" on IRC, I assume now that the problem rather lies with the communication to your printer breaking but the communication between OctoPrint's front-end and backend still working just fine?
I'm utterly confused now what the actual issue is you are experiencing. Please describe exactly, with as much detail as possible, what works, what doesn't, and what exactly makes it work again. I for one am currently completely in the unclear on what you are actually looking at ;)
If you want, a screencast on YouTube showing the problem would also be very helpful here I think.
Well, when nothing in the main view responds, seems like ui-only features are active and there's no indication of responsiveness and there are no errors, and you don't want to start a new print on a potentially unstable system, what can you conclude?
what can you conclude
what can you conclude
Actually, you shouldn't conclude anything but simply describe exactly what you are seeing, as detailed and descriptive as possible ("Becomes unresponsive." is pretty non-descriptive and can mean a multitude of things), especially if you don't know how stuff fits together :)
That prevents misunderstandings on both sides as we had here - I honestly thought you were looking at network communication issues based on your descriptions here and on IRC. And preventing misunderstandings in turn saves valuable time otherwise lost on useless back-and-forth while trying to understand and ideally solve an issue (be it through a bug fix or a configuration change).
@bolsoncerrado that's what I thought too, but after some more details @jammi actually appears to be running into issues where his printer stops responding to commands sent via serial, with the web frontend itself staying completely responsive.
I later got UI hangs as well, where the printer was responsive and traffic was otherwise ongoing, but UI buttons wouldn't pass on, like terminal command line entry not being sent or cleared, control tab things not doing anything and so forth. The incident while opening this issue could've overlapped with such an event. Left-hand side panel worked, the right-hand side panels didn't. Disconnect-Connect didn't resolve, no number of reloads of the browser window on either device would work either. Restarting octoprint in this case was the only way to restore functionality. So basically I got the same thing I've got earlier many times, but probably not related to printer comms like the one 10 days ago.