From 171a3e175889ce30f201fcdf5c4632f480344ae6 Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Sat, 19 Sep 2026 17:42:11 +0200 Subject: fix(node): the Music app's tags survive a restart MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit media_cache held video_meta, photo_meta and thumbs; the audio tags lived only in the in-memory IndexEntry. So every start re-read every audio file the node serves, and until that pass landed it served an index with no artist on any track — one the Music app cannot group. Over a real 6176-file library the pass costs 27.8s cold and 6.4s from audio_meta. Only what the bytes decided is stored. The filename and folder fallbacks still run live, or a renamed file would get the old name's answer; the sibling-cover scan reads the folder, so it stays live too; and a read that failed is not cached, or one bad read becomes permanent. Co-Authored-By: Claude Opus 5 --- CLAUDE.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'CLAUDE.md') diff --git a/CLAUDE.md b/CLAUDE.md index 694f7b2..5463437 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -493,6 +493,24 @@ do. Read them before writing anything that touches the same mechanism. viewport from the layout one), which was plausible, cost a round trip, and was wrong; the screenshot showing no keyboard was already in hand. +- **Derived data that nothing persists is re-derived where somebody is + watching.** `video_meta`, `photo_meta` and `thumbs` were durable; the audio + tags were not, so every node start re-read every audio file it serves and, + until that pass landed, served an index with no artist on any track — an + index the Music app cannot group. Nobody noticed for months because the + re-read is cheap and the node is usually up. `media_cache.audio_meta` holds + it now: the pass over a real 6176-file library costs 27.8s cold and 6.4s + cached. **What goes in such a cache is what the file's bytes decided, never + the field as the app finally sees it** — `display_title`, `track_no`, artist + and album can also come from the filename and the folder, and a rename has to + re-derive those; storing the resolved field would hand a renamed file the old + name's answer, which is the fault `_reenrich_renamed_audio_entries` exists to + prevent. The sibling-cover scan stays live for the mirror-image reason: it + reads the *folder*, so caching "no cover" would make a cover dropped in + afterwards unfindable. And a read that *failed* is not an answer — caching + "this file says nothing" for a drive that did not respond makes one bad read + permanent + - **A view that draws one shape of unit, beside an emptiness test that counts every shape.** The Music grid's unit is an album; a track whose artist tag is empty belongs to none, so it was drawn nowhere — while `empty` counted it and -- cgit v1.2.3