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
331 stars 57 forks source link

[Bug]: #271

Closed MichaelData closed 6 months ago

MichaelData commented 7 months ago

Describe the bug.

When I click "Save HTML file for each model when updating info & tags (increases process time)."

I get this error

Traceback (most recent call last): File "C:\webui_forge_cu121_torch21\system\python\lib\site-packages\gradio\routes.py", line 488, in run_predict output = await app.get_blocks().process_api( File "C:\webui_forge_cu121_torch21\system\python\lib\site-packages\gradio\blocks.py", line 1431, in process_api result = await self.call_function( File "C:\webui_forge_cu121_torch21\system\python\lib\site-packages\gradio\blocks.py", line 1103, in call_function prediction = await anyio.to_thread.run_sync( File "C:\Users\Archive\AppData\Roaming\Python\Python310\site-packages\anyio\to_thread.py", line 33, in run_sync return await get_asynclib().run_sync_in_worker_thread( File "C:\Users\Archive\AppData\Roaming\Python\Python310\site-packages\anyio_backends_asyncio.py", line 877, in run_sync_in_worker_thread return await future File "C:\Users\Archive\AppData\Roaming\Python\Python310\site-packages\anyio_backends_asyncio.py", line 807, in run result = context.run(func, args) File "C:\webui_forge_cu121_torch21\system\python\lib\site-packages\gradio\utils.py", line 707, in wrapper response = f(args, **kwargs) File "C:\webui_forge_cu121_torch21\webui\extensions\sd-civitai-browser-plus\scripts\civitai_file_manage.py", line 1050, in file_scan save_path, name = get_save_path_and_name(install_path, file_name, api_response) File "C:\webui_forge_cu121_torch21\webui\extensions\sd-civitai-browser-plus\scripts\civitai_file_manage.py", line 814, in get_save_path_and_name sub_folder = os.path.normpath(os.path.relpath(install_path, gl.main_folder)) File "ntpath.py", line 744, in relpath ValueError: path is on mount 'D:', start on mount 'C:'

Steps to reproduce the problem.

  1. Go to CivitAI Browser+ tab
  2. Go To Update Models
  3. Check "Save HTML file for each model when updating info & tags (increases process time)."
  4. Error comes out

Expected behavior

It should update my models and give me HTML that tells it the triggers for various Loras and stuff

System info

Console logs

CivitAI Browser+: model: "Mad_Science_Lab_Coat.safetensors" not found on CivitAI servers.
CivitAI Browser+: model: "havenTrooperMGS4_v10.safetensors" not found on CivitAI servers.
CivitAI Browser+: model: "incase.safetensors" not found on CivitAI servers.
Traceback (most recent call last):
  File "C:\webui_forge_cu121_torch21\system\python\lib\site-packages\gradio\routes.py", line 488, in run_predict
    output = await app.get_blocks().process_api(
  File "C:\webui_forge_cu121_torch21\system\python\lib\site-packages\gradio\blocks.py", line 1431, in process_api
    result = await self.call_function(
  File "C:\webui_forge_cu121_torch21\system\python\lib\site-packages\gradio\blocks.py", line 1103, in call_function
    prediction = await anyio.to_thread.run_sync(
  File "C:\Users\Archive\AppData\Roaming\Python\Python310\site-packages\anyio\to_thread.py", line 33, in run_sync
    return await get_asynclib().run_sync_in_worker_thread(
  File "C:\Users\Archive\AppData\Roaming\Python\Python310\site-packages\anyio\_backends\_asyncio.py", line 877, in run_sync_in_worker_thread
    return await future
  File "C:\Users\Archive\AppData\Roaming\Python\Python310\site-packages\anyio\_backends\_asyncio.py", line 807, in run
    result = context.run(func, *args)
  File "C:\webui_forge_cu121_torch21\system\python\lib\site-packages\gradio\utils.py", line 707, in wrapper
    response = f(*args, **kwargs)
  File "C:\webui_forge_cu121_torch21\webui\extensions\sd-civitai-browser-plus\scripts\civitai_file_manage.py", line 1050, in file_scan
    save_path, name = get_save_path_and_name(install_path, file_name, api_response)
  File "C:\webui_forge_cu121_torch21\webui\extensions\sd-civitai-browser-plus\scripts\civitai_file_manage.py", line 814, in get_save_path_and_name
    sub_folder = os.path.normpath(os.path.relpath(install_path, gl.main_folder))
  File "ntpath.py", line 744, in relpath
ValueError: path is on mount 'D:', start on mount 'C:'

Additional information

I'm using Web Forge UI

Rinual commented 6 months ago

Experiencing the same, also utilizing Forge UI: Updating any of the model info is enough to result in the same. However it scanned partially one time before never letting me again. Updating the images however worked fine.

Easy workaround though depending on your setup, just installed and ran it on auto1111 then switched back to forge

BlafKing commented 6 months ago

Thanks for reporting, sorry for the delay!

From quickly skimming the error log, it looks like this occurs when the installed path of the model is on a different drive compared to where it expects a model of that content type to be located.

For example, if my stable diffusion folder is located at C:\SD\webui\models\Stable-diffusion (gl.main_folder) but the model is located at D:\Some\path\model.safetensors (install_path) then this error occurs.

The code where this happens tries to find if a sub folder is used, by comparing the main_folder with the install_path. I'm not exactly sure how this could occur, since afaik it should only look for models in the folder of the corresponding content type.

I'll try find a fitting solution, I'll presumably try to implement a different method of trying to find the sub folder.

ice-fly commented 6 months ago

Might be realted to symlinks on windows.

silveroxides commented 6 months ago

Might be realted to symlinks on windows.

Most likely yes. I had this issue before and it turns out it had something to do with not creating the link correctly so I got the Link Shell Extension and no issues since. Here is a link to Bing summarizing it.

BlafKing commented 6 months ago

Can confirm that this issue is caused by faulty symlinks, should resolve itself if you properly make a symlink!

I'll close this bug report as that should solve the issue.