mirror of
https://github.com/DominikDoom/a1111-sd-webui-tagcomplete.git
synced 2026-11-05 00:17:25 +00:00
[GH-ISSUE #301] [WebUI ReForge] LoRAs/Checkpoints/Embeddings/UI itself are not refreshing/reloading #208
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
low priority
low priority
pull-request
question
waiting for feedback
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
DominikDoom/a1111-sd-webui-tagcomplete#208
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Hazitos on GitHub (Sep 4, 2024).
Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/301
WebUI: ReForge - [f1.1.0dev-v1.10.1RC-latest-1147-g3e80b4d8]
Python: 3.10.0
Torch: 2.3.1+cu121
Gradio: 3.41.2
A month or so ago my UI started to freeze refreshing the LoRAs tab and then eventually the embeddings and checkpoints also did and now I can't even reload the webui, I gotta fully close and reopen it if I want to refresh certain things and I get this tagcomplete message in the dev tools.
This is the only thing that shows up whenever I refresh anything.
@DominikDoom commented on GitHub (Sep 4, 2024):
The message isn't abnormal, in fact that it appears means at least TAC itself refreshed successfully. As for Lora and the UI itself, TAC listens to the refresh event but just reuses the internal data of the webui, it doesn't (or rather shouldn't) interfere in any way.
Does it also happen if you disable TAC? If so, it's likely unrelated.
There also is the setting "Don't re-scan for wildcard files when pressing the extra networks refresh button" which I added after a user reported refreshing issues due to their wildcard collection (thousands of files symlinked on a slower external hard drive).
Other than that I can only suggest checking the lora/embedding files themselves, it might be a corrupted file or just the total amount of files being very high causing issues.
@Hazitos commented on GitHub (Sep 4, 2024):
Thing is while I do have quite a number of LoRAs this doesn't seem to be the issue since my friends have even more than me, and about the wildcards thing, while I do have the extension I have never used it as I don't exactly know how wildcards work. And I did some testings with a friend a while ago and I completely removed the extension and everything went back to working and loading normally.
I did try clicking the TAC refresh button, and it was a while ago now and it's still loading infinitely.
@DominikDoom commented on GitHub (Sep 4, 2024):
Yeah that's definitely abnormal, it takes max 3 seconds for me with a good amount of loras, embeddings etc.
The amount question was more about extreme cases to make sure, e.g. the user with the wildcard issues I mentioned used a bundle with like 150k wildcards in it. That caused loading issues due to each request trying to parse a 35+ MB file.
Is there anything suspicious in the network tab of the browser dev tools when you start a refresh? For example a request that starts but never returns.
@Hazitos commented on GitHub (Sep 4, 2024):
I didn't notice anything "suspicious" in it, though I don't really know what i'm looking at lol
@DominikDoom commented on GitHub (Sep 4, 2024):
That was just to get a list of all files TAC reloads after clicking on the refresh, I was hoping to see a culprit from a TAC-related file not responding or something like that.
There is actually one suspicious thing:
Pending means the response wasn't received yet. For comparison, this is what it looks like on my end (with 2000+ Loras, ~500 Embeddings and ~150 wildcards):
https://github.com/user-attachments/assets/904afbcc-1190-49b4-a960-deb238a7c6bb
As you can see, the pending "join" resolves relatively quickly - that is also the moment when the refresh in the UI finishes.
The bad news is that join is from webui internals - I have no clue what would cause the issue you experience at the moment.
TAC seems to get all its files normally, for some reason your webui / its gradio backend just doesn't receive answers to its own communication requests.
It might be a somehow corrupted venv, issues with specific files, extension conflicts, etc. Extremely hard to diagnose.
If possible I would suggest trying to reproduce the bug with a minimal setup - delete and let it recreate the venv, TAC as the only active 3rd party extension and renaming the lora or embedding folders to see if a file there might be the issue.
@DominikDoom commented on GitHub (Sep 4, 2024):
Ah, I just noticed the full refresh-temp-files request is unusually long with 12+ seconds, so something is definitely going on there. It might be that the webui times out while waiting for TAC and gets stuck because of that. But still no clue why it takes that long. There must be something related to the files it searches.
How many embeddings/lora do you have, if you can give a rough number? Any symlinks? Slow harddrive, network share, anything like that?
EDIT: Also, sorry for the info-dump, but another thing to try:
Find this line in
extensions/<tag-autocomplete folder>/scripts/tag_autocomplete_helper.pyAnd change the
force=Truetoforce=False(watch out for the capitalization).Does that change anything?
@Hazitos commented on GitHub (Sep 4, 2024):
Embeddings I have about 10, don't use them much, now LoRAs... Surprisingly... I have 713. I did not actually know I had that many lol. I don't know what Symlinks are, my harddrive is slightly slow but good enough and I have no network share.
One tidbit I should add, when I was testing stuff with my friend a couple weeks ago I fully reinstalled my python on another drive to see if anything would change, any nothing did. I also have all my AI-related stuff together in this one 1TB HDD. That refresh_embeddings part was already set to False.
@DominikDoom commented on GitHub (Sep 4, 2024):
That amount should be no problem, like you said. But it's also nothing that warrants the reload taking over twelve seconds.
Even the slowest HDD would be faster than that.
Are you sure? There's a call with false in line 741 which you might've confused it with:
But that other one in line 483 should be true in the current TAC version.
Since you only have 10, I don't think that's the cause, but it doesn't hurt to try.
Other than that, did you already try with the skip wildcard refresh option on? Even if you don't use wildcards, another extension might've added a lot of wildcard files, so just to make sure it has no impact would be good to know.
@Hazitos commented on GitHub (Sep 4, 2024):
I have had wildcard part enabled for a while now yes and you're right, I had only one of the refresh_embeddings on False, I hadn't seen the 483 one, I'll test it right now.
Thank you for being so helpful by the way, I should've asked you sooner.
@Hazitos commented on GitHub (Sep 4, 2024):
Okay man, after changing both refresh_embeddings to False, everything is refreshing just fine, even faster now. Thank you very very much for going so far to help me!
@DominikDoom commented on GitHub (Sep 4, 2024):
Glad to hear, although I'm still unsure why it would cause that. After all I just pass that parameter to the webui itself.
Anyway, I'll quickly add an actual option for it so you can change this behavior without modifying the code (which would break with updates).
@Hazitos commented on GitHub (Sep 4, 2024):
Also one more thing. This whole issue began, the very same day another issue with Civitai Helper began where it would download stuff like normal but the descriptions would all be broken like this, so maybe these two have some issue together?
@DominikDoom commented on GitHub (Sep 4, 2024):
Don't think so, that is just an issue with how Civitai Helper shows HTML in this box (or more like that it doesn't).
The "broken" stuff is just the formatting from the civitai website, instead of plain text the author wrote their description in this way to highlight different words with colors or bold text.
@DominikDoom commented on GitHub (Sep 4, 2024):
Alright, you should be able to update throught the webui now and get the "official" fix.
After considering for a bit, I made it off by default, with the option being to restore the old behavior with force=True. So in your case you don't need to change anything with the new setting and it should work.
@Hazitos commented on GitHub (Sep 4, 2024):
It's like that with everything I download through civitai helper though, same thing is happening with my friend. It started the very same day as TAC's issues, so either it's something to do with ReForge or something else idk
@Hazitos commented on GitHub (Sep 4, 2024):
This is how it's supposed to be formatted, all of the ones downloaded from before these issues began are like this.
@DominikDoom commented on GitHub (Sep 4, 2024):
Definitely a change on Civitai helper's side, also happens with the base webui. I guess its default behavior just coincidentally changed around the same time.
Civitai Helper has this option you can check:
which will convert it to plain text.
@Hazitos commented on GitHub (Sep 4, 2024):
Me and my friend both tried that and it didn't do anything with or without it, so it's an issue on their end.
@DominikDoom commented on GitHub (Sep 4, 2024):
It will only change it for new downloads, descriptions for existing models come from a json file next to the model on your disk and won't get modified automatically.