Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autotag Complete Not Wkring since Last Forge Update #302

Open
ThesiiNCey opened this issue Oct 4, 2024 · 9 comments
Open

Autotag Complete Not Wkring since Last Forge Update #302

ThesiiNCey opened this issue Oct 4, 2024 · 9 comments

Comments

@ThesiiNCey
Copy link

Autotag Complete Not Wkring since Last Forge Update

I also tried a clean new installation in another folder with 1111 Webui, it doesn't work with Forge

@DominikDoom
Copy link
Owner

It works normally for me on forge f2.0.1v1.10.1-previous-549-g4baf8ffb / Commit hash 4baf8ffb9c617c05a4e3c23dcaafcdcedf5e42b2, which is the most recent release on the forge main branch at the time I write this.

So if it wasn't caused by something already fixed by now in forge and still doesn't work for you, I can't help you without more information. Are there any errors logged in the terminal window or in the browser console?

@gitupp22
Copy link

gitupp22 commented Oct 6, 2024

image
I get errors like this when typing in A1111. It works fine in forge though.

@andy8992
Copy link

andy8992 commented Oct 6, 2024


*** Error loading script: model_keyword_support.py
Traceback (most recent call last):
File "E:\Data\Packages\Stable Diffusion WebUI Forge\modules\scripts.py", line 525, in load_scripts
script_module = script_loading.load_module(scriptfile.path)
File "E:\Data\Packages\Stable Diffusion WebUI Forge\modules\script_loading.py", line 13, in load_module
module_spec.loader.exec_module(module)
File "", line 883, in exec_module
File "", line 241, in _call_with_frames_removed
File "E:\Data\Packages\Stable Diffusion WebUI Forge\extensions\a1111-sd-webui-tagcomplete\scripts\model_keyword_support.py", line 7, in
from scripts.shared_paths import EXT_PATH, STATIC_TEMP_PATH, TEMP_PATH
ModuleNotFoundError: No module named 'scripts.shared_paths'


*** Error loading script: tag_autocomplete_helper.py
Traceback (most recent call last):
File "E:\Data\Packages\Stable Diffusion WebUI Forge\modules\scripts.py", line 525, in load_scripts
script_module = script_loading.load_module(scriptfile.path)
File "E:\Data\Packages\Stable Diffusion WebUI Forge\modules\script_loading.py", line 13, in load_module
module_spec.loader.exec_module(module)
File "", line 883, in exec_module
File "", line 241, in _call_with_frames_removed
File "E:\Data\Packages\Stable Diffusion WebUI Forge\extensions\a1111-sd-webui-tagcomplete\scripts\tag_autocomplete_helper.py", line 20, in
from scripts.model_keyword_support import (get_lora_simple_hash,
ModuleNotFoundError: No module named 'scripts.model_keyword_support'


*** Error loading script: tag_frequency_db.py
Traceback (most recent call last):
File "E:\Data\Packages\Stable Diffusion WebUI Forge\modules\scripts.py", line 525, in load_scripts
script_module = script_loading.load_module(scriptfile.path)
File "E:\Data\Packages\Stable Diffusion WebUI Forge\modules\script_loading.py", line 13, in load_module
module_spec.loader.exec_module(module)
File "", line 883, in exec_module
File "", line 241, in _call_with_frames_removed
File "E:\Data\Packages\Stable Diffusion WebUI Forge\extensions\a1111-sd-webui-tagcomplete\scripts\tag_frequency_db.py", line 4, in
from scripts.shared_paths import TAGS_PATH
ModuleNotFoundError: No module named 'scripts.shared_paths'

@DominikDoom
Copy link
Owner

DominikDoom commented Oct 6, 2024

@gitupp22 never seen that before, but it looks like an encoding error. That is most definitely not related to this though, so please open a new issue for it. EDIT: Ah, I see you already asked in discussions.

@andy8992 This is an old forge bug that has been fixed on their side ages ago, see #299. TL;DR: you need to make sure forge is updated and likely have to recreate your venv. It's a dependency conflict that messes up not only TAC, but all extensions that import from local files without a module.

@ThesiiNCey
Copy link
Author

It works normally for me on forge f2.0.1v1.10.1-previous-549-g4baf8ffb / Commit hash 4baf8ffb9c617c05a4e3c23dcaafcdcedf5e42b2, which is the most recent release on the forge main branch at the time I write this.

So if it wasn't caused by something already fixed by now in forge and still doesn't work for you, I can't help you without more information. Are there any errors logged in the terminal window or in the browser console?

I found out as soon as you install CivitAi Browser Plus the Tag Complete no longer works. Could you take a look at that?

@DominikDoom
Copy link
Owner

DominikDoom commented Oct 10, 2024

@ThesiiNCey Thanks for the info, I had a look and was able to figure something out. However, it's sadly out of my control. The short answer is that Civitai Browser Plus is pretty buggy right now, especially on forge.
The actual issue is related to BlafKing/sd-civitai-browser-plus#326.

Civitai Browser Plus has some update conditions that result in infinite loops, the main culprit I could find was this part of its UI code: preview_html.change(fn=None, _js="() => adjustFilterBoxAndButtons()")

adjustFilterBoxAndButtons() is a function that on its own makes changes to the preview HTML, so it triggers itself again and again. This results in massive lags even on a high-end system, I'm seeing constant 8% CPU usage in chrome vs 0-1% without Civitai Browser installed.

Why does this affect Tag Autocomplete instead of just causing laggy UI?

Because Gradio, at least in forge, uses a queuing system to process scripts. Normally, this is good for performance as it spreads out loading a bit. But in this case the queue gets completely filled with these infinite update loops, so almost no other script gets a chance to load. This doesn't just affect TAC, but it's especially noticeable here, since TAC needs to load its tag files into the browser before it can even start working.

You can easily test this yourself:
Start the webui, wait until the page loads, then switch to a different tab for a few seconds and back to the webui. Suddenly, TAC will work again, even if it wasn't before. That's because as soon as the page is no longer the open tab, gradio pauses UI updates to save performance, resulting in a much emptier queue and TAC getting a chance to load.


Now, all this being said, there is pretty much nothing I can do to fix this on my side. You'll have to wait until Civitai Browser is updated to resolve these infinite loop issues. I would honestly recommend not using it at all until then (at least on forge) as the performance issues it causes make the whole UI worse to use.

@crusader290
Copy link

crusader290 commented Nov 15, 2024

@DominikDoom

Now, all this being said, there is pretty much nothing I can do to fix this on my side. You'll have to wait until Civitai Browser is updated to resolve these infinite loop issues. I would honestly recommend not using it at all until then (at least on forge) as the performance issues it causes make the whole UI worse to use.

I don't even have Civitai Browser installed. All the base tags show up on auto-completion (even the Booru ones) and even my LoRAs... just none of my added Embeddings/Textual Inversions show which can be quite annoying.

@DominikDoom
Copy link
Owner

@crusader290 I think you are talking about a different thing here. It sounds more like what I mentioned in #297, this could be the cause here:

Like some other implementations (maybe also dependent on settings), the SD model now gets loaded not on startup, but on demand (i.e. once you click generate)
TAC uses the webui's internal model database to fast-reload embeddings and figure out if they're SD1/SD2/SDXL, so before the model is loaded, embeddings will show up as "unknown". This is not fixable. Once the model was loaded for the first time, it should show the correct types.
This also means that newly added embeddings will only show up after a model switch/reload

TAC has a force-refresh button at the bottom of its settings list, you could try generating something so the model is guaranteed to be loaded and then hit that refresh button. That should update the embedding list if nothing else works.

@crusader290
Copy link

crusader290 commented Dec 17, 2024

@crusader290 I think you are talking about a different thing here. It sounds more like what I mentioned in #297, this could be the cause here:

Like some other implementations (maybe also dependent on settings), the SD model now gets loaded not on startup, but on demand (i.e. once you click generate)
TAC uses the webui's internal model database to fast-reload embeddings and figure out if they're SD1/SD2/SDXL, so before the model is loaded, embeddings will show up as "unknown". This is not fixable. Once the model was loaded for the first time, it should show the correct types.
This also means that newly added embeddings will only show up after a model switch/reload

TAC has a force-refresh button at the bottom of its settings list, you could try generating something so the model is guaranteed to be loaded and then hit that refresh button. That should update the embedding list if nothing else works.

@DominikDoom
Thank you so much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants