Upload epub failed and LLM checking indicator never changing

[fariddesu]

I try upload the epub, but nothing change, and the LLM checking indicatore never changing the state, even though i've already installed the ai models

[hydropix]

Hi @fariddesu, thanks for the report.

The server side looks healthy — your startup log shows Ollama connected! Found 2 model(s), so Ollama is reachable. The "LLM: Checking..." indicator stays stuck because the browser never finishes its initialization, which also explains why the EPUB upload doesn't react (same init step wires both).

A few things to try:

1. Hard reload the page with Ctrl+Shift+R (or Cmd+Shift+R on Mac).
2. Confirm the URL you're opening — it must be http://127.0.0.1:5000 or http://localhost:5000 from the same machine running the server (it doesn't bind to your network).
3. Try a different browser (Chrome/Firefox latest) to rule out a browser-specific issue.
4. Clear the site's storage: in your browser, open settings → "Clear browsing data" for localhost, then reload.

If none of that works, could you open DevTools (press F12), click the Console tab, reload the page, and screenshot anything in red? That will tell us exactly what's failing.

Side note: the upload area mentions DOCX, but only .txt, .epub, and .srt are actually supported — we'll fix that label.

[hydropix]

Hi @fariddesu — I managed to reproduce this and pushed a fix in c5ec9b4.

Root cause: in initializeModules() (index.js), WebSocketManager.connect() was called before wireModuleEvents(), with an await TranslationTracker.initialize() in between. Two cascading bugs:

1. Race: the socket connected during the await and emitted connect before its handler was registered, so the post-connect refresh (provider models, file list, resumable jobs) was silently dropped → "LLM: Checking..." stayed stuck.
2. Hang: a slow /api/health or /api/translations froze the whole init, so wireModuleEvents() and LifecycleManager.initialize() never ran → upload area + buttons unresponsive.

Fix: all event wiring now runs synchronously before the WebSocket opens, and TranslationTracker.initialize() runs in the background (no await) so a slow server can't freeze the UI.

Could you git pull and confirm the indicator switches to "Connected" and the upload reacts on your machine?

[fariddesu]

Thanks for the reply, i did the pull and try other browser (Edge, Brave) currently im using Chrome, and yeah it's still not worked.
Btw, do the debug mode error? i've changed the DEBUGMODE = true, but nothing changed when i restart the runtime,

[fariddesu]

This error is show up when i'm trying to upload the epub

[hydropix]

@fariddesu thanks for posting the screenshots — they pointed straight at the real cause, and it wasn't the race I fixed earlier. Pushed a follow-up in f90532a (released as v1.2.2).

Root cause: look at the first console error in your screenshot:

Failed to load module script: Expected a JavaScript-or-Wasm module script but the server responded with a MIME type of text/plain. Strict MIME type checking is enforced for module scripts per HTML spec.

index.js is loaded as <script type="module">, and browsers refuse to execute module scripts unless the server sends a JS MIME type. Your Flask server was sending text/plain for .js, so the entire module never ran — that's why handleFileSelect was undefined and why the upload area didn't react.

This is a Windows-specific issue: Python's mimetypes module reads from HKCR\.js\Content Type in the registry, and on some Windows machines that key has been overwritten to text/plain (commonly by IIS, certain antivirus / EDR products, or other software). Nothing you did wrong — Brave/Edge/Chrome all enforce the same strict MIME check, which is why switching browsers didn't help.

Fix: force-register the correct MIME types at server startup (in translation_api.py), before Flask serves anything. mimetypes.add_type() overrides the registry, so the browser now receives text/javascript regardless of the registry state.

Could you git pull, restart the server, and confirm the UI loads? You should see "LLM: Connected" and the upload should respond.

[fariddesu]

Thx for the reply, i did the pull, and the error still showed up, but, i've download the executable [v1.2.2] instead (https://github.com/hydropix/TranslateBooksWithLLMs/releases/tag/v1.2.2) and right now it's fixed.

[hydropix]

Glad the .exe works — it's built from the same translation_api.py, so the fix is correct. Two things to check on your source clone:

1. Confirm the fix is in your local file: git log --oneline -1 -- translation_api.py should show f90532a. If not, your pull didn't bring it in (local edits, wrong branch, or out-of-sync fork).
2. Restart the Python server after pulling. The .exe is a fresh process, which is why it picked up the fix automatically — a still-running python translation_api.py keeps the old code in memory.

I also pushed a small hardening (moved mimetypes.add_type() above the Flask import) — pull again to get it.

[hydropix]

There were two separate problems behind this and both are fixed.

The "checking LLM" indicator that never changed was a startup ordering bug in the web UI. Fixed in v1.0.27.

The EPUB upload failure was Windows serving .js files with the wrong content type. Some installs have that mapping changed in the registry, and the browser then refuses to load the app's scripts. TBL now forces the correct types at startup. Fixed in v1.2.2.

Closing as resolved. If an upload still fails for you on a recent version, please open a new issue with the browser console output, because it would be a different cause.