Downloading models and stuff

[Woisek]

I would really like to use this, but the downloads are ridiculous. And even more, there is nowhere a hint on WHAT it downloads and to WHERE it is saved.
Downloading several GB of files, there is often the chance that downloads get aborted or are failures due connection problems. And we don't have any chance to do a manual download because of the above mentioned missing information.
It would be HIGHLY recommended to display that in the console.

Like:
Download xyz_file.ext
from http://whateversite.com
saving to
X:/given/save/directory

That would help a lot.

[rsxdalv]

We can suggest this to huggingface since their code does the downloads. Many of the recent models have this automatic downloading baked in. It's stored in caches, so multiple projects or installations can use the same ones.
As for the ridiculousness, well, AI really is a "silicon valley" type of deal where anything less than a gigabit internet is "slow" unfortunately.
In terms of better communication, I'd like to switch away from gradio, it's caused me quite the grief, and then I could add a much richer UX with warnings such as - using bark for the first time will download 4-8gb of model weights. But as things are, gradio is a pain and the project is already a bit hard to maintain.

[Woisek]

Yes, this would be a great improvement I think. Thanks for considering it and look into it. 👍

[rsxdalv]

Created this topic for the huggingface hub project: huggingface/huggingface_hub#1747

[pngwn]

Hey, I'm a gradio maintainer and I'd love to know specifically what is causing you pain. I'm not going to try to convince you to stick with gradio but I'd love to understand what isn't working for you so we can improve!

Thanks!

[Wauplin]

Hello, maintainer of huggingface_hub here. I feel that there a several topics in this convo. Let me answer a few:

It would be nice to have a central management to where those huge binaries are saved. Storing all on C drive is the dumbest I can think of. I know how I can junction this away, but probably not the average user.

I would advice you to read this guide about cache management when downloading files using huggingface_hub (so when using tts-generation-webui but not only). In particular, cache location can be configured using HF_HOME or HUGGINGFACE_HUB_CACHE environment variables.

In terms of better communication, I'd like to switch away from gradio, it's caused me quite the grief, and then I could add a much richer UX with warnings such as - using bark for the first time will download 4-8gb of model weights.

As far as I know, you can trigger warnings in Gradio using gr.Warning. Those will be shown in the UI.

we don't have any chance to do a manual download because of the above mentioned missing information.

A possibility for manual downloads is to use huggingface-cli download which will provide you with more information on the download process. It could be good to document it in this repo README if that's something users might find useful.

Also last thing about cache in the HF environment is that you can clean it whenever you want using huggingface-cli scan-cache and huggingface-cli delete-cache (see clean your cache section).

---

I feel that most of the problem you raised is because of the fact end users are (legitimately) not aware of the existing tools in huggingface_hub and huggingface-cli. Please let me know if you think of any good way to help with discoverability. A simple option could be to simply print a few links to resources when starting tts-generation-webui.

[rsxdalv]

Hey, I'm a gradio maintainer and I'd love to know specifically what is causing you pain. I'm not going to try to convince you to stick with gradio but I'd love to understand what isn't working for you so we can improve!

Thanks!

Audio support has been poor in the UI components. Images have a gallery, audio has none such option. I had to make several workarounds to create an app that can batch generate and display a list of audio. This workaround has poor performance. Gradio UI does not allow customization, many visual improvements require "hacking" in the sense of bypassing the official API. Dataflows are similar to a full app, but it becomes painful at scale (for example, I implemented a reactive UI that is synchronized with state. I got a few I infinite loops, but even after fixing those the "reloading" after any input was the major pain). Other times I end up fighting with the files, as there's a "gradio" way of dealing with inputs. It's good for some things and is more consistent, but if I want users to select a checkpoint... It will end up copying a few gigabytes now, isn't it? But overall the API requires me to use .name and other things that require constant testing as the official documentation is mostly generated, sometimes not exactly truthful, and sometimes isn't documenting something.
I thought about just making the really necessary components, such as audio list myself but after forking the project I realized that I need to write a lot of code even if I wanted a simple feature.
So overall, gradio is a backend framework for me. It's on me for trying to push it and stretch it. I wish it was a web component library or a toolkit, but the UI is a lock in monolith. For now I will continue building a react front end on top with tooltips, rich user input forms, custom buttons and dynamic feedback.

Edit: as for this specific use case, I'd normally just have a disclaimer (using some visual library components and close to the button itself) about the download. I'd save the disclaimer is_read in a cookie and not clutter the UI for users. I could even add it as a popup after the button is pressed. In gradio I would have to add a state that is saved on disk, try to visually "style" a gr.Markdown and a button, then add a function to this button. For me, this is a big contrast in the final result and effort, especially because I could probably get ChatGPT or Copilot to generate me #1 case but not #2 case and save 30-60% of the time.

[rsxdalv]

@Wauplin thank you for your detailed answer!

Once I can access my workstation I will add it to the readme or wiki. Storage locations have affected multiple people and so there are several issues and a few discussions, so overall the information is scattered throughout this repository.

Actually I made a settings page that allows setting those exact values from within the UI. (But I'm at the point where the UI needs more documentation.)

gr.Warning almost does it, I might use it for now since it's easier to integrate. In the future I would like an advance warning or confirmation.

I'm thinking that the HuggingFace cli could be added to the UI, but I'm a little scared people with dial up internet will accidentally delete their entire cache.

[Woisek]

@Wauplin
I'm sorry to say, but your information is just like that. An information. It's surely nice that there are obviously possibilities to solve the issues mentioned here, but they don't mean nothing if they aren't implemented for the user to use.

It's nice that we have cache management, but where do I find that in the UI? Where can the average user set the directory for the cache?
I'm aware that this may be more related to the developer of the UI for his project, but I think nothing speaks against the possibility that Gradio designers implement this as a core setting that is always available, no matter what project is realized with it, that uses HF.
But then ... when I see that the Gradio developing itself is stalling somehow ... well ...

It would be nice to see more optimizations from the Gradio team itself. Every developer that uses Gradio and which I'm in contact with, groans when we talking about Gradio. I can't believe that this isn't noticed by Gradio by now.

I see so many great open source projects and every time Gradio comes into play, all gets slower and more tedious, because any new update could break the whole project. That's not a really good basis and I hope that this changes soon, for the benefit of all these volunteers who give up their free time for us users, so that we have something 'to play' with.

[dangerweenie]

I hear your concerns and understand the frustration (i'm experiencing it myself).

That said, this is a free app - it's not a production tool. There are plenty of subscription options available for tools like this, Stable Diffusion, etc, that take the work out of it for the "average" user that is not github and CLI adept. If you want organization and convenience without all the work involved in doing research and learning schemas and structures, you can pay someone for doing that work for you via a cloud service like rundiffusion etc.

[pngwn]

Gradio maintainer here.

I'm aware that this may be more related to the developer of the UI for his project, but I think nothing speaks against the possibility that Gradio designers implement this as a core setting that is always available, no matter what project is realized with it, that uses HF.

I'm not sure sure how we could do this, or how we could do it in a way that isn't disruptive. Gradio is used for a wide variety of tasks and developers ultimately have an enormous amount of flexibility over how they structure their apps and what they use them for. There i no expectation on our side that gradio users will interact with the hugging face hub and i think many users would be annoyed if we started changing huggingface_hub's defaults. This is very much the responsibility of the app developer.

But then ... when I see that the Gradio developing itself is stalling somehow ... well ...

I don't really see how this is a remotely reasonable take. On the actual day you made this comment there were 14 commits to the main branch. In the previous 30 days there were 114 commits to the main branch. In the same 30 day time period we released 9 new versions of gradio. We also released 14 pre-release versions. That is a combined 23 versions in 30 days (if you include weekends which we do not work). If that isn't active development then i don't know what is.

In the time since this comment (298 days, 215 week days), we have made almost 1200 commits to main and released ~90 new versions of gradio. That is a release every few days and over 5 commits to main every day that we work.

I'm fine with people not liking gradio but the idea that gradio development is slow or stalling in any way is absurd.