Open pochrist opened 1 year ago
I had this happen to me a couple of days ago and I was stuck on it for a long time. Ultimately I did a number of things and got it to finally work, but I'm not sure which thing specifically was the fix.
The first thing I did was disable quite a few extensions at a time, mainly ones I didn't think I would be using any time soon.
The second thing I did was to go to the webui-user.bat file and add a line that said "git pull" between the "set COMMANDLINE_ARGS=" line (and any arguments you have added there) and the "call webui.bat" line. This little bit of code basically checks for an Automatic1111 update every time you launch it from said bat file, insuring you're running the latest version. I think that was the issue, that A1111 was a smidge behind and some kind of breaking incompatibility has cropped up between the open outpaint extension and older versions, but I don't know for sure. It could be just an incompatibility with any number of other webui extensions that are active.
thanks for the reply, yea I also have no other extensions loading now but this one. I added the "git pull" command where you indicated but no luck, I am by no means a developer I bumble around at best I decided to take a look at the source code on the Webui Webpage and noticed that where the buttons call to the scripts their are 2 entries for the open paint script but all the other seem o be single - maybe its nothing but I thought it was interesting.
I face same issue
so i'm completely unable to reproduce this as long as webUI is on (or beyond) the gradio verison bump commit and openOutpaint is on (or beyond) the associated commit to fix the buttons for the new classes
anyone experiencing this, please verify:
commit version of webUI - a9fed7c3
Version of openOutpaint - v0.0.15.3 (2023410.001)
Tried CTRL+F5 - no luck
Just for shits and giggles tried Running "inPrivate" Mode - Nope and Tried Running as Admin - Nope
On Wed, Apr 19, 2023 at 5:33 PM tim h @.***> wrote:
so i'm completely unable to reproduce this as long as webUI is on (or beyond) the gradio verison bump commit https://github.com/AUTOMATIC1111/stable-diffusion-webui/commit/b0b777e64da238f1b259b77b0899b61c26a99dee and openOutpaint is on (or beyond) the associated commit to fix the buttons for the new classes https://github.com/zero01101/openOutpaint-webUI-extension/commit/566a8a53c910f902297c4926f0d3634900403e53
anyone experiencing this, please verify:
- the commit version of webUI (should be visible at the bottom of the page) [image: image] https://user-images.githubusercontent.com/1649724/233204805-6541aa34-bfac-4884-8f05-e06b66328893.png
- the version of openOutpaint (open the Debug Info section) [image: image] https://user-images.githubusercontent.com/1649724/233204895-c08a889a-6e4d-4b9b-a3ed-784d6b17f209.png
- just out of curiosity, if both are as recent as possible, try force-refreshing the webUI page without cache (may have to disable cache in your F12 browser devtools, or CTRL+F5 on windows generally, not sure elsewhere) and see if that brings them back to life as i'm wondering if the extension's JS is caching somewhere that it shouldn't
— Reply to this email directly, view it on GitHub https://github.com/zero01101/openOutpaint-webUI-extension/issues/51#issuecomment-1515413185, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5BDLVEGAFSATXF4LJ5Y5UTXCBK4JANCNFSM6AAAAAAXCZH7L4 . You are receiving this because you authored the thread.Message ID: @.***>
commit version of webUI - a9fed7c3
that'd do it; that commit predates the gradio updates significantly so the classes have changed pretty heavily.
you can open a command prompt, navigate to your webUI's installation directory, run cd extensions\openOutpaint-webUI-extension
, and run git checkout 46534e840476dcbea4791d938f711a0d461c1ba5
which will revert openOutpaint to the commit before the update for gradio changes, or you can update webUI to a more recent commit
Yup that did it, works perfect now. Thanks for the help.
commit version of webUI - a9fed7c3
that'd do it; that commit predates the gradio updates significantly so the classes have changed pretty heavily.
you can open a command prompt, navigate to your webUI's installation directory, run
cd extensions\openOutpaint-webUI-extension
, and rungit checkout 46534e840476dcbea4791d938f711a0d461c1ba5
which will revert openOutpaint to the commit before the update for gradio changes, or you can update webUI to a more recent commit
Hey Zero, quick question about this -- if Pochrist's version of the webUI was outdated, and adding the "git pull" code to the webui-user.bat file between the set COMMANDLINE_ARGS= line and the call webui.bat line typically forces the bat to check and install an update to the webUI every time it launches (thus updating the webui to a commit that isn't outdated), why didn't that work for Pochrist in solving the problem?
I'm asking just because this particular issue plagued me for a long time, like over a week, and I kind of want to understand what is and isn't a solution better in case it ever crops up again in the future (or someone else strolls along that just hasn't gotten the memo yet and I can just quickly drop the answer on them).
why didn't that work for Pochrist in solving the problem?
of course i can't answer for them, but i'm guessing downgrading the extension did the trick as opposed to upgrading webUI - simply adding git pull
won't actually update anything if tracked files conflict locally of course, so something as simple as adding i guess that example is only applicable if webui-user.bat was updated between the repo being cloned and attempting to update it, but i'd still posit that a local change to a tracked file is the case --api
to the webui-user.bat commandline_args parameter could prevent pulling in the newest updates from succeeding if those changes aren't committed to a local repo fork or something similar
Just to be clear I opted to update the web-UI instead of rolling back the extension becasue I figured eventually I'll be forced to update the Web-UI in the future at some point anyway. It worked on both the computers I was having the issue on.
Is ths issue about the extension?
What happened?
Extension Tab and bottom button load, but "send to outpaint" does nothing, no manual way to add an image as far I can see if I just go to the Tab
Steps to reproduce the problem
What should have happened?
Tab should open with image loaded
Commit where the problem happens
Latest as of 4-18-23
What platforms do you use to access openOutpaint?
Windows
What browsers do you use to access the UI ?
Mozilla Firefox, Google Chrome
Browser Extensions/Addons
Google Chrome
Firefox - all Blockers are set to whitelist on Automatic111 webui
AUTOMATIC1111 webUI Commandline Arguments
--api
Additional information
No response