v1.8.1 — Drop Tesseract, single 16-digit reply
Fix v1.8.0's keypad OCR failure
v1.8.0 used Tesseract to read the 10 clean keypad button PNGs and
build the letter→digit mapping automatically, asking the user for
just the 6 captcha digits. Production results: 0/10 buttons read
successfully. Local reproduction confirmed Tesseract systemically
confuses 1 with 7 on these images (the v7.4 decorative underline
fools it), and silently returns empty on the lighter-colored ones.
No amount of preprocessing fixed it reliably.
New approach
The solver now hands the user everything they need to read in a
single composed image:
- Distorted captcha on top.
- 10 keypad button PNGs in a strip below, each labelled
1–10.
The user replies with 16 digits in one go: the 10 keypad positions
(left to right) followed by the 6 captcha digits. Example reply if
the keypad reads 8 5 2 6 7 9 3 0 1 4 and the captcha is 198142:
8526793014198142
The solver maps captcha digits → keypad letters using the order the
user provided and returns the 6-letter click sequence to
CheckJCClient. From there it's the same as before: re-read DOM, click
each letter's current position, submit.
Why this is better than v1.8.0's OCR
- 100% reliable for the cases v1.8.0 broke.
- Zero new dependencies (Tesseract gone, image is smaller).
- Same
CaptchaSolver.solve()contract, so anLLMVisionSolver
plugged in later reads the same 16 digits from the same composite
image we already build for the human.
Trade-off: the user types 10 extra digits per fichaje (still 30
seconds total). The composite image's 1..10 labels make it obvious.
Files
- Dropped
keypad_reader.py,pytesseract,tesseract-ocr. - Kept
Pillowfor the image composition. - Bot listener now expects 16-digit replies.
pending_captcha.responsewidened toVARCHAR(32)(auto-migration
on startup).
Image
ghcr.io/gonzalez8/checktime:1.8.1 / :1.8 / :latest
Upgrade
sed -i 's/^CHECK_TIME_VERSION=.*/CHECK_TIME_VERSION=1.8.1/' stack.env
docker compose pull app
docker compose up -d appSchema migration is automatic. No new env vars.