From 0061ddef72cb7aee27ddc2f746f567de95b6710c Mon Sep 17 00:00:00 2001 From: Gmer4Lfe Date: Sun, 26 Jul 2026 11:10:35 -0400 Subject: [PATCH] Update rsync docs: emby-fallback profile removed, Emby watch state now synced by play_state_sync.sh --- README.md | 5 +---- Rsync/Manual-Rsync.md | 27 ++++++++------------------- Rsync/README-Rsync.md | 8 +++----- 3 files changed, 12 insertions(+), 28 deletions(-) diff --git a/README.md b/README.md index c985e51..fa2230d 100644 --- a/README.md +++ b/README.md @@ -607,10 +607,7 @@ Every 7 minutes: transcode_management.sh cleanup → manager (order non-negotiable) Every 30 minutes: - critical_sync_maintenance.sh Critical-Data + Emby dirty sync + partnership check - -Every 30 minutes: - rsync.sh --profile=emby-fallback Emby watch state sync (separate cron entry) + critical_sync_maintenance.sh Critical-Data rsync + play_state_sync (Emby watch state via API) + partnership check Every 4 hours: arrs_failed_stalled_recovery.sh blocklist + re-search failed imports diff --git a/Rsync/Manual-Rsync.md b/Rsync/Manual-Rsync.md index 283c52c..48a7ff5 100644 --- a/Rsync/Manual-Rsync.md +++ b/Rsync/Manual-Rsync.md @@ -341,24 +341,9 @@ PROFILES["emby_CRITICAL_CONTAINER_NAMES"]=("Emby") PROFILES["emby_EXCLUDE_DIRS"]=( "transcodes/" "logs/" "crash*" "cache/" ) - -# ── emby-fallback ───────────────────────────────────────────────────────────── -# Every 30 minutes, Emby STAYS RUNNING — dirty sync of critical state only -PROFILES["emby-fallback_CRITICAL_CONTAINER_NAMES"]=() # nothing stops -PROFILES["emby-fallback_EXCLUDE_DIRS"]=( - "*.wal" "*.shm" # unsafe mid-write - "transcodes/" "logs/" "crash*" "cache/" -) -PROFILES["emby-fallback_REMOTE_RESTART_CONTAINERS"]=("Emby") ``` -### Two Emby Profiles — Why Both Exist - -**emby-fallback** (every 30 minutes, Emby stays running): -- Syncs: users.db, library.db, authentication.db, config/ -- Skips: \*.wal, \*.shm, transcodes/, logs/, cache/ -- Why: WAL files are written while Emby runs — copying them would produce a corrupt database on HOST2 -- Result: HOST2 is always within 30 minutes of HOST1 on watch state and user activity +### The `emby` Profile and Watch-State Sync **emby** (Sunday 2:30am, both Emby instances stopped): - Syncs: everything except transcodes, logs, cache, crash files @@ -366,8 +351,12 @@ PROFILES["emby-fallback_REMOTE_RESTART_CONTAINERS"]=("Emby") - Why: WAL is checkpointed on clean shutdown — safe to copy everything - Result: HOST2 gets a gold-standard Emby state once per week -The two profiles work together. emby-fallback keeps HOST2 current for immediate fallback. -emby gives HOST2 full fidelity once per week. Neither alone is sufficient. +Between weekly mirrors, Emby **watch/resume state** is kept current by +`Media/play_state_sync.sh`, which reads and writes play state over the Emby API every +30 minutes (CRITICAL_MAINTENANCE_SCRIPTS) — so HOST2 never falls more than one cycle +behind on what's been watched. This replaced the old `emby-fallback` dirty-rsync profile: +copying Emby's live SQLite databases mid-write risked landing a half-written WAL file on +HOST2, and an API-level sync sidesteps the database-consistency problem entirely. --- @@ -705,5 +694,5 @@ name doesn't match any profile key, or when testing a specific profile. ```bash rsync.sh /mnt/user/appdata-Fallback/Critical-Data --profile=critical-data -rsync.sh /mnt/user/Media_Server/Emby --profile=emby-fallback +rsync.sh /mnt/user/Media_Server/Emby --profile=emby ``` diff --git a/Rsync/README-Rsync.md b/Rsync/README-Rsync.md index 90cde98..239f1b9 100644 --- a/Rsync/README-Rsync.md +++ b/Rsync/README-Rsync.md @@ -67,8 +67,8 @@ Orchestrators/ ← decides what to sync, when, and in what order weekly_sync_maintenance.sh ──────────────────────────────────► rsync.sh (emby, critical-data) critical_sync_maintenance.sh ────────────────────────────────► rsync.sh (partnership shares) -Cron (direct): - */30 * * * * ──────────────────────────────────► rsync.sh --profile=emby-fallback +Note: Emby watch/resume state is NOT synced by rsync — Media/play_state_sync.sh + does it over the Emby API every 30 min (CRITICAL_MAINTENANCE_SCRIPTS). Monitors/ bandwidth_monitor.sh ◄─── called by rsync.sh after each sync (--log-transfer) @@ -94,7 +94,6 @@ Profile key = directory basename lowercased. `--profile=name` overrides. | `critical-data` | Auth stack | Mariadb-Authelia, Redis-Authelia, NPM, Lldap | Authelia has restart delay | | `important-data` | NextCloud + Postgres | Postgres-NextCloud | NextCloud has restart delay | | `emby` | Full Emby mirror | Emby (both sides) | Weekly — Sunday 2:30am | -| `emby-fallback` | Emby watch state delta | None | Dirty sync — Emby stays running | For full profile definitions see `Manual-Rsync.md`. @@ -104,7 +103,7 @@ For full profile definitions see `Manual-Rsync.md`. | Script | Role | When It Runs | |--------|------|-------------| -| `rsync.sh` | Core transfer engine — profile resolution, pre-flights, container management, transfer, bandwidth logging | Called by orchestrators; directly for manual and 30-min Emby dirty sync | +| `rsync.sh` | Core transfer engine — profile resolution, pre-flights, container management, transfer, bandwidth logging | Called by orchestrators; directly for manual syncs | --- @@ -116,7 +115,6 @@ Callers (Orchestrators/) ────────────────── weekly_sync_maintenance.sh rsync.sh /path/to/share [--profile=name] │ critical_sync_maintenance.sh ─────────────────────────────────────────────► │ fallback.sh (writeback) │ - Direct cron (emby-fallback) │ ▼ ┌─────────────────────────────────────┐ │ 1. Infer/accept profile │