Failed to export after complete render with kokoro

[artaeun]

Describe the bug
Failed to export file after rendering audio with kokoro-fastapi

Environment info:

• OpenReader-WebUI version: v0.2.9
• Using Docker: yes
• Browser: Firefox
• Device: AMD PC

No actual error, just "name-file undefined" but it choose it himself and had no errors from kokoro.
Kokoro actually gave no errors whatsoever as per screen.

Screenshots

[richardr1126]

What do u mean "it choose it himself"?

[artaeun]

What do u mean "it choose it himself"?

I'm just doing guess work here since i don't know the code base, but what I meant is that the error seems to refer to the filename not being valid (1st screenshot, being the output in docker), while the output file has a standard name chosen by the app itself. I realize i might have caused confusion, I apologize.

Any information on the issue I can further provide to debug the problem?

[richardr1126]

Your problem is definitely new to me. The output filename is a default and shouldn't cause issues.

You have to wait sometime after the progress reaches 100%, depending on the length of the audio.

Issues could arise due to the length or maybe the version of Kokoro you are using. But it's been working for me.

[artaeun]

I left the terminals open for 20 minutes after the render. The render took 1 hour and 54 minutes. As you can see from the second screen, kokoro reported no error, while OpenReader did fin am_michael 1 mp3 undefined. Have you tried rendering larger epubs by any chance, and see if you can reproduce the problem?
What version of kokoro are you using? maybe I can have it work better with the same specific version you are using. I would not like to try and fail such long renders.

[jcshelly66]

I also had this happen as well. I ran a large epub for about an hour and it hit 100% then the UI reset without the option to download. Is there a location within the docker file system where I could track the file down if it is presistiant?

[richardr1126]

You can check the /app/temp directory in the docker container. But files might have been cleaned up.

The raw files are labeled {chapterIndex}-input.aac. And the converted chapter in WAV are {chapterIndex}.wav.

If it made it all the way to the stitching then it would be under {bookId}.m4b

I'll try to do some testing to find what's going wrong. But I think it's just the downloading of the final .m4b from the UI which is causing issues when they are too large (this is why blob storage exists). Currently I am streaming the raw bytes of the m4b back to the UI.