stable-diffusion-webui-forge icon indicating copy to clipboard operation
stable-diffusion-webui-forge copied to clipboard

Checkpoint Hashs being read incorrectly

Open KizlanH opened this issue 1 year ago • 3 comments

Checkpoint hashes are loading incorrectly since updating. They appear to be loading off the filename rather than the checkpoint data. The same Checkpoint file copied with a different filename is showing a different hash for each file. This is causing Civitai to fail to recognize, or mislabel model use.

Loading up A1111 or reForge show all 3 filenames with identical correct hashes. (but they don't work as well for me, so I'd rather use Forge).

Loras appear to be working fine and are still recognized by their hashes. I'm only seeing the issue for checkpoints.

Is there a setting or method I can use to revert checkpoint hashes to the previous method?

Thanks.

Edit: ran ComfyUI with custom node to save model data in image metadata, and it also uses the correct hash regardless of filename. Issue is only occurring in Forge.

KizlanH avatar Sep 26 '24 19:09 KizlanH

Known issue from #1650

Juqowel avatar Sep 27 '24 08:09 Juqowel

my brother in forge pls same

da1barker avatar Sep 28 '24 00:09 da1barker

Posting here in case it helps someone. But I got it to read CivitAI's AutoV2 model hash by going to forge's modules/hashes.py, commenting the code there, and pasting Automatic1111's modules/hashes.py. Then I just cleared the /cache folder and restarted the app. So far I haven't come across any trouble.

ricktvr avatar Oct 02 '24 21:10 ricktvr

I did some digging on the issue and found that changes to the hashing functions seem to originate from cfa5242a7581a4a27cb7e3d7bb46ba8d1a2f8d99. The original function which calculates hash from file's binary representation is replaced with one that, indeed, calculates hash from filename. No idea why this change was introduced.

I can also confirm that reverting these changes in modules/hashes.py and clearing the cache makes Forge calculate correct hashes again with no apparent issues.

Edit: Apparently, #1647 is supposed to fix this issue, but is been hanging there for over a month.

Siberpone avatar Oct 12 '24 10:10 Siberpone