Jellyfin on Chromecast keeps stopping mid-episode

[ram]

This has been a big pain for me, but I keep having an issue where reliably, during playback, the Chromecast pauses playback to buffer endlessly. For the particular file I'm examining the problem with, playback's freezing at 00:05:13, which, visually, appears to be the last frame of the transcoded segment. This, however, has been a problem with different video files from different media sources.

To attempt to resolve the issue, I:
- End the Chromecast Session
- Reset episode progress
- Shut down Jellyfin
- Allow ffmpeg to finish its transcoding session
- Delete the transcoding session
- Start Jellyfin
- Start the Chromecast Session
- Begin playback from the episode
- Wait for 00:05:13 to appear again

The logs for my Jellyfin: https://pastebin.com/aJmG5Rdi
The logs for the FFmpeg.DirectStream: https://pastebin.com/xMbUvKwW
These logs are from after the previous procedure was followed, and logs were cleared / reset.

Thanks for any help!!

[TheDreadPirate]

Your server and ffmpeg logs look fine.

What model Chromecast is this?

[ram]

Your server and ffmpeg logs look fine.

What model Chromecast is this?

It's a Chromecast Ultra (two different ones, even)

[TheDreadPirate]

For all the videos you are having issues with, does it always fail at 5:13 into the video?

[ram]

For all the videos you are having issues with, does it always fail at 5:13 into the video?

No it's at different points in the videos and often multiple times throughout the playback

[TheDreadPirate]

Can you try remuxing one of these files and try the new file? This does not require re-encoding.

Open a command prompt and run this command.

Code:

ffmpeg -fflags +genpts+igndts -i "E:\Live Action Shows\Doctor Who (2005) [tvdbid-78804]\Season 10\Doctor.Who.2005.S10E01.The.Pilot.720p.BluRay.DD.5.1.x264-DON.mkv" -codec copy -avoid_negative_ts make_zero -max_muxing_queue_size 2048 -max_interleave_delta 0 "E:\newFile.mkv"

[Dan Stoner]

I know it is over a year later, but I recently ran into this exact issue and kept working on it until I found a probable cause (and solution).

In my case I believe it is due to bitrate spikes.  The problem occurs in "large" high definition videos that were created over a decade ago and I had never tried playing via Chromecast until recently.

My solution has been to re-encode all of the problem videos with a max bitrate cap (ffmpeg -maxrate).

Code:

ffmpeg -i 'Big File (HD).mkv' -c:v libx264 -preset slow -maxrate 15M -crf 18 -c:a copy 'Big File (HD) maxrate 15M crf 18.mkv'

I have actually been starting with -maxrate 30M which fixes the problem for me most of the time and helps preserve more of the original video quality.  Then there are a few of my videos that will freeze in a different place after that re-encoding, so I go back to the source and try again with a lower value like 20M.  And for a very very few I had to go down to 15M.  I see recommendations on the Internet that 10 - 12M is the actual max bitrate for old Chromecast devices.  It's a bit tedious to do the re-encoding, and then start playback, and then wait to see if the movie plays all the way through... but this workflow "works" for me.

Re-muxing did not help me and I was unable to find a way to determine by looking at the files themselves that they would be problematic... it would be nice to be able to scan my library and only re-encode the the files that are likely to be broken, without having to actually watch every movie through a Chromecast device to see if it actually breaks.


p.s. ChatGPT can be pretty dumb about a lot of things but it seems to have some good suggestions about ffmpeg encoding and media playback.  It pointed me at the bitrate issue with early Chromecast devices and other possible issues like the following, none of which panned out, but seemed plausible (but could totally be hallucinations):

Your file was muxed with:


mkvmerge v3.2.0 (2010)
libmatroska v0.8.1

Those are 14–15 years old, very early implementations with known issues involving:

• broken cluster seeking
  
• incorrect cue positions
  
• timestamp rounding errors
  
• bad index tables
  
• incorrect handling of B-frames in MKV
  

Chromecast is very sensitive to seek table errors, and symptoms match:
✔ plays fine until it hits a bad cluster
✔ freezes at exactly the same timestamp every time
✔ other players (VLC, MPV) work — because they are far more forgiving
 
Old x264 builds could produce:
- slightly non-compliant B-frame timing
- weird keyframe/cue misalignment
- edge-case bitstream behaviors modern hardware decoders dislike

Chromecast’s H.264 decoder is generally strict.