Boy, that was an excellent suggestion. Unfortunately no luck. I put in an exception for the address and reloaded the page, but no luck. I also went over to Edge (where I don't have an ad blocker) and that threw the error as well.
Try again by running OctoPrint in Safe Mode and then share the octoprint.log from this session.
Thanks, greatly appreciate the help. I'm on the octopi server using winscp, but can't for the life of me find where octoprint is actually installed, hence, can't find the octoprint log files.
From within WinSCP, no variation of: ~/.octoprint/logs appears to generate a valid directory location.
This is probably something really simple, but it is escaping me.
Thanks
Found it. home/pi/.octoprint and that got me to the logs.
Right now the printer is helping support printing Prusa face shields for Covid-19. I'm looking at the log file, but haven't had a chance to restart the server in safe mode.
here is what I see when trying to log in from my PC:
2020-03-29 06:38:19,894 - octoprint.server.util.flask - INFO - Passively logging in user 3DMaster from ::ffff:10.0.0.28
2020-03-29 06:38:19,903 - octoprint.access.users - INFO - Cleaning up user session 320071E51FD24FCCB2D99A537508DE3D for user _api
2020-03-29 06:38:19,911 - octoprint.access.users - INFO - Logged out user: _api
2020-03-29 06:38:19,914 - octoprint.access.users - INFO - Cleaning up user session 73B6916859DA4090AD017C2093140352 for user 3DMaster
2020-03-29 06:38:19,919 - octoprint.access.users - INFO - Logged out user: 3DMaster
2020-03-29 06:38:19,923 - octoprint.access.users - INFO - Cleaning up user session 7C4E175BD5E14A6B9C73BD0FB4E4C7FC for user _api
2020-03-29 06:38:19,953 - octoprint.access.users - INFO - Logged out user: _api
2020-03-29 06:38:19,956 - octoprint.access.users - INFO - Cleaning up user session 47114A8EBA6548ED92A3D1B7619AC167 for user _api
2020-03-29 06:38:19,958 - octoprint.access.users - INFO - Logged out user: _api
2020-03-29 06:38:19,965 - octoprint.access.users - INFO - Logged in user: 3DMaster
2020-03-29 06:38:21,640 - octoprint.plugins.Octoslack - ERROR - Slack RTM message processing error: coercing to Unicode: need string or buffer, NoneType found
2020-03-29 06:38:27,367 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:10.0.0.28
2020-03-29 06:38:28,021 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:10.0.0.28
2020-03-29 06:38:28,614 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:10.0.0.28
2020-03-29 06:38:29,220 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:10.0.0.28
2020-03-29 06:38:29,829 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:10.0.0.28
2020-03-29 06:38:30,522 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:10.0.0.28
2020-03-29 06:38:31,124 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:10.0.0.28
2020-03-29 06:38:31,701 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:10.0.0.28
2020-03-29 06:38:32,399 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:10.0.0.28
2020-03-29 06:38:38,775 - octoprint.server.util.sockjs - INFO - Client connection closed: ::ffff:10.0.0.28
2020-03-29 06:38:40,742 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:10.0.0.28
2020-03-29 06:38:41,536 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:10.0.0.28
2020-03-29 06:38:47,760 - octoprint.server.util.sockjs - INFO - Client connection closed: ::ffff:10.0.0.28
Looks like It's using IPV6 which Android and Linux fully support. Windows has issues with IPV6. may want to add ipv6.disable=1 to the cmdline.txt file in /boot and see what happens
Thanks. Been trying to do that, but not sure what sudo command to use, and chmod 777 to get to cmdline.txt is failing due to permissions.
In a case like this, I might put the microSD into an adapter and then plug it into my MacBook. I'd then jump to a terminal and... sudo nano /Volumes/boot/cmdline.txt to edit it directly, then Eject and boot the Pi like that.
But in your case, you'd need to use PuTTY to get a session to the Pi, then sudo nano /boot/cmdline.txt.
Excellent! Thank you. worked like a charm! Now I just need to let this current print complete and then I'll try a reboot.
Thanks again.
Well this is really strange or should I say sporadic. I deactivated IPV6 for the one Octopi instance and rebooted. At that point, the instance was not accessible at all, regardless of platform. Went back in and munged up the undo to the point I just had to recreate the original cmdline.txt by hand (couldn't upload a new one due to permissions). After that and a reboot, the instance is now available and I'm using it. The other instance seems to be working as well (I had a working browsers session for that one that I had been trying to protect, but wound up needing to reopen it and it seems to be working as well). As I get some free time, I'll try to see if there is a pattern.
And of course, no sooner do I hit reply, and go back to Octopi Instance #1 in the browser, and I'm back to the original error. Arrghh.
Do your instances have unique hostnames assigned? You should consider this a requirement.
The instances are uniquely named in Octoprint, but for access, I just use the IP address. During Octopi setup, They are also given unique names.
It smells like a browser-caching or a DHCP-leasing issue almost. You might try issuing static IP addresses to both in your router.
Sorry for the delay. It is definitely inconsistent. Octopi Instance 1 is currently inaccessible, but it has always had a DHCP reservation. Octopi Instance 2 is currently accessible, did not originally have a DHCP reservation, but I did add one a day or so ago.
I have no idea what the underlying issue is. I'm trying to get Instance 1 to restart in safe mode but haven't had the time to dig deep, and when I try to run the cmd to set safe mode, it says something to the effect "bash: octoprint: command not found". My linux-fu is lacking.
I'm in the /home/pi/oprint/bin directory and see the octoprint file
If you haven't changed the hostname on one of the RPi images, they are both trying to identify themselves as "octopi" which will certainly confuse any DHCP server running on the your network.
From a command line on one of the RPi's run "sudo raspi-config" and under the Network Options, change the hostname to "octopi1". If you can get to the other one, change the hostname to "octopi2". This frees the hostname "octopi" for use when you buy that third printer 
The system running your DHCP server will probably need to be rebooted. If you can configure your DHCP server, then removing any old reservations for these two RPi systems might be useful. Its likely that the system with the DHCP server is also providing a local DNS server as well and if so, DNS may need to be cleaned up. Lastly, systems which had trouble connecting may need to be rebooted (or have their DNS cache flushed).
1 Like
BTW, all of the RPi systems (each with unique names) on my LAN have both IPV4 and IPV6 addresses. They get their IPV4 addresses via DHCP. I don't think you need to limit your RPi systems to IPV4 only.
Quick update - The instance names are / were unique, but I went ahead and gave Instance 1 a new name anyway - cr10spro-v1. It was again inaccessible this morning. I tried deactivating my BitDefender security app, but that didn't have any beneficial affect.
I did power cycle cr10spro-v1 and that did enable me to get into the instance.
I have not been able to cycle my Orbi - that will have to wait for this evening. Everyone home, running school remotely and my son has a virtual interview this afternoon as well. 
Don't want to jinx anything.
I own the Orbi pair and they work great for me. I will note that the Avahi service in tandem with Netgear routers (Orbi) or similar will negotiate hostnames sometimes in ways that are weird.
cat /var/log/syslog | grep Avahi
Sometimes this will say, essentially, something like "I know you just asked for octopi as a name but I'm going to issue you octopi-2 instead. This typically happens right after you pull a microSD card from one Pi and place it into another. The 2nd Pi's Avahi service will come up, ask if it's okay to broadcast as octopi, the Netgear router will say "no" and then Avahi will decorate its name to octopi-2, ask the Netgear, it says "yes" and then it's now this.
I ran the cat command but didn't see anything peculiar in the Avahi output with regards to renaming the instance.
I did reboot the Orbi (which has also worked very well for me), but that didn't change the behaviour.
Next, I did resolve the bash issue with setting the safe mode flag by executing (prepending the ./ was the key):
> ./octoprint safemode
It is now running in safemode and appears to be accessible. Would the log files be of any help? I'm unsure if being accessible is just a feature of restarting the octoprint service or if the restart has actually removed a conflict. I'll see if I can use it through out the day and see if things are better.
It appears then that Safe Mode works. This means that one of your plugins is somehow getting in the way. If you're in love with your existing set of 3rd-party plugins, you could attempt to troubleshoot which one caused you the trouble.
In a case where "the trouble" prevents you from bringing up OctoPrint from the interface, this becomes a little tougher, of course. Reviewing the earlier octoprint log should indicate something that's throwing errors; those lines usually indicate which plugin was the cause of your woes.