You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description
On network paths with high round-trip latency and unstable/bursty throughput (e.g. long-distance international connections), video playback stutters constantly and enters frequent rebuffering, even when the transcoding bitrate is set very low (tested down to 420kbps). Average throughput on the affected link is around 500kbps–1Mbps, which should be more than sufficient for a 420kbps stream, but short-term dips in bandwidth are enough to starve the player's buffer and cause a stall.
Evidence / Comparison
I compared identical conditions (same server, same file, same client-side network) across two players:
Jellyfin for Android TV: plays transcoded content via HLS with short (3s) segments. Stutters/rebuffers heavily, even after lowering the transcoding bitrate to 420kbps and confirming (via server-side monitoring) that the server-side encoder had massive headroom (21x realtime) and was not the bottleneck.
Kodi with the official Jellyfin add-on: playing the exact same file, same server, same network, with default Kodi settings (no custom advancedsettings.xml buffer tuning). Kodi negotiates Direct Play over plain progressive HTTP instead of HLS, and its built-in player does aggressive read-ahead caching of the continuous HTTP stream by default. Playback is smooth with no stutter at all, at full original quality.
Network-level testing confirmed:
Server-side transcoding was never the bottleneck (hardware encode running at 21x realtime speed).
The client's own network path sustains a real, measured throughput of only ~500kbps–1Mbps under sustained load (measured via direct file transfer on the same LAN as the affected device), with high but stable round-trip latency (~230ms) and 0% packet loss on ICMP probes — i.e. the link is capacity-limited/bursty rather than simply broken.
The difference in playback smoothness between the two clients is attributable to buffering/delivery strategy, not to server load, transcoding settings, or raw available bandwidth.
Suggested improvement
Expose a user-configurable playback buffer / read-ahead size (or a "prefer larger buffer over low latency" toggle) in the Android TV app's playback settings, similar to what desktop/Kodi-based clients already allow. Even a coarse setting (e.g. small / default / large buffer, translating to different ExoPlayer DefaultLoadControl min/max buffer values) would let users on unstable or high-latency connections trade a few extra seconds of start-up delay for uninterrupted playback, without having to switch to a different client app.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Description
On network paths with high round-trip latency and unstable/bursty throughput (e.g. long-distance international connections), video playback stutters constantly and enters frequent rebuffering, even when the transcoding bitrate is set very low (tested down to 420kbps). Average throughput on the affected link is around 500kbps–1Mbps, which should be more than sufficient for a 420kbps stream, but short-term dips in bandwidth are enough to starve the player's buffer and cause a stall.
Evidence / Comparison
I compared identical conditions (same server, same file, same client-side network) across two players:
Jellyfin for Android TV: plays transcoded content via HLS with short (3s) segments. Stutters/rebuffers heavily, even after lowering the transcoding bitrate to 420kbps and confirming (via server-side monitoring) that the server-side encoder had massive headroom (21x realtime) and was not the bottleneck.
Kodi with the official Jellyfin add-on: playing the exact same file, same server, same network, with default Kodi settings (no custom advancedsettings.xml buffer tuning). Kodi negotiates Direct Play over plain progressive HTTP instead of HLS, and its built-in player does aggressive read-ahead caching of the continuous HTTP stream by default. Playback is smooth with no stutter at all, at full original quality.
Network-level testing confirmed:
Server-side transcoding was never the bottleneck (hardware encode running at 21x realtime speed).
The client's own network path sustains a real, measured throughput of only ~500kbps–1Mbps under sustained load (measured via direct file transfer on the same LAN as the affected device), with high but stable round-trip latency (~230ms) and 0% packet loss on ICMP probes — i.e. the link is capacity-limited/bursty rather than simply broken.
The difference in playback smoothness between the two clients is attributable to buffering/delivery strategy, not to server load, transcoding settings, or raw available bandwidth.
Suggested improvement
Expose a user-configurable playback buffer / read-ahead size (or a "prefer larger buffer over low latency" toggle) in the Android TV app's playback settings, similar to what desktop/Kodi-based clients already allow. Even a coarse setting (e.g. small / default / large buffer, translating to different ExoPlayer DefaultLoadControl min/max buffer values) would let users on unstable or high-latency connections trade a few extra seconds of start-up delay for uninterrupted playback, without having to switch to a different client app.
Environment
Jellyfin server: 10.11.11.0 (Docker, jellyfin/jellyfin image)
Client: Jellyfin for Android TV (affected), Kodi 2.1.0 Jellyfin add-on (working well, for comparison)
Network: client behind a high-latency (~230ms RTT), bandwidth-constrained international link
All reactions