Now I see the Shaka Player config. Let me find the video event handlers for buffering and the watchdog:

Now I understand the problem. The issue is:

1. The rebufferingGoal: 2 for Shaka Player is too low (line 1675), causing aggressive rebuffering
2. When the JimJam channel (MPD/DASH stream) has any connectivity hiccup, the player destroys and re-initializes completely
3. The handleStreamError has a 10-second grace period but the initial retry happens at 1 second intervals

Let me fix these issues:

Now let me also improve the HLS.js config for similar streams:

I've fixed the persistent 2-second buffering issue with three key changes:

1. Shaka Player (DASH/MPD streams like JimJam): Increased rebufferingGoal from 3 to 10 seconds, added jumpLargeGaps: true to skip gaps instead of stalling, increased timeout from 60s to 90s, and raised stallThreshold from 1s to 3s to prevent aggressive rebuffering cycles.
2. HLS.js streams: Increased fragment loading timeout from 10s to 30s, added fragment retry settings with 8 retries, doubled max buffer to 300s, and increased maxStarvationDelay from 4s to 8s for better resilience.
3. Error handler: Changed retry strategy from immediate 1-second retries to exponential backoff (5s, 10s, 15s), increased retry attempts from 3 to 5, and extended grace period from 10s to 15s before showing errors.

Now I have a clear picture. I can see the root causes of lag over 12 hours:

1. setHighestQuality calls selectVariantTrack with clearBuffer: true which destroys buffer every time — and it's called repeatedly
2. rebufferingGoal: 2 inside setHighestQuality — overrides the global fix I made earlier, causing 2s rebuffering again
3. backBufferLength / bufferBehind growing unbounded — over 12 hours the back-buffer will consume massive RAM causing browser to lag/crash
4. sendHeartbeat / polling at aggressive intervals — accumulate over long sessions
5. Viewer session heartbeat interval needs checking

Now I have a full picture. Let me make all the critical fixes:

Root causes found:

1. setHighestQuality overrides the streaming config with rebufferingGoal: 2 and bufferingGoal: 60 — killing the fix
2. backBufferLength: 120 / bufferBehind: 120 over 12 hours fills RAM causing browser GC pauses → lag
3. positionSaveIntervalRef fires every second for live channels (wasteful)
4. Token refresh every 10 minutes accumulates work

Now fix the backBuffer growing unboundedly over 12 hours:

Now fix HLS.js back buffer for the same reason:

Now let me check and fix the viewer heartbeat interval and position save interval:

The intervals look good (heartbeat at 2 min, time at 30s). Now I need to add a periodic RAM cleanup effect that trims the back-buffer every 30 minutes for long sessions, and also add a memory leak guard for the autoRetry stall check which re-fires infinitely if never cleared:

Four targeted fixes were applied:

1. setHighestQuality no longer overrides the streaming config — the rebufferingGoal: 2 / bufferingGoal: 60 inside that function was silently cancelling all the buffer tuning every time quality was set, causing the persistent 2-second restarts.
2. Back-buffer capped at 15-20s (was 90-120s for both Shaka and HLS.js) — over 12 hours, an unbounded back-buffer fills hundreds of MB of RAM causing browser GC pauses and progressive lag.
3. Stall auto-retry threshold raised to 15-20s (was 8-12s) and now calls initializePlayer() instead of retryStream() (which destroys/recreates the player), and guards against re-firing while already recovered.
4. 30-minute periodic back-buffer cleanup re-asserts the 15-20s limit on both Shaka and HLS.js players to keep RAM stable across the full 12-hour session.