Great concept! + A few Docker/Windows bugs & an idea for multi-character casting

[jamesonBradfield]

Hey there! Just wanted to say I absolutely love the core concept of this project. A self-hosted e-reader that generates local AI audiobooks on the fly is exactly the kind of tool I've been looking for. I starred the repo and wanted to drop some notes from my deployment attempt today.

I tried spinning this up on a Windows machine using Docker Compose and ran into a few environmental bugs. Figured I'd list them here in case you (or someone who forks this) want to patch them up:

1. Kokoro Health Check Block:
   The kokoro container's internal health check fails out of the box for me, which prevents the server container from fully booting because of the depends_on: service_healthy condition. Changing it to service_started allows it to bypass the block.

2. Frontend/Backend Race Condition (502 Error):
   There is a slight race condition between Caddy, the Web frontend, and the Backend server. Caddy boots instantly, but the backend server takes 10-20 seconds to run the Prisma schema sync and actually open port 3001. Because the docker-compose.yml relies on a standard depends_on without a strict condition: service_healthy check for the server, Caddy frequently throws 502 Connection Refused errors until the backend finishes its startup sequence and the frontend is manually restarted.

3. Hardcoded TTS Endpoint:
   Currently, the backend expects a very specific Kokoro /synthesize payload. It would be awesome to eventually see this support the standard OpenAI /v1/audio/speech API format. This would allow users to easily swap out the TTS engine for other local Dockerized models (like Chatterbox, F5-TTS, or AllTalk).

Feature Idea: Screenplay Casting
I’ve had a project idea in mind that I think would fit perfectly into this architecture: Multi-voice casting.
The pipeline would use a local LLM to parse the .epub text and convert it into a "screenplay" JSON format (identifying the narrator vs. specific character dialogue). The UI could then let the user assign specific custom TTS voices to specific characters. The backend would generate the chunks and stitch them together into a full-cast radio drama!

Would love to know if you plan on continuing development on this, or if you'd be open to PRs! Thanks again for sharing the code.

Edit: clarifying the race condition, I did an attempt at making a custom server.py tonight exposing that race condition on building chatterbox-tts.

[wobblycogs]

I also love the concept here. I like it enough I'm tempted to come out of retirement and get my typescript skills back up to date.

I also had a couple of issues getting the application running. Something is going wrong with the health check for the Kokoro container. I suspected it was working even though the health check was failing so I replaced the check with:
test: ['CMD', 'wget', '-q', 'http://google.com']
The failure mentioned something about not being able to access curl, hence why I used wget. Curl is definitely available. I running on Debian stable.

The one thing I'd really change, however, is the name. While it's clever and book related is also impossible to search for a book / reading related project called "chapter".

[jamesonBradfield]

feel free to use it, I've got other things I'm working on that have my attention. No shortage of good ideas here.

[1DontEx1st]

I also couldn't find curl, so switched to wget. I didn't get much further, though, since I'm unable to register in the web UI - I get "unknown error" and nothing in the logs.