show: savePrefs playlist blob on short-lived heap

[SimonePDA]

Summary

• savePrefs() builds the comma-joined playlist string in a malloc/free buffer (~2.5 KB) instead of on the loop-task stack.
• No FatFS mutex (dropped after review).

Why

A full 64-slug list on the stack is a plausible hang/stack-pressure source. Permanent static would cost Performance DRAM permanently; tree rule is no static buffers over 1 KB.

Test plan

• Save/load a long playlist (up to 64 slugs)
• Sequence mode prefs still restore across reboot
• Performance / default builds stay within footprint pin (no DRAM re-pin)

Contributed by @SimonePDA

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
pattern-flow_origin	Building	Preview	Sep 24, 2026 4:25am UTC
pattern-flow-open	Ready	Preview	Sep 24, 2026 4:25am UTC

[engmung]

Thanks for this one. I'm holding it for now: as written the lock can't do anything, and I'd rather find what actually hung.

• loadFile() is the only place that takes PFFfat::Guard, and every path to it and to savePrefs() already runs on the loop task. /api/shows/control, /schedule and /delete all go through PFLoopSync::run. Nothing on Core 0 takes the lock: /api/status's totalBytes(), the library and uploads all skip it. So the lock never has anything to wait for. TryGuard isn't used anywhere.
• ESP-IDF already builds FatFS with FF_FS_REENTRANT 1. FatFS itself serializes calls on the same volume from both cores; a waiter times out after CONFIG_FATFS_TIMEOUT_MS instead of corrupting anything.
• If the hang went away with this change, I suspect the other half is what fixed it: savePrefs()'s 2.5 KB blob sitting on the loop task's stack. That part is worth keeping, but as a short-lived heap buffer (malloc/free, or PFMem) rather than static. A static costs Performance 2.8 KB of DRAM for good. The tree's rule is no static buffers over 1 KB, because one of them broke console page delivery in August.

Could you send the serial log from a hang, with any panic, backtrace or watchdog line, and say what was running at the time? Then we can fix the actual cause. I'm happy to take a trimmed PR with just the savePrefs() change.

[SimonePDA]

Thanks — agreed on all three points.

Trimmed this PR to just the savePrefs() change: short-lived malloc/free for the ~2.5 KB playlist blob (not static). Removed core_ffat_lock.h and the loadFile guard.

I don't have a clean serial capture of the original hang handy; if it shows up again I'll grab panic/backtrace + what was running and open a follow-up. Happy for you to take this trimmed form.