diff --git a/media-servers/troubleshooting.md b/media-servers/troubleshooting.md
index bb89425..85a4507 100644
--- a/media-servers/troubleshooting.md
+++ b/media-servers/troubleshooting.md
@@ -548,6 +548,20 @@ tar -czf ~/jellyfin-config-backup-$(date +%Y%m%d).tar.gz ~/docker/jellyfin/confi
 - Test on non-production instance if possible
 - Document current working configuration
 
+## Roku Buffering on Weak WiFi — Client Bitrate Cap (2026-03-26)
+
+**Severity:** Low — single device, non-critical viewing location
+
+**Problem:** Roku in a far corner of the house with poor WiFi signal was buffering/failing to play videos. Content was not being transcoded down to accommodate the limited bandwidth.
+
+**Root Cause:** Jellyfin does not dynamically adapt bitrate mid-stream (no HLS ABR like Netflix). The server's `RemoteClientBitrateLimit` was set to `0` (unlimited), and LAN clients are treated as "local" anyway so that setting wouldn't apply. The Roku Jellyfin app was requesting full-quality streams that exceeded the WiFi throughput.
+
+**Fix:** Set **Max Streaming Bitrate** in the Jellyfin Roku app settings (Settings > Playback) to a lower value (4-8 Mbps). This forces the server to transcode down via NVENC before sending. No server-side changes needed.
+
+**Lesson:** For bandwidth-constrained clients, the client-side bitrate setting is the first lever to pull. For a server-enforced cap that survives app resets, create a dedicated Jellyfin user for that device and set a per-user bitrate limit in Dashboard > Users > Playback. The `RemoteClientBitrateLimit` in system.xml only applies to clients Jellyfin considers "remote" — LAN devices are always "local."
+
+---
+
 ## Related Documentation
 - **Setup Guide**: `/media-servers/jellyfin-ubuntu-manticore.md`
 - **NVIDIA Driver Management**: See jellyfin-ubuntu-manticore.md