Library Bundle

Move your LapInsight data between machines or share an event as a self-contained bundle.

Library Bundle is the canonical way to move LapInsight data between installs — between two trackside laptops, from your work machine to your home machine, or to share an event with a coach. A bundle is a self-contained folder with a versioned manifest, a SQLite subset, and copies of the referenced media.

Use it for:

  • Coach handoff: export one event with full session notes, markers, telemetry, and videos.
  • Multi-laptop consolidation: export all of today's days from the trackside laptop and import them on the engineering laptop.
  • Migrating to a new machine: export Whole Library, import on the new install.

For point-in-time snapshots of just the database (not for transfer), use Backup & Restore instead.

Bundle layout

`` MyEvent_2026-05-09_bundle/ ├── manifest.json ← versioned metadata ├── data/ │ └── export.sqlite ← DB subset, 15+ tables └── assets/ ├── video/ ├── document/ └── image/ ``

The manifest carries version, bundle_min_supported, schema_version (highest applied migration on the source), app_version, scope, asset inventory, and entity ID maps.

Export

File → Export Library Bundle... opens the export dialog with three scope choices:

ScopeWhen to useWhat ships
Selected DaysSharing one or two specific days (e.g. a coaching session).Just those days + their sessions / videos / notes / markers.
Selected EventHanding off a complete event.All non-deleted days for the event, honouring the event's scope (shared vs driver-specific).
Whole LibraryMigrating to a new machine, archiving an entire install.Every non-deleted day in the database.

Choose what assets to include via the checkboxes:

  • Videos — all session-linked video files.
  • Documents — PDFs and other documents associated with sessions or days.
  • Images — including embedded images referenced from session notes.

Bundle export runs on the UI thread but ticks progress per-day during the asset-scan phase, then per-asset during the copy phase, so a Whole-Library export of 100+ days stays responsive.

Import

File → Import Library Bundle... asks for the bundle folder and the destination data root, then offers a Preview button.

Preview (dry-run)

Click Preview before clicking OK. The import runs in dry-run mode: it does the full DB rewrite inside a transaction, then rolls back without writing anything to disk or copying any assets. The preview panel reports per-table counts:

`` Table Seen Insert Skip ---------------------------------------------------------------- days 11 11 0 events 3 3 0 session_notes 11 11 0 videos 28 26 2 session_markers 147 147 0 ... ``

  • Seen — rows the bundle contains for this table.
  • Insert — rows that would be added to the local DB.
  • Skip — rows that wouldn't be inserted (UUID already exists locally, or a foreign-key target wasn't part of the bundle).

If the preview looks wrong, cancel and investigate before committing.

Real import

Clicking OK runs the real import. Before any DB writes, LapInsight auto-creates a pre-bundle-import backup (see Backup & Restore). If anything goes wrong, that backup is your one-step rollback.

Manifest validation

Import refuses bundles in two cases:

  • Bundle format too newmanifest.version exceeds the local app's supported version. Upgrade LapInsight.
  • Bundle schema newer than local — the source DB was on a newer migration than the local DB. Upgrade LapInsight first; otherwise the import would silently drop columns the local DB doesn't yet know about.

Older bundles (older format or older schema) import fine — the bundle path uses UUID-first deduplication and FK remapping that gracefully tolerates schema gaps.

Re-importing the same bundle

Importing a bundle twice is safe. The second pass deduplicates by UUID across events, days, sessions, videos, and most other UUID-tracked entities. The second import shows 0 inserts and skip counts equal to seen counts.

Path rebasing

LapInsight rewrites absolute paths from the source machine to the destination data root automatically:

  • days.day_folder_path and sessions' session_path are rebased.
  • Video file_path and document paths are mapped to their imported locations under <dest_root>/_ImportedAssets/<type>/ (or to their original relative paths if those resolve under dest_root).
  • Path references embedded inside session note text are rewritten via the same source→dest mapping.

You can also import on a machine where the original source_root matched — paths will simply land back at their original locations.

Cancel and progress

  • During asset copy: clicking Cancel on the progress dialog stops the copy and aborts the import (DB writes haven't happened yet).
  • During DB import: cancel is honoured up to the point of commit. After commit, the only rollback is restoring from the auto-created pre-bundle-import backup.

What bundle is NOT

  • Not a sync system. Bundles are one-way snapshots. There's no continuous sync, no two-way merge, no conflict resolution beyond the UUID dedupe.
  • Not encrypted. Treat bundle folders the same way you'd treat the data root.
  • Not a backup. Bundles aren't designed for "snapshot the live DB before I do something risky" — that's Backup & Restore. Bundles are for cross-machine transfer.

Troubleshooting

  • "export.sqlite not found" — the bundle folder is missing files. Re-export from the source.
  • "Bundle format version X is newer than this app supports" — update LapInsight on the importing machine.
  • "Bundle schema X is newer than local schema Y" — the source machine ran a newer migration set; update LapInsight on the importing machine and restart so migrations run.
  • Imported videos show as missing — the asset copy phase may have failed silently (e.g. permission errors). Check the assets/ directory inside the bundle and the destination <data_root>/_ImportedAssets/.

See also