ComplexRobot
commented
8 months ago I've run into this issue myself. Looking at the code, the lora prompt text must fit the regex pattern <(lora|hypernet):([a-zA-Z0-9_\.\-\s]+):([0-9.]+)(?:[:].*)?> to be properly parsed and written to the metadata.
In other words, the lora name can only contain letters, numbers, underscores, periods, hyphens and white space. The actual prompt is not that restrictive.
Also, it uses the filename for the lookup so the lora string must be the filename, not the internal name. (There is a setting to insert the names as their filename.)
And the hashes are written at startup, so after renaming the file you have to completely restart the UI.
Noticed that my LoRAs that have parentheses in their filenames weren't properly listed in the image metadata.
To recreate this bug: -Create an image with a LoRA from civitai (one that you are sure is properly added to the metadata, and is detected when uploading the image to civitai). -Close your instance of stable diffusion and rename the filename of the LoRA adding "(test)" or something similar -Make an image with that same LoRA
The new image should not have the LoRA's hash value in the metadata.
I've noticed similar behavior with too many hyphens in the filename, too many double hyphens in the filename, filenames that are too long (potential issue with max filename path length?), and filenames that are significantly different from the default filename found on civitai.
I suspect that whatever function is used in this extension for generating hash values throws an exception when given a filename with parentheses, which is then caught and suppressed, so no hash is generated.
If the bug can't be recreated, let me know and I can generate some images on my end to provide examples.