Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug]: Model database remains stale #6117

Open
1 task done
blessedcoolant opened this issue Apr 3, 2024 · 1 comment · May be fixed by #6122
Open
1 task done

[bug]: Model database remains stale #6117

blessedcoolant opened this issue Apr 3, 2024 · 1 comment · May be fixed by #6122
Assignees
Labels
bug Something isn't working

Comments

@blessedcoolant
Copy link
Collaborator

Is there an existing issue for this problem?

  • I have searched the existing issues

Operating system

Windows

GPU vendor

Nvidia (CUDA)

GPU model

RTX 4090

GPU VRAM

24GB

Version number

main

Browser

Chrome / Firefox

Python dependencies

No response

What happened

When a user moves model files to another folder, the model database continues to remain stale.

Here's the example scenario:

  1. Let's say I add a bunch of LoRA's in a folder C:/models/loras which has a bunch of safetensors files.
  2. I boot up Invoke and the client recognizes these new models and registers them to the database and the client.
  3. Now let's say I do some local file management and now instead moved these LoRA's to C:/models/loras/styles
  4. When I boot up Invoke next, the ModelInstallerService as expected, reports that the LoRA's registered are now missing from their location.

Here's where the problems begin:

  1. The Model Manager UI does not reflect these missing models in anyway. So it is not possible to tell at a glance from the UI which of the models files are not there. This needs to be referred to from the console. The Model Manager should mark this.
  2. There doesn't seem to be a way from the Model Manager UI to update these paths to a new path. So it basically becomes a dead entry.
  3. If you notice, the new path of these LoRA files are also in the same folder hierarchy where they should be recognized automatically by Invoke. But they do not register the new paths because the files share the same names as those existing in the database already. If the file names are same, then maybe we should update these paths automatically? This could be a problem for Diffusers sub models which have the same names but should not be an issue for checkpoint paths maybe? Because Diffusers are detected by the folder name in most cases.

What you expected to happen

  • The Model Manager UI should visually indicate the missing model files somehow
  • The Model Manager UI should have an option to update these paths either manually or automatically.
  • The ModelInstallerService should probably override the database entry with the new path if the model with the same name is detected under the same folder hierarchy.

How to reproduce the problem

No response

Additional context

No response

Discord username

No response

@blessedcoolant blessedcoolant added the bug Something isn't working label Apr 3, 2024
psychedelicious added a commit that referenced this issue Apr 3, 2024
Check if the model file exists. If not, omit it from the list of models.

Closes #6117
@psychedelicious psychedelicious linked a pull request Apr 3, 2024 that will close this issue
3 tasks
@psychedelicious
Copy link
Collaborator

The short answer is you aren't allowed to move models around in the models dir. That's an application-managed directory

#6122 hides the missing models from the API response

A more involved but maybe better UX would be to extend the model config class w/ a flag indicating if the model is physically present or not. This would alos require UI changes to communicate that the model is missing.

Omitting the model entirely seems like a good compromise to me. It encourages the user to look at the terminal to see what's wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants
@lstein @psychedelicious @blessedcoolant and others