[nu-demo] hero_foundry not pointed at seed_media — Files/Videos/Photos/Songs can't stream #19

New issue

Open

opened 2026-04-28 12:20:22 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-04-28 12:20:22 +00:00

Owner

Symptom

Videos/Photos/Songs islands show metadata (titles, thumbnails placeholders) from hero_osis_media but actual playback and thumbnail fetches 404. The WebDAV under hero_foundry has no bytes to serve.

Root cause

service_foundry.nu starts foundry with:

HERO_FOUNDRY_REPOS=~/hero/var/hero_foundry/repos   # empty
--webdav-storage ~/hero/var/hero_foundry/webdav    # empty

Seed media is laid down at ~/hero/var/seed_media/{Documents,Photos,Songs,Videos} by a separate seeding step (hero_books or equivalent), but nothing connects that tree to the foundry WebDAV roots. Foundry therefore has nothing to serve.

Demo workaround (applied 2026-04-23)

For each context (root, default, geomind, incubaid, threefold):

cp -r ~/hero/var/seed_media ~/hero/var/hero_foundry/webdav/<context>/

After that, playback and thumbnails resolved.

Proper fix

Pick one:
(a) When hero_books (or whatever seeds the bundle) lays down seed content, also mirror it into each context's WebDAV tree under ~/hero/var/hero_foundry/webdav/<context>/.
(b) service_foundry gains a --seed-media <dir> flag that symlinks or copies a source tree into every per-context WebDAV root on first run.

Option (b) is cleaner — keeps the content-seeding concern with foundry, not with the books seeder.

Filed 2026-04-23 nu-shell demo bring-up. Signed-off-by: mik-tf

Previous comments from home#139

mik-tf — 2026-04-27T03:25:45Z

Triage from the home#193 close-out sweep.

Current state of service_foundry.nu: L87-99 still starts the server with --allow-dir <data_repos> and --webdav-storage <data_webdav> pointing at empty per-instance dirs. Seed media at ~/hero/var/seed_media/{Documents,Photos,Songs,Videos} is not mirrored anywhere. Issue is not fixed.

Why this is more involved than the other Group B verify-then-close items:

Option (a) (hero_books seeder mirrors into webdav) crosses repos and pushes the seeding concern into the wrong layer.
Option (b) (service_foundry --seed-media flag) is cleaner but hero_foundry doesn't know about contexts — that's hero_osis's domain. A naive symlink into a single webdav root would work for instance-0 / single-context bring-up but break multi-context deploys (geomind / incubaid / threefold etc.) where each context expects its own subtree under ~/hero/var/hero_foundry/webdav/<context>/.
A correct option-(b) implementation needs to:
1. Enumerate contexts from hero_osis (or accept a --contexts arg).
2. For each context, mkdir-p webdav/<context>/ and rsync/symlink seed_media into it.
3. Be idempotent (skip if already populated).
4. Be opt-in via flag/env so production deploys aren't surprised by a forced bootstrap.

Decision: keeping this open and moving it from Group B (verify-then-close) into the design-work bucket alongside the AI-grounding issues (Group D). The current workaround in the issue body (manual cp -r per context) remains the correct deploy-time mitigation until the proper bootstrap lands.

Meta-tracker: home#193.

Signed-off-by: mik-tf

Originally filed as home#139 on 2026-04-23 by mik-tf — moved to hero_demo as part of consolidating issue tracking.

## Symptom Videos/Photos/Songs islands show metadata (titles, thumbnails placeholders) from hero_osis_media but actual playback and thumbnail fetches 404. The WebDAV under hero_foundry has no bytes to serve. ## Root cause `service_foundry.nu` starts foundry with: ``` HERO_FOUNDRY_REPOS=~/hero/var/hero_foundry/repos # empty --webdav-storage ~/hero/var/hero_foundry/webdav # empty ``` Seed media is laid down at `~/hero/var/seed_media/{Documents,Photos,Songs,Videos}` by a separate seeding step (hero_books or equivalent), but nothing connects that tree to the foundry WebDAV roots. Foundry therefore has nothing to serve. ## Demo workaround (applied 2026-04-23) For each context (root, default, geomind, incubaid, threefold): ``` cp -r ~/hero/var/seed_media ~/hero/var/hero_foundry/webdav/<context>/ ``` After that, playback and thumbnails resolved. ## Proper fix Pick one: (a) When `hero_books` (or whatever seeds the bundle) lays down seed content, also mirror it into each context's WebDAV tree under `~/hero/var/hero_foundry/webdav/<context>/`. (b) `service_foundry` gains a `--seed-media <dir>` flag that symlinks or copies a source tree into every per-context WebDAV root on first run. Option (b) is cleaner — keeps the content-seeding concern with foundry, not with the books seeder. Filed 2026-04-23 nu-shell demo bring-up. Signed-off-by: mik-tf --- ### Previous comments from home#139 #### mik-tf — 2026-04-27T03:25:45Z Triage from the home#193 close-out sweep. **Current state of `service_foundry.nu`:** L87-99 still starts the server with `--allow-dir <data_repos>` and `--webdav-storage <data_webdav>` pointing at empty per-instance dirs. Seed media at `~/hero/var/seed_media/{Documents,Photos,Songs,Videos}` is not mirrored anywhere. **Issue is not fixed.** **Why this is more involved than the other Group B verify-then-close items:** - Option (a) (hero_books seeder mirrors into webdav) crosses repos and pushes the seeding concern into the wrong layer. - Option (b) (service_foundry `--seed-media` flag) is cleaner but hero_foundry doesn't know about contexts — that's hero_osis's domain. A naive symlink into a single webdav root would work for instance-0 / single-context bring-up but break multi-context deploys (geomind / incubaid / threefold etc.) where each context expects its own subtree under `~/hero/var/hero_foundry/webdav/<context>/`. - A correct option-(b) implementation needs to: 1. Enumerate contexts from hero_osis (or accept a `--contexts` arg). 2. For each context, mkdir-p `webdav/<context>/` and rsync/symlink seed_media into it. 3. Be idempotent (skip if already populated). 4. Be opt-in via flag/env so production deploys aren't surprised by a forced bootstrap. **Decision:** keeping this open and moving it from Group B (verify-then-close) into the design-work bucket alongside the AI-grounding issues (Group D). The current workaround in the issue body (manual `cp -r` per context) remains the correct deploy-time mitigation until the proper bootstrap lands. Meta-tracker: home#193. Signed-off-by: mik-tf --- *Originally filed as [home#139](https://forge.ourworld.tf/lhumina_code/home/issues/139) on 2026-04-23 by mik-tf — moved to hero_demo as part of consolidating issue tracking.*