[Bug] OS-level TTS can time out without recovery

[fpqc]

I use an android OS level replacement for the built-in TTS called TTS-Server-Android with a custom plugin that hooks into Bing Translate's API to generate TTS, and sometimes it times out. In Google Play Books and Moonreader, if the request times out, (I think this is how it works) the reader application will request the chunk again until it eventually gives up retrying after a certain number of attempts and moves on to the next chunk.

Right now, if the OS-level TTS is used in Episteme and the request fails, Episteme seems to just hang indefinitely.

here are my config files if you want to test it

ttsrv-list.json

ttsrv-plugin-微软翻译.json

[fpqc]

I had gemini analyze the bug and the project, and it suggested that in BaseTtsSynthesizer.kt the catch block of the SynthesizeToFile method should be updated to

} catch (e: Exception) {
                    Timber.w("BaseTts: Failure on attempt $attempt. Reason: ${e.message}")

                    tempFile.delete()
                    requests.remove(utteranceId)

                    if (attempt < MAX_RETRY_ATTEMPTS) {
                        // FIX: Just stop the broken utterance instead of tearing down the engine binder
                        try {
                            tts?.stop()
                        } catch (stopEx: Exception) {
                            Timber.e(stopEx, "BaseTts: Failed to stop TTS during recovery loop")
                        }
                        
                        // Force an engine reset flag if it's a persistent crash, 
                        // but don't call blocking shutdown() inside the active lock.
                        delay(500) 
                    }
                }

but I'm not a programmer so who knows if that is the issue. It says using shutdown instead of stop is creating a deadlock.

[Aryan-Raj3112]

see if this still happens in the new version

[fpqc]

Now it is silently skipping stuff. I'm not sure if the problem is in the timeout code or somewhere else.

If it is in the timeout code, it is skipping anything that takes slightly too long and completely failing to retry.

see 0:17 and 0:19 in this screen recording. I included the relevant logs from with tts-server-android

screen-20260620-111157-1781968288342.mp4

[Aryan-Raj3112]

try the new version

[Aryan-Raj3112]

if the new version doesn't work then try this: https://drive.google.com/file/d/17PGZDvZ6HM53KRAJtzC2jlyXYb94DtXU/view?usp=sharing

[fpqc]

the google drive version seems to be working perfectly now (I had it run for maybe 2 minutes with no skips), but the version on the play store is still broken. sorry for taking so long to get back to you

Edit: Tested for 30 minutes now in both continuous and paginated modes. zero glitches

[Aryan-Raj3112]

thanks for testing, this will be part of the next update

[fpqc]

Kinda curious what the source of the bug was. I tried reading some of the code and this is what it seems like you did:

My guess is that files were being added to the exoplayer playlist, and if they were incomplete or locked due to the engine still holding a writing handle, locking them from being read, exoplayer would fail to read them and immediately exhaust the retries and skip, so basically a time to write vs time of read race condition.

Is that how it works or am I misunderstanding the commit?

[Aryan-Raj3112]

TTS chunks are generated without any order so a later chunk might be ready and added to exoplayer even if the present chunk is missing or invalid. so if exoplayer experienced a gap it skipped the chunk for that later chunk. so the fix was to only add the chunk to exoplayer if its predecessor was present. also the timeout is now progress aware and not just hardcoded time because external engines takes longer to produce audio

[fpqc]

Ahhh, that makes sense. Thanks!

[Aryan-Raj3112]

try the new version