Spaces:

Duplicated from  TTS-AGI/TTS-Arena

Pendrokar

/

TTS-Spaces-Arena

like 105

Running

Wish I could give you clarification.

For Zero-GPU spaces it is most often the running out of computing units. For the coqui Space, it is 429 TooManyRequests error, hidden in a Gradio fatal error: [edit] PR merged
https://github.com/gradio-app/gradio/issues/9683

Strangest part is that even after some times passes, even a rarely used Space still gives the 429.

It could be because I contact two Spaces too fast. I'll try to add a few second delay between the two requests. Here:
https://huggingface.co/spaces/Pendrokar/TTS-Spaces-Arena/blob/main/app.py#L1100-L1104

Though every restart clears the cached audio pairs, making it worse for visitors.

It could be because I contact two Spaces too fast. I'll try to add a few second delay between the two requests.

Yeah, no dice. Even with a 5 second delay, it seems to still hit some multi-request limit.

fishaudio/fish-speech-1 coqui/xtts
Sending models fishaudio/fish-speech-1 and coqui/xtts to API
Loaded as API: https://fishaudio-fish-speech-1.hf.space ✔
fishaudio/fish-speech-1: Default inputs overridden by Arena
fishaudio/fish-speech-1: Sending request to HF Space
Loaded as API: https://coqui-xtts.hf.space ✔
AttributeError("'Client' object has no attribute 'src_prefixed'")
coqui/xtts: Unable to call API (attempt: 1)
Done with fishaudio/fish-speech-1

Fish Speech did not finish within a 5 second timeframe and HF blocked the request to XTTS.

The only safe method may be to not use multi-threading => longer wait time for visitors, but at least less failures.

Hell even when doing them one-by-one the issue may pop-up. Once I merge #11 then I can just not use multithreading and instead rely on Gradio contacting the spaces, as this would allow a user to listen to one model while the other is being prepared. #2

Multithreading disabled, stability increased with increased processing time sacrifice.

@cfahlgren1 a new stern message received from the coqui/xTTS Space:
We had to rate limit you. If you think it's an error, send us an email.

As an HF Staff member. If you have suggestions, I would gladly hear them out.

There is also the fact that I've increased the likelihood of xTTS being picked.
https://huggingface.co/posts/Pendrokar/552560958530464

Hmm, it looks like the gradio issue was fixed. I am not super familiar with the internals of gradios but I would ask @abidlabs

Upgraded Gradio, at least now the error message is more clear. I also switched the HF token, maybe now it will be blacklisted less.

Lately most spaces give the TooManyRequests at earlier intervals than before.

I'm getting frustrated. It might not be such a big deal if I started to save the cached samples to a synthetic dataset and just use that for cached samples.

Hey Pendrokar! This may be because unauthenticated Hub API rate limits has been lowered a bit.
If you are calling spaces that are performing unauthenticated requests frequently, it could be one of the reasons why you get 429s (if I am understanding everything correctly).

@cfahlgren1 well yes, the only authentication happens with my own HF TOKEN. No HF user authentication.
https://huggingface.co/spaces/Pendrokar/TTS-Spaces-Arena/blob/main/app.py#L1114-L1130

Other than attaching the X-IP-Token which, if I read correctly, helps with ZeroGPU spaces.