FailedProxy/Varaverk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

rename appdata-Failover→appdata-Fallback in docs; critical sync 15→30min; transcode 3→7min

Browse Source 
appdata-Failover → appdata-Fallback:
  All .md files updated — scripts and confs already used appdata-Fallback.
  Share was renamed; docs were the only stale references.

critical_sync_maintenance.sh: */15 → */30, 96/day → 48/day:
  critical_sync_maintenance.sh header, master.conf, host1/2.conf comments,
  Orchestrators README, User Script Plug-in README, Partnership README/manual/script,
  Docker_Essentials README/downloaders_reset.sh, Fallback README,
  weekly_sync_maintenance.sh, user_script_plug-in.sh all updated.

rsync_emby_failover User Script superseded:
  Emby dirty sync was already in HOST1_CRITICAL_SYNC_SHARES — it now runs inside
  critical_sync_maintenance.sh every 30min alongside auth sync and partnership check.
  Section in User Script Plug-in README marked for deletion from plugin.

transcode_management.sh: */3 → */7:
  transcode_management.sh, transcode_manager.sh, transcode_cleanup.sh headers,
  Transcodes README/manual, Orchestrators README, User Script Plug-in README,
  user_script_plug-in.sh all updated.
This commit is contained in:
Gmer4Lfe
2026-05-22 22:22:21 -04:00
parent 2d0c91ea13
commit ee086f309e
22 changed files with 129 additions and 156 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Orchestrators/README-Orchestrators.md
+14 -14
View File
@@ -49,7 +49,7 @@ tells you which job and what happened — no correlation needed.
### 🔴 Transcode Manager Triggering Unnecessary SSD Flips
`transcode_manager.sh` ran every 3 minutes on its own. It checked ramdisk usage —
`transcode_manager.sh` ran every 7 minutes on its own. It checked ramdisk usage —
saw 6.8GB used, threshold is 6.5GB, flipped sessions to SSD. One minute later
`transcode_cleanup.sh` ran and removed 4GB of stale segment files from ended sessions.
Actual usage was 2.8GB. Sessions were now on SSD for no reason. Users experiencing
@@ -102,14 +102,14 @@ The User Scripts plugin contains exactly these entries:
array_started.sh
# Cron — one entry per maintenance window:
*/3 * * * * transcode_management.sh
*/7 * * * * transcode_management.sh
0 */6 * * * arrs_failed_stalled_recovery.sh
*/30 * * * * rsync.sh emby-fallback ← not an orchestrator, direct call
*/30 * * * * critical_sync_maintenance.sh ← auth + Emby dirty sync + partnership
0 1 * * * daily_sync_maintenance.sh
30 2 * * 0 weekly_sync_maintenance.sh
# Manual only (not scheduled):
failover_test.sh, emby_database_repair.sh, repair tools
fallback_test.sh, emby_database_repair.sh, repair tools
```
Every job list is configured in the `ORCHESTRATORS` section of `master.conf`.
@@ -168,7 +168,7 @@ without `--log`.
|--------|---------------------|----------|
| `array_started.sh` | All array startup scripts in order | At Startup of Array |
| `watchdog_orchestrator.sh` | resource → docker → system → stability watchdogs | Every minute |
| `transcode_management.sh` | Cleanup then manager — order critical | Every 3 minutes |
| `transcode_management.sh` | Cleanup then manager — order critical | Every 7 minutes |
| `arrs_failed_stalled_recovery.sh` | Failed import + stalled download recovery | Every 6 hours |
| `daily_sync_maintenance.sh` | git pull → sync → media maintenance → restarts | 1am daily |
| `weekly_sync_maintenance.sh` | Stop → update → clean sync → start → weekly restarts | 2:30am Sunday |
@@ -292,11 +292,11 @@ array_started.sh --status
## ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Runs `transcode_cleanup.sh` then `transcode_manager.sh` in the correct order every
3 minutes. Exists because the order is not optional — the manager must always see
7 minutes. Exists because the order is not optional — the manager must always see
post-cleanup usage to make accurate flip decisions.
```bash
# Scheduled: */3 * * * * (every 3 minutes)
# Scheduled: */7 * * * * (every 7 minutes)
```
---
@@ -371,7 +371,7 @@ post-cleanup usage to make accurate flip decisions.
### ── Usage ───────────────────────────────────────────────────────────────────
```bash
transcode_management.sh # normal run (every 3 min via cron)
transcode_management.sh # normal run (every 7 min via cron)
transcode_management.sh --dry-run # passes --dry-run to both child scripts
transcode_management.sh --status # show config, current state, daily log stats
transcode_management.sh --log # verbose output from both child scripts
@@ -730,7 +730,7 @@ maintenance block before the 7am coffee report.
# ─────────────────────────────────────────────────────────────────────────────
# Two Emby syncs run in parallel — dirty and clean:
#
# emby-fallback dirty sync (every 30 minutes, Emby running):
# emby-fallback dirty sync (every 30 minutes via critical_sync_maintenance.sh, Emby running):
# watch states, library deltas, user activity — continuous coverage
# WAL files excluded — safe to copy while Emby writes
# HOST2 always within 30 minutes of HOST1 on playback state
@@ -814,7 +814,7 @@ maintenance block before the 7am coffee report.
# master.conf
WEEKLY_SYNC_SHARES=(
"/mnt/user/Media_Server/Emby" # emby profile — full clean mirror
"/mnt/user/appdata-Failover/Critical-Data" # critical-data — auth stack clean state
"/mnt/user/appdata-Fallback/Critical-Data" # critical-data — auth stack clean state
)
WEEKLY_MAINTENANCE_SCRIPTS=(
@@ -943,14 +943,14 @@ media_management.sh --status # show configured job list and exit
array_started.sh
# ─────────────────────────────────────────────────────────────────────────────
# Frequent — every 3 minutes:
# Frequent — every 7 minutes:
# ─────────────────────────────────────────────────────────────────────────────
*/3 * * * * transcode_management.sh
*/7 * * * * transcode_management.sh
# ─────────────────────────────────────────────────────────────────────────────
# Periodic — not an orchestrator, direct rsync call:
# Every 30 minutes — auth stack + Emby dirty sync + partnership check:
# ─────────────────────────────────────────────────────────────────────────────
*/30 * * * * rsync.sh /mnt/user/Media_Server/Emby --profile=emby-fallback
*/30 * * * * critical_sync_maintenance.sh
# ─────────────────────────────────────────────────────────────────────────────
# Every 6 hours:
Orchestrators/critical_sync_maintenance.sh
+8 -8
View File
@@ -2,9 +2,9 @@
# ==============================================================================================
# ============================= Critical Sync Maintenance ======================================
# ==============================================================================================
# Orchestrator for time-sensitive syncs that run every 15 minutes.
# Orchestrator for time-sensitive syncs that run every 30 minutes.
# Keeps the mirror current between the less frequent daily and weekly windows.
# Schedule: */15 * * * * (every 15 minutes via User Scripts plugin)
# Schedule: */30 * * * * (every 30 minutes via User Scripts plugin)
#
# ── EXECUTION ORDER ───────────────────────────────────────────────────────────────────────────
# 1. Critical-Data rsync — auth stack, NPM config, certs (containers stopped both sides)
@@ -12,8 +12,8 @@
# 3. CRITICAL_MAINTENANCE_SCRIPTS — any scripts configured for critical window
# 4. partnership --check — read both state files, detect changes, act accordingly
#
# ── WHY EVERY 15 MINUTES ──────────────────────────────────────────────────────────────────────
# Auth stack changes (new users, proxy rules, certs) propagate within 15min ✅
# ── WHY EVERY 30 MINUTES ──────────────────────────────────────────────────────────────────────
# Auth stack changes (new users, proxy rules, certs) propagate within 30min ✅
# Emby watch states stay in sync — mirror users see correct playback position ✅
# Partnership state changes detected and acted on quickly ✅
# Lock prevents: daily rsync doing Critical-Data mid-critical window ✅
@@ -24,17 +24,17 @@
# partnership --check always runs regardless — state check doesn't need rsync
#
# ── LOCK BEHAVIOUR ────────────────────────────────────────────────────────────────────────────
# acquire_lock "strict" — if previous 15min run still going, skip this cycle entirely
# Critical-Data taking > 15min is a problem worth knowing about
# acquire_lock "strict" — if previous 30min run still going, skip this cycle entirely
# Critical-Data taking > 30min is a problem worth knowing about
# Strict mode prevents pile-up without waiting — log and move on ✅
#
# ── SILENT WHEN HEALTHY ───────────────────────────────────────────────────────────────────────
# Runs 96 times per day — clean runs must produce zero output ✅
# Runs 48 times per day — clean runs must produce zero output ✅
# Only failures and notable events produce visible output
#
# ── CONFIGURATION (master.conf) ───────────────────────────────────────────────────────────────
# CRITICAL_RSYNC_ENABLED — enable/disable rsync section
# CRITICAL_SYNC_SHARES — shares synced every 15min (HOST*_CRITICAL_SYNC_SHARES)
# CRITICAL_SYNC_SHARES — shares synced every 30min (HOST*_CRITICAL_SYNC_SHARES)
# CRITICAL_MAINTENANCE_SCRIPTS — scripts run in critical window (optional)
# PARTNERSHIP_ENABLED — enable/disable partnership check
#
Orchestrators/transcode_management.sh
+3 -3
View File
@@ -4,7 +4,7 @@
# ==============================================================================================
# Orchestrator — runs transcode_cleanup.sh then transcode_manager.sh in the correct order.
# Replace individual transcode_manager and transcode_cleanup cron entries with this.
# Schedule: */3 * * * * (every 3 minutes via User Scripts plugin)
# Schedule: */7 * * * * (every 7 minutes via User Scripts plugin)
#
# ── WHY CLEANUP BEFORE MANAGER ────────────────────────────────────────────────────────────────
# Cleanup runs first — removes stale segment files from ended sessions.
@@ -47,7 +47,7 @@
# All TRANSCODE_* threshold vars — see master.conf Transcode Manager section
#
# ── USAGE ─────────────────────────────────────────────────────────────────────────────────────
# transcode_management.sh — normal run (every 3 minutes via cron)
# transcode_management.sh — normal run (every 7 minutes via cron)
# transcode_management.sh --dry-run — preview without changes (passed to children)
# transcode_management.sh --status — show configuration and current state
# transcode_management.sh --log — verbose output from both child scripts
@@ -92,7 +92,7 @@ if [[ "$SHOW_STATUS" == true ]]; then
echo "$ICON_RAM Ramdisk: $RAMDISK_PATH ($RAMDISK_SIZE)"
echo "$ICON_DISK SSD fallback: $TRANSCODE_SSD"
echo "$ICON_LINK Symlink: $TRANSCODE_LINK"
echo "$ICON_TIME Schedule: every 3 minutes"
echo "$ICON_TIME Schedule: every 7 minutes"
echo ""
echo "━━━ Child Scripts ━━━"
[[ -f "$CLEANUP_SCRIPT" ]] && \
Orchestrators/weekly_sync_maintenance.sh
+1 -1
View File
@@ -20,7 +20,7 @@
# Emby builds a warm image cache on HOST2 throughout the week.
# Syncing nightly resets cache — cold loads every morning for users.
# Weekly sync: cache stays warm 6 days, resets Sunday night while users sleep.
# emby-fallback dirty sync covers watch states + library every 15min between weekly syncs.
# emby-fallback dirty sync covers watch states + library every 30min between weekly syncs.
#
# ── CONTAINER UPDATES ─────────────────────────────────────────────────────────────────────────
# Containers already stopped for sync — updates pull at zero extra downtime.