PROBLEM SUMMARY
When playing MPEG4/MP3 AVI files on Android TV (Chromecast HD), video playback starts with a frozen frame for 3-5 seconds while audio plays normally. After this initial delay, playback continues in sync. This issue does NOT occur on web browsers (Chrome/Safari).
ENVIRONMENT
Server: Jellyfin Version 10.10.7, Server OS TrueNAS ElectricEel 24.10.2.2, FFmpeg 7.0.2-Jellyfin, Hardware AMD FX-8320 with 24GB RAM
Client: Chromecast HD (Google Chromecast with Google TV HD), Android Version 14, Jellyfin Android TV Version 0.19.4 (190499), SOC AMLS805X2, Local ethernet connection
Test File: AVI container with MPEG4 (XVID) video at 720x544, 25fps, 986 kbps, and MP3 audio at 48kHz stereo, 116 kbps. Duration is 43 minutes 51 seconds.
REPRODUCTION STEPS
Play an MPEG4/MP3 AVI file on Android TV Jellyfin app. Observe video starts with frozen frame while audio plays. After 3-5 seconds, video begins and remains in sync. Playing the same file in Chrome web browser shows no sync issue.
TECHNICAL ANALYSIS - SOURCE FILE VERIFICATION
Verified the source file has NO sync issues using multiple tools. Running ffprobe shows both video stream and audio stream have start_time=0.000000, with video duration 2631.200000 and audio duration 2631.192000. MediaInfo confirms both streams are 43 min 51 s duration with no delay metadata present and proper AVI interleaving (1656ms preload is normal). Conclusion: Source file is perfectly synchronized.
TECHNICAL ANALYSIS - SERVER-SIDE BEHAVIOR
Jellyfin transcodes the video using HLS with 3-second segments. The transcode command uses libx264 for video with preset veryfast and crf 23, while audio is copied directly. Output format is HLS with 3-second segments using mpegts container. Key observations: Video is transcoded to H264 at about 500fps encoding speed, but takes 3 seconds to generate the first segment. Audio is copied directly and available instantly with no encoding delay. The first video segment (0.ts) takes approximately 3 seconds to complete while audio segments are available immediately.
TECHNICAL ANALYSIS - CLIENT-SIDE BEHAVIOR
On Android TV (Chromecast HD) the device profile shows MPEG4 is not in DirectPlay codecs. The HLS player receives audio segment 0 which is ready immediately, and receives video segment 0 which is still encoding. The player starts audio playback without waiting for video, resulting in frozen video frame for 3-5 seconds at start.
On Chrome Web Browser the same transcode occurs server-side, but the HLS player waits for both audio AND video segments before starting playback. Result is perfect sync from playback start.
The Android TV device profile confirms MPEG4 not supported for DirectPlay. The DirectPlayProfiles show VideoCodec as "av1,h264,hevc,mpeg,mpeg2video,vp8,vp9" and AudioCodec as "aac,mp2,mp3". Note that MPEG4 is missing from video codecs, forcing transcode. The device DOES have hardware MPEG4 decoder (c2.amlogic.mpeg4.decoder) but with limitations, specifically max 896x896 resolution, that likely exclude it from the profile.
ROOT CAUSE
This is an Android TV HLS player buffering bug. The client's ExoPlayer implementation doesn't properly synchronize audio and video streams when audio stream is copied (instant availability) and video stream is transcoded (delayed availability). The player should buffer both streams until the first video segment completes encoding, but instead begins audio playback immediately.
WORKAROUNDS
Force Audio Transcoding. Lower the audio bitrate limit to force AAC transcoding, which keeps audio/video segment generation synchronized. In Android TV app go to Settings, then Playback, then Maximum bitrate, and set to 100 kbps or lower (below the source audio bitrate of 116 kbps). This forces both audio and video to transcode together, eliminating the timing mismatch. If playback is returned to begining of file, then the mismatch occurs
EVIDENCE SUMMARY
Source file verified clean using ffprobe and MediaInfo. Server transcode working correctly with logs confirming expected behavior. Issue reproduces consistently on Android TV version 0.19.4. Issue does NOT occur on web browser with same transcode. Workarounds confirmed effective. This appears to be a client-side Android TV HLS player bug, not a server or source file issue. Basic troubleshooting attempted, (e.g. restart, clean transcode directory, etc).
jellyfin-androidtv-sync-bug-logs.txt (Size: 16.68 KB / Downloads: 2)
Specific logs available on request
When playing MPEG4/MP3 AVI files on Android TV (Chromecast HD), video playback starts with a frozen frame for 3-5 seconds while audio plays normally. After this initial delay, playback continues in sync. This issue does NOT occur on web browsers (Chrome/Safari).
ENVIRONMENT
Server: Jellyfin Version 10.10.7, Server OS TrueNAS ElectricEel 24.10.2.2, FFmpeg 7.0.2-Jellyfin, Hardware AMD FX-8320 with 24GB RAM
Client: Chromecast HD (Google Chromecast with Google TV HD), Android Version 14, Jellyfin Android TV Version 0.19.4 (190499), SOC AMLS805X2, Local ethernet connection
Test File: AVI container with MPEG4 (XVID) video at 720x544, 25fps, 986 kbps, and MP3 audio at 48kHz stereo, 116 kbps. Duration is 43 minutes 51 seconds.
REPRODUCTION STEPS
Play an MPEG4/MP3 AVI file on Android TV Jellyfin app. Observe video starts with frozen frame while audio plays. After 3-5 seconds, video begins and remains in sync. Playing the same file in Chrome web browser shows no sync issue.
TECHNICAL ANALYSIS - SOURCE FILE VERIFICATION
Verified the source file has NO sync issues using multiple tools. Running ffprobe shows both video stream and audio stream have start_time=0.000000, with video duration 2631.200000 and audio duration 2631.192000. MediaInfo confirms both streams are 43 min 51 s duration with no delay metadata present and proper AVI interleaving (1656ms preload is normal). Conclusion: Source file is perfectly synchronized.
TECHNICAL ANALYSIS - SERVER-SIDE BEHAVIOR
Jellyfin transcodes the video using HLS with 3-second segments. The transcode command uses libx264 for video with preset veryfast and crf 23, while audio is copied directly. Output format is HLS with 3-second segments using mpegts container. Key observations: Video is transcoded to H264 at about 500fps encoding speed, but takes 3 seconds to generate the first segment. Audio is copied directly and available instantly with no encoding delay. The first video segment (0.ts) takes approximately 3 seconds to complete while audio segments are available immediately.
TECHNICAL ANALYSIS - CLIENT-SIDE BEHAVIOR
On Android TV (Chromecast HD) the device profile shows MPEG4 is not in DirectPlay codecs. The HLS player receives audio segment 0 which is ready immediately, and receives video segment 0 which is still encoding. The player starts audio playback without waiting for video, resulting in frozen video frame for 3-5 seconds at start.
On Chrome Web Browser the same transcode occurs server-side, but the HLS player waits for both audio AND video segments before starting playback. Result is perfect sync from playback start.
The Android TV device profile confirms MPEG4 not supported for DirectPlay. The DirectPlayProfiles show VideoCodec as "av1,h264,hevc,mpeg,mpeg2video,vp8,vp9" and AudioCodec as "aac,mp2,mp3". Note that MPEG4 is missing from video codecs, forcing transcode. The device DOES have hardware MPEG4 decoder (c2.amlogic.mpeg4.decoder) but with limitations, specifically max 896x896 resolution, that likely exclude it from the profile.
ROOT CAUSE
This is an Android TV HLS player buffering bug. The client's ExoPlayer implementation doesn't properly synchronize audio and video streams when audio stream is copied (instant availability) and video stream is transcoded (delayed availability). The player should buffer both streams until the first video segment completes encoding, but instead begins audio playback immediately.
WORKAROUNDS
Force Audio Transcoding. Lower the audio bitrate limit to force AAC transcoding, which keeps audio/video segment generation synchronized. In Android TV app go to Settings, then Playback, then Maximum bitrate, and set to 100 kbps or lower (below the source audio bitrate of 116 kbps). This forces both audio and video to transcode together, eliminating the timing mismatch. If playback is returned to begining of file, then the mismatch occurs
EVIDENCE SUMMARY
Source file verified clean using ffprobe and MediaInfo. Server transcode working correctly with logs confirming expected behavior. Issue reproduces consistently on Android TV version 0.19.4. Issue does NOT occur on web browser with same transcode. Workarounds confirmed effective. This appears to be a client-side Android TV HLS player bug, not a server or source file issue. Basic troubleshooting attempted, (e.g. restart, clean transcode directory, etc).
jellyfin-androidtv-sync-bug-logs.txt (Size: 16.68 KB / Downloads: 2)
Specific logs available on request