Drive eating me inside out

[duskfallcrew]

ERROR:root:Internal Python error in the inspect module. Below is the traceback from this internal error.

Traceback (most recent call last): File "/usr/local/lib/python3.9/dist-packages/IPython/core/interactiveshell.py", line 3326, in run_code exec(code_obj, self.user_global_ns, self.user_ns) File "", line 28, in get_ipython().run_line_magic('cd', '/content/gdrive/MyDrive/sd/stable-diffusion-webui/modules/') File "/usr/local/lib/python3.9/dist-packages/IPython/core/interactiveshell.py", line 2314, in run_line_magic result = fn(*args, kwargs) File "", line 2, in cd File "/usr/local/lib/python3.9/dist-packages/IPython/core/magic.py", line 187, in call = lambda f, *a, *k: f(a, k) File "/usr/local/lib/python3.9/dist-packages/IPython/core/magics/osm.py", line 334, in cd oldcwd = os.getcwd() OSError: [Errno 107] Transport endpoint is not connected

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/usr/local/lib/python3.9/dist-packages/IPython/core/interactiveshell.py", line 2040, in showtraceback stb = value._rendertraceback() AttributeError: 'OSError' object has no attribute '_rendertraceback'

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/usr/local/lib/python3.9/dist-packages/IPython/core/ultratb.py", line 1101, in get_records return _fixed_getinnerframes(etb, number_of_lines_of_context, tb_offset) File "/usr/local/lib/python3.9/dist-packages/IPython/core/ultratb.py", line 319, in wrapped return f(*args, **kwargs) File "/usr/local/lib/python3.9/dist-packages/IPython/core/ultratb.py", line 353, in _fixed_getinnerframes records = fix_frame_records_filenames(inspect.getinnerframes(etb, context)) File "/usr/lib/python3.9/inspect.py", line 1543, in getinnerframes frameinfo = (tb.tb_frame,) + getframeinfo(tb, context) File "/usr/lib/python3.9/inspect.py", line 1501, in getframeinfo filename = getsourcefile(frame) or getfile(frame) File "/usr/lib/python3.9/inspect.py", line 709, in getsourcefile if getattr(getmodule(object, filename), 'loader', None) is not None: File "/usr/lib/python3.9/inspect.py", line 738, in getmodule file = getabsfile(object, _filename) File "/usr/lib/python3.9/inspect.py", line 722, in getabsfile return os.path.normcase(os.path.abspath(_filename)) File "/usr/lib/python3.9/posixpath.py", line 380, in abspath cwd = os.getcwd() OSError: [Errno 107] Transport endpoint is not connected

.... I suspect this is drive, because EVERY TIME I install google drive desktop it does this to me, and now i'm on a better machine i'd .... I DONT KNOW WHY it does this. Temporarily, i'm not quitting using fast sd just.. XD going back to my crappy other notebook because for some reason Gdrive is hating me

[Ai-Artsca]

The error message suggests that there is an issue with accessing the Google Drive folder due to a problem with the Transport endpoint not being connected. This could be due to a problem with the Google Drive desktop application or a network connectivity issue.

One solution to try is to restart the Google Drive desktop application and ensure that your network connection is stable. If the problem persists, you could try disconnecting and reconnecting your Google Drive account to the desktop application.

Alternatively, you could try accessing the Google Drive folder directly from your web browser, as this may bypass any issues with the desktop application.

If none of these solutions work, it may be worth seeking assistance from the Google Drive support team.

[TheLastBen]

try ngrok

[duskfallcrew]

I'll try AGAIN with ngrok i have been using both local tunnel and ngrok, and honestly i'm on a wired - not true wired but power over ethernet connection and was able to stream on twitch for over three hours yestereday :P

[duskfallcrew]

try ngrok

Currently sitting over 9 minutes trying to connect to the SD instance with no "ERRORS" but it's hanging, I have a backup notebook I can use (that i dont like as much as yours) in the mean time, - but will keep SD installed with yours so in case things perk up after the gradio update i don't have to reinstall :P

it sat for 11 minutes, i hit "STOP" and it had a lora.py issue, and this is the most recent update in notebook, i'll see if it's still snagging - i hit the button again seeing if it'll work.

Ok it's LOADING NOW, and i'll report back if Gradio is behaving or not, this is MAYBE GOING TO WORK THIS TIME FINGERS CROSSED

[anonderpling]

I can't guarantee it won't break again (it probably will, it's an issue with colab), but the following steps will allow you to restart SD without restarting the runtime (and having to reinstall SD). Basically, it unmounts google drive so you can remount it again (It shouldn't ask for permission, since you've already given permission).

1. Add another cell with this in it, it prevents needing to restart the runtime to restart SD

# change directory away from an invalid directory that doesn't exist. jupyter doesn't like it when that happens, and won't let you use `%cd`
os.chdir('/content'); 
!fusermount -u /content/gdrive # now unmount the drive
drive.mount('/content/gdrive') # and remount it

2. Run the new cell
3. Try starting the last official cell again (the one that starts A1111)

@TheLastBen this isn't an issue related to ngrok or localtunnel or gradio or etc. This is because the google drive itself is being disconnected. It's an error from the filesystem, not from A1111/python. The more annoying part is that you can't use jupyter %magic or !shell commands to change the directory, because both require a valid CWD (hence os.chdir()). This is an issue with colab itself, that makes me wonder if maybe whatever they're using is based on google-drive-ocamlfuse