mirror of
https://github.com/DominikDoom/a1111-sd-webui-tagcomplete.git
synced 2026-11-05 00:17:25 +00:00
[GH-ISSUE #242] The extension errors every time a checkpoint or VAE is loaded (SD.Next) #174
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#174
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 @mart-hill on GitHub (Sep 25, 2023).
Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/242
Hi!
I noticed, that for some time, with recent update of the extension, there's an error every time I load a new checkpoint or VAE (the loading of those at startup is fine):
There's also a bug with embeddings not being listed anymore, despite the option being set at default for them. The embeddings I use are in the symlinked folder.It happens on SD.Next UI with 89ba8e3c commit.
@DominikDoom commented on GitHub (Sep 26, 2023):
After being stuck for a bit, I think that the issue is SD.Next not supporting SDXL embeddings properly, possibly as a side effect of SDXL only working with diffusers there. Do you maybe have any lying around?
From what I've seen in the SD.Next code, they get detected as diffusers concepts, but since the data format is wrong they get skipped.
The issue here is that while in auto1111 they are just ignored but still registered properly, in SD.Next the function exits prematurely, before other info about the skipped embedding like filepaths was added. This is a bug / side effect in SD.Next.
When switching models, tag autocomplete looks up the embeddings to determine their type (sdv1/sdv2, with sdxl being detected as the latter for now). The error then happens when trying to look up these skipped sdxl embeddings, since they have been registered as skipped but are missing filepath and other info, which a1111 on the other hand keeps intact.
I have added a safety check for missing paths on my side, so the error after a model switch should be fixed now. It will also hide those embeddings from autocompletion. In SD.Next it shouldn't be too much of an issue since they seem unsupported anyway.
The root cause of the behavioral difference / bug in SD.Next is still there, but I imagine it will be fixed when they add sdxl support to the original backend instead of just diffusers.
@mart-hill commented on GitHub (Sep 26, 2023):
Thank you for quick fix!

The only XL embeddings I have are those 'negatives':
Could they be the cause?
@DominikDoom commented on GitHub (Sep 26, 2023):
I think these are the same I noticed the problem with, they're from CounterfeitXL, right?
I found an issue on the SD.Next repo that had the same problem, so I mentioned it there. As of now, vlad has already fixed it in the dev branch in response, so it should soon be properly resolved.
It seems specifically related to loading these sdxl embeddings on the original backend (where SD.Next doesn't support sdxl models yet) instead of the diffusers one, which caused the original bug/oversight.
Just out of interest since I don't have one downloaded right now:
In case you have a diffusers XL model you use with SD.Next, do these embeddings get correctly loaded there?
Would be interesting to know if they are incompatible with diffusers or were just not properly skipped on the original backend.
@mart-hill commented on GitHub (Sep 26, 2023):
I noticed that in Vlad's dev branch as well, can't wait to get original backend implemented for SDXL. 🙂
For the diffusers backend+SDXL, I have trouble running it at all (and since it's still fresh, I'm patiently waiting for fully fledged SDXL support), so I didn't test it much, yet, and I'm using last 'main' branch of the SD.Next, before Vlad started implementing big changes into 'dev' branch and stated, that it's best to go with fresh
git pullbecause of these changes. 🙂