BlafKing / sd-civitai-browser-plus

Extension to access CivitAI via WebUI: download, delete, scan for updates, list installed models, assign tags, and boost downloads with multi-threading.
GNU Affero General Public License v3.0
309 stars 53 forks source link

[Bug]: Error when downloading a certain LORA #149

Closed ManOrMonster closed 9 months ago

ManOrMonster commented 9 months ago

Describe the bug.

I'm trying to download this LORA: https://civitai.com/models/245862/pulp-cover-art

It downloads the model then throws an error when trying to verify the hash. I haven't had this issue with other downloads today. I had to restart auto1111 to get the extension working again, and it threw that error again on the same LORA.

Steps to reproduce the problem.

  1. Search LORA/LoCon for "Pulp Cover Art"
  2. Download the model

Expected behavior

It should download the model, verify the hash, then download the art.

System info

Console logs

CivitAI Browser+: Model saved to: C:\stable-diffusion\automatic1111\models\Lora\.styles-art\styles\Pulp_Cover_Art.safetensors
CivitAI Browser+: Model info saved to "C:\stable-diffusion\automatic1111\models\Lora\.styles-art\styles\Pulp_Cover_Art.json"
Traceback (most recent call last):
  File "C:\stable-diffusion\automatic1111\venv\lib\site-packages\gradio\routes.py", line 488, in run_predict
    output = await app.get_blocks().process_api(
  File "C:\stable-diffusion\automatic1111\venv\lib\site-packages\gradio\blocks.py", line 1431, in process_api
    result = await self.call_function(
  File "C:\stable-diffusion\automatic1111\venv\lib\site-packages\gradio\blocks.py", line 1103, in call_function
    prediction = await anyio.to_thread.run_sync(
  File "C:\stable-diffusion\automatic1111\venv\lib\site-packages\anyio\to_thread.py", line 33, in run_sync
    return await get_asynclib().run_sync_in_worker_thread(
  File "C:\stable-diffusion\automatic1111\venv\lib\site-packages\anyio\_backends\_asyncio.py", line 877, in run_sync_in_worker_thread
    return await future
  File "C:\stable-diffusion\automatic1111\venv\lib\site-packages\anyio\_backends\_asyncio.py", line 807, in run
    result = context.run(func, *args)
  File "C:\stable-diffusion\automatic1111\venv\lib\site-packages\gradio\utils.py", line 707, in wrapper
    response = f(*args, **kwargs)
  File "C:\stable-diffusion\automatic1111\extensions\sd-civitai-browser-plus\scripts\civitai_download.py", line 610, in download_create_thread
    _file.save_preview(path_to_new_file, item['model_json'], True, item['model_sha256'])
  File "C:\stable-diffusion\automatic1111\extensions\sd-civitai-browser-plus\scripts\civitai_file_manage.py", line 172, in save_preview
    if file_entry["hashes"]["SHA256"] == sha256:
KeyError: 'SHA256'

Additional information

Just passing this along in case there's some new intermittent issue that needs to be fixed going forward.

Worldgate commented 9 months ago

Amusing enough, if two lora have the same name, it gets confused. for example there two 'Blaziken' lora and it gets confused between them. And sometimes, for example this one (https://civitai.com/models/123021), it doesn't import all of the versions of a model.

BlafKing commented 9 months ago

Thanks for reporting!

This issue ended up being caused by the CivitAI API, since it returns a file which no longer exists on the server. The model you sent returns 2 files and I see now that the API includes a primary field for the primary file, which in the case of the model you supplied is the working file.

So i'll make it so that the file with the primary tag is actually used as the default file. I'll also make the error log a bit clearer when a non existing file is selected. I'll add both of these changes in an upcoming update soon! :)

BlafKing commented 9 months ago

Amusing enough, if two lora have the same name, it gets confused. for example there two 'Blaziken' lora and it gets confused between them. And sometimes, for example this one (https://civitai.com/models/123021), it doesn't import all of the versions of a model.

That ended up being caused by something else, those versions don't include the publishedAt field in their API return for some reason, which is used to verify if a file is actually uploaded. (This is required since the API actually returns models that aren't published yet without any files)

I'll change the logic of detecting if files are actually uploaded so that they'll show up!

BlafKing commented 9 months ago

I've just published an update which includes the changes mentioned in my messages

Thanks again for reporting! :) I'll go ahead and close this bug report since it should be resolved.