lhumina_code/home
23
0
Fork 0
Code Issues 6 Pull requests Projects Releases Packages Wiki Activity Actions

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

New issue
Closed
opened 2026-04-23 23:16:46 +00:00 by mik-tf · 2 comments
mik-tf commented 2026-04-23 23:16:46 +00:00
Owner
Copy link

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

## 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
mik-tf commented 2026-04-27 03:25:45 +00:00
Author
Owner
Copy link

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

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
mik-tf commented 2026-04-28 12:20:23 +00:00
Author
Owner
Copy link

Moved to hero_demo#19 — see lhumina_code/hero_demo#19

Moved to hero_demo#19 — see https://forge.ourworld.tf/lhumina_code/hero_demo/issues/19
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/home#139
No description provided.