The Mark of
the Beast

Done. The React table view now has an autoplayer on/off badge in the top

Original request:
show feedback in react table view of hiss.exe when the autoplayer is on or off

Result:
Done. The React table view now has an **autoplayer on/off badge** in the top-right, just below the replayer one ([index.html](laravel-react-table-display/public/index.html)):

- **Engaged** → glows **green**: `● AUTOPLAYER ON`
- **Off** → dim grey: `● AUTOPLAYER OFF`
- **Hiss unreachable** → faint `● AUTOPLAYER —`

It polls Hiss's own `/api/autoplayer` every 1.2s — a bare GET that only *reports* `{engaged}` and never toggles (so the badge can't accidentally disengage the bot). Green = engaged (distinct from the red replayer badge, so the two engagement states read at a glance).

Verified live: `GET /api/autoplayer` on Hiss's port (27655) returns `{"ok":true,"engaged":true}` — so right now the badge shows green **AUTOPLAYER ON**. Same-origin, so no CORS concerns.

Served from disk → live on next load; the table view self-refreshes every 10 min, or refresh the Hiss tab / table window now to see both badges.

Done. The React table view now shows a replayer on/off indicator in the

Original request:
show feedback in react table view of hiss.exe when the replayer is on or off

Result:
Done. The React table view now shows a **replayer on/off indicator** in the top-right corner of [index.html](laravel-react-table-display/public/index.html):

- **Playing** → glows **red**: `▶ REPLAYER · <hand#>` (red text, red border, red glow) — exactly the "highlighted red button" you asked for.
- **Off** → dim grey: `● REPLAYER OFF`.
- **Control server unreachable** → faint `● REPLAYER —` so it never looks like a false "off."

It's self-contained (no React-bundle dependency, sits beside the gametype / FCKRA / mode badges) and polls the replayer control server's `/status` at `192.168.1.137:8089` every 1.5s.

Verified:
- That exact URL returns `200` with `Access-Control-Allow-Origin: *`, so the table view's cross-origin poll works (currently `playing:false` → badge shows dim OFF; when `replayer.exe` plays it flips red with the hand number).
- Markup + script wired in.

It's served from disk, so it's live on the next load — the table view self-refreshes every 10 min, or just refresh the Hiss tab / table window now to see it.

Done — "Play in Replayer.exe" is verified working on the local advance

Original request:
ther replayer.exe isnt playing anything and the play button remains at the first frame when i hit play with play in replayer.exe enabled.    local version

Result:
Done — "Play in Replayer.exe" is verified working on the local advanced replay (played all 28 frames end-to-end). The seq-monotonic fix is in the autostarting control server, so it'll keep working across reboots, and I recorded the gotcha in case it ever regresses. Let me know if you want the browser scrubber to mirror the desktop playback so the Play button doesn't look frozen.

"Play in Replayer.exe" now works correctly on both advanced-replay syste

Original request:
make sure play in replayer.exe work on both local and server advanced replay system

Result:
"Play in Replayer.exe" now works correctly on **both** advanced-replay systems. Here's what I found and fixed.

## The bug
The control server (`replayer_control_server.py` on BEAST :8089) was **hard-wired to pull frames from swiftsnake** (`REPLAY_BASE = http://192.168.1.39`, `Host: hiss.scarletbeast.com`). So:
- **Server UI** (swiftsnake `replay.html`) → worked, because its store *is* swiftsnake.
- **Local UI** (`:8090` all-frames store) → the checkbox hit the same control server, which ignored the local store and reached out to swiftsnake — where frames are deduped or may not have shipped yet, so it played the wrong frames or nothing.

## The fix — each UI tells the control server which store to read
- **`replayer_control_server.py`**: `/play` now accepts `src` (frame-source base) and optional `host` (vhost header), threaded through `replay_get → hand_to_bmp / hands_by_time → play_loop`. No `src` → legacy swiftsnake default, so nothing else breaks. `src` is echoed in `/play` and `/status`.
- **Local [beast_replay.html](mcp/beast_replay.html)**: passes `src=http://127.0.0.1:8090&host=` → control server (also on BEAST) pulls the **local all-frames** store.
- **Server `replay.html`** (deployed to swiftsnake): passes `src=http://192.168.1.39&host=hiss.scarletbeast.com` → pulls the **swiftsnake** store (same as before, now explicit).

## Verified end-to-end
- Control server: syntax-checked, restarted **detached** (PID 7540), `/status` returns the new `src` field. CORS open, binds `0.0.0.0` (LAN-reachable).
- `replayer.exe` present (`Release/replayer.exe`); autostart Run key intact.
- Ran the control server's actual fetch+convert path against **both** stores for hand 2764366269 → **28 BMP frames each, "BOTH OK"** (without launching `replayer.exe` on your screen).

One inherent caveat worth knowing: the checkbox only works from a **LAN browser** — it fetches `192.168.1.137:8089`, a private IP, so it can't reach the control server when the server UI is opened remotely via Cloudflare. That's unavoidable since `replayer.exe` is a desktop app on BEAST. Also, the local `:8090` server must be running (the Advanced Replayer (Local) toolbar button starts it).

I dug into the actual data and the writer's code. Here's what really hap

Original request:
why does the hand history say i collected money if i lost all my money for hand number 2764366269

Result:
I dug into the actual data and the writer's code. Here's what really happened on hand **2764366269** and why the history is wrong.

## What actually happened
You're `christianbeast` (Seat 4), dealt **4h4d**. You limped a multiway pot, the flop came **5s 3s 6s** (monotone). Your 44 = bottom pair + an open-ended straight draw, and the OHF read that as a combo draw (`f$HaveComboDraw = 1`) and **called Tashar1215's all-in shove** (the decision row: `action: f$call`, `AmountToCall 5.73`). The turn bricked (**Th**), it went to showdown off-screen, and you lost.

## Why the history says you "collected"
The hand-history writer **cannot read showdown results on the scrcpy/phone table** — it can't see opponents' hole cards or who actually won. So it infers the winner two ways, and both failed you here:

1. **Showdown path** ([CHandHistoryWriter.cpp:543](Hiss/CHandHistoryWriter.cpp#L543)) only fires *at the river with opponents' cards visible*. This all-in resolved on the **turn**, so this path never ran.

2. **Uncontested-win path** ([CHandHistoryWriter.cpp:529](Hiss/CHandHistoryWriter.cpp#L529)) fires when exactly one seat is still detected as "playing" (`nplayersplaying == 1`) — i.e., everyone else folded. As the hand ended and the table cleared, the **opponents' card graphics vanished from the scrape a beat before yours did**, so for one sample only your seat was still "holding cards." The writer crowned that seat:
   ```
   christianbeast collected 103.29 from pot
   _hand_decided = true;   // frozen as the terminal result
   ```

That same card-clearing is why the narrative is garbled: at [line 436](Hiss/CHandHistoryWriter.cpp#L436) a seat that's no longer "playing" and isn't flagged all-in gets logged as a fold — so Tashar (who was actually **all-in**, not folded) and givdamoney got written as *"folds"* on the turn, manufacturing a fake "everyone folded to you" story. The bloated **103.29 pot** is a secondary OCR symptom (`_final_pot` keeps the largest pot ever scraped — [line 514](Hiss/CHandHistoryWriter.cpp#L514) — and a bad end-of-hand read inflated it).

**In one line:** you didn't win — the writer guessed the winner from "who still has cards on screen," and at hand-end your cards lingered a frame longer than the opponents', so its uncontested-win heuristic falsely crowned you.

## The fix I'd make
The reliable ground truth on these tables is the **stack delta**: a real collector's stack goes *up*; yours went to ~0. I'd gate the uncontested-win block so it won't crown a seat whose stack **dropped/busted** at hand-end, and treat "a called all-in reached showdown" as *contested* (decide by stack change, not card-presence). That stops a busted hero from ever being recorded as collecting — which also matters because these histories feed PT4 and the training data.

Want me to implement that guard?

Both fixed. Here's what was causing it and what I changed:

Original request:
can you do something about the flickering on advanced replay on local and server when its playing?

Result:
Both fixed. Here's what was causing it and what I changed:

**Root cause:** Both UIs rendered the frame as `<img key={imgSrc}>`. Changing a React `key` every frame forces React to *unmount the old `<img>` and mount a fresh blank one*. The new element starts empty against the black `.frameimg` background and stays black until the new PNG fetches and decodes — so playback flashed black on every single frame.

**Fix (applied to both [mcp/beast_replay.html](mcp/beast_replay.html) local and the swiftsnake `replay.html`):**
1. **Double-buffering** — a new `ReplayImage` component loads each frame *off-screen* via `new Image()` and only swaps the visible `<img>` once it has fully decoded. The previous frame stays on screen until the next is ready, so there's no blank/black flash. (A load error now *holds the last good frame* instead of blanking.)
2. **No more remounting** — one persistent `<img>` element, just its `src` changes.
3. **Next-frame preloading** — warms the cache 1–2 frames ahead so each swap is an instant cache hit, keeping playback smooth even at fast cadence.

**Deployment:**
- **Local (:8090):** `beast_replay_server.py` reads `beast_replay.html` from disk on every request, so it's live now — just refresh the page (or reopen via the Advanced Replayer (Local) button). No server restart needed.
- **Server:** deployed to `/mnt/www/hiss.scarletbeast.com/public/replay.html` (chowned back to `www-data`), verified 2 `ReplayImage` refs and 0 leftover `key={imgSrc}`. Refresh `192.168.1.39/replay.html` to pick it up.

Note this only affects the **in-browser** player. The "Play in Replayer.exe" desktop path renders frames in `replayer.exe` separately and isn't touched by this.