batocera-tuninglisted

# Batocera Tuning Performance: why the frontend or a game runs slow, and how to fix it. Assumes the connection pattern and `batocera.conf` model from `batocera-ops`. The theme throughout: **diagnose the machine state before blaming config, themes, or gamelists.** Most "it got slow" reports are a throttle or a leak, not the thing the user suspects. ## Diagnostic order for "the frontend is slow" Work down this list; each step is one command and rules out a whole class: 1. **CPU governor.** A frontend that is laggy *from cold boot* and stays laggy through a reboot is almost always the CPU stuck in `powersave`: ```bash SSHB "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" ``` If it says `powersave` despite `system.cpu.governor=performance`, see the governor fix below. This is step 1 because it's the most common cause and the cheapest check. 2. **ES event hooks.** Lag that gets *progressively worse* as you navigate, and is cured only by an ES restart, points at a slow/leaky ES event hook. ES runs every executable in its scripts dirs on menu events — a `system-selected` hook fires on **every carousel tile change** and can add permanent per-frame cost. Audit `/userdata/system/scripts/` and `/userdata/system/configs/emulationstation/scripts/`. Because hooks are global (not theme-scoped), this masquerades as a "theme-independent ES bug" — the tell is that it accumulates per tile visited. See below. 3. **Texture cache.** Lag that