# Estado OCR Sri Caitanya-caritāmṛta (Surya) — handoff

Última actualización: 2026-07-15 ~13:00

## Qué corre (procesos independientes del chat, con nohup+caffeinate)
- `cc_guardian.sh` bajo `caffeinate -i` → supervisa y relanza el worker; sale al 100%.
- `surya_full.py --book sri-caitanya-caritamrta` → el OCR real.
- `llama-server` (hijo del worker) → sirve el modelo Surya OCR 2.

## Estado
- ~5600 / 7659 páginas (~73%), en `mad5`. Ritmo ~0.8 pág/min. ETA ~2 días.

## El fix clave (ya aplicado en surya_full.py)
Las páginas con verso BENGALÍ (todo Madhya/Antya-līlā) hacían BUCLE en modo
full-page (~10 min → timeout → página vacía). Solución:
1. `SURYA_GUIDED_LAYOUT=false` (el layout guiado por JSON-schema rompe con
   llama.cpp → "400 failed to parse grammar").
2. Modo POR BLOQUES (`full_page=False`, layout→OCR por bloque): cada bloque
   tiene presupuesto de tokens acotado → el bengalí no se dispara. ~50s/pág.
Guardián con watchdog: si no avanza en 900s mata worker+servidor y relanza
(pasó 1 vez tras 22h de uptime; auto-recuperado). Concurrencia = 1 página a la
vez (el threading multipágina colgaba el servidor; el modo-bloque ya paraleliza
sus bloques por los slots).

## Monitorizar
```bash
cd scripts/scan_audit
find surya/sri-caitanya-caritamrta -name '*.surya.txt' | wc -l      # hechas /7659
tail -f surya/cc_run.log                                            # log worker vivo
tail surya/cc_guardian.log                                          # reinicios/atascos
```

## Si hay que relanzar a mano
```bash
cd scripts/scan_audit
caffeinate -i nohup bash cc_guardian.sh >/dev/null 2>&1 &
```

## CERRADO (2026-07-29) — los 0-byte NO eran cuelgues
CC está terminado: 7659/7659 páginas, 7556 con texto, 103 en 0 bytes.

**Se comprobó borrando los 103 y re-lanzando el guardian: vuelven a salir
vacías. No son cuelgues del full-page — están vacías porque no hay texto que
sacar.** Clasificación de las 103:

| qué son | nº | ¿0 bytes correcto? |
|---|---|---|
| láminas en color (págs. ~13–33 de cada volumen) | 99 | sí |
| páginas en blanco (mad2/173, mad9/528) | 2 | sí |
| índice de versos sánscritos a 4 columnas (mad3/438, mad9/510) | 2 | **no** — fallo real |

Solo 2 páginas fallan de verdad, y son índice alfabético de primeras líneas
(no texto de Prabhupāda) → irrelevantes para el diff/auditoría. **NO volver a
borrar los 0-byte y relanzar: es ~1h20m de GPU para reescribir 101 ficheros
vacíos que ya eran correctos.**

Si algún día se quieren esas 2 páginas de índice, no sirve el modo bloque tal
cual: el layout a 4 columnas densas devuelve 0 bloques con texto.

## OJO — "COMPLETO" en los guardianes cuenta FICHEROS, no texto
`cc_guardian.sh` / `bg_guardian.sh` deciden el fin con
`find … -name '*.surya.txt' | wc -l`, y `surya_full.py` escribe el fichero
igual cuando la página falla (`outf.write_text("")`, líneas 139 y 148). Una
página fallida cuenta como hecha y en la siguiente pasada se salta por el
`if outf.exists()`. Para verificar de verdad:
```bash
find surya/<libro> -name '*.surya.txt' ! -size 0 | wc -l   # las que TIENEN texto
```

## Backups del código
- `surya_full.py.bak` = versión original de 1 página (full-page, sin fix).
- `surya_full.py.threaded` = experimento multipágina (colgaba; NO usar).