Exoplayer black screen on Android TV when transcoding ASS subtitles

[cheeselord]

I've attached the log that was generated from running that command.

  repack-file.txt (Size: 11.65 KB / Downloads: 22)

Out of curiosity, I put the outputFile.mkv into my Jellyfin library just to see what would happen.  It took 15 seconds to load, but it started to play in ExoPlayer and the subtitles were burned in correctly.  Additionally, only one transcode log was generated as opposed to the multiple I would usually see while it was attempting to start.  I'll attach the log.

  exo-success-outputFile.txt (Size: 48.9 KB / Downloads: 31)

After that successfully played, I tried to play the original file.  It did the same thing as it usually does and just continually attempted to transcode before I backed out of the player.  I've attached one example of the many transcode logs it generated.

  exo-unsuccessful-original.txt (Size: 23.64 KB / Downloads: 21)

I then tried to play the outputFile.mkv again, but it would not play.  It started to do the same thing the original file did.  Here is one of the many logs it generated.

  exo-unsuccessful-outputFile.txt (Size: 23.51 KB / Downloads: 15)


After this, I unchecked the "Allow encoding in HEVC" option and tried again.  This time both files played just fine and generated only one transcode log per file, but it took awhile for them to load.  While they were loading, I checked the Dashboard to see what Jellyfin was reporting, and while they were loading, it reported that both files were "Direct Playing".  When ExoPlayer started playing the file, that's when the Dashboard showed that the file was being transcoded.  I've attached a log of the original file successfully playing.

  exo-success-original.txt (Size: 86.04 KB / Downloads: 19)

Since unchecking this option seemed to help, I wanted to check "Allow encoding in HEVC" again to see if I can get it to fail.  However, both files play just fine now.  I can't make heads or tails of this, so I apologize for all of the logs.  Does the server not pick up on the changes to the Playback section right away or is this just a red herring?

[TheDreadPirate]

I've noticed it can take a sec to pick up changes. I always restart Jellyfin whenever I make significant changes because of what you're describing.

[cheeselord]

It doesn't look like checking or unchecking "Allow encoding in HEVC format" makes a difference here.  Everytime I changed a setting in Playback, I would restart Jellyfin. Nothing else has been changed to my knowledge, but the episode consistently plays each time now and generates exactly one transcode log.  It takes about 15 seconds to load though.  Some other anime episodes with ASS subtitles load within 2-3 seconds.

Additionally, I wanted to test another piece of anime media with ASS subtitles that would consistently give me issues in Exoplayer.  These are movies, and none of the above troubleshooting has allowed them to play in Exoplayer.  Other anime movies that have PGSSUBs can DirectPlay on the Firestick.

This particular piece of media throws the "Player error encountered. Will retry..." (as opposed to the episodes we've been looking at which never showed this error), and continues to generate transcode logs in Jellyfin until I exit the player.  In the server logs I can see that ffmpeg has exited with code 137.  Immediately when I exit Exoplayer though, quite a few ffmpeg processes are launched and the transcode logs are written to.  These processes will continue to run until I manually kill them.

Here is one log of many where the ffmpeg process exited with code 137.  This will keep happening until I exit Exoplayer.

  exo-failed-howls-code-137.txt (Size: 12.51 KB / Downloads: 27)
  jf-server-log-howls-code-137.txt (Size: 8.99 KB / Downloads: 36)

Once I closed Exoplayer, 2 or 3 ffmpeg processes fired off and started writing to the log until I manually killed them.

  exo-howls-transcode-after-exit.txt (Size: 21.46 KB / Downloads: 33)

I would like to think that maybe this is hardware related on my end, but it still seems like it's specific to something inside the media that is giving me issues.

[TheDreadPirate]

The only thing that makes sense is that it is taking a long time to extract all the fonts or something.

From the ffmpeg command.

Code:

fontsdir='/config/cache/attachments/0f61260f1a76e2d52dafda15a48bcf35'

When you start it a second time I see that it is looking at the same path for the ASS subtitle fonts.

How long as you waiting before backing out? Maybe give it a sec more? What is your media stored on?

[cheeselord]

That's what I was thinking as well.  The only logical difference I can see is that each piece of media might be using different fonts.

I was waiting about 2 minutes before.  Out of curiosity I waited about 5 minutes before backing out this time - same behavior.  Here's a screen capture of the logs it generated within a couple minutes. 
   

Almost everyone of them stops at this:

Code:

[Parsed_subtitles_3 @ 0x55bd310db480] libass API version: 0x1502000
[Parsed_subtitles_3 @ 0x55bd310db480] libass source: tarball: 0.15.2
[Parsed_subtitles_3 @ 0x55bd310db480] Shaper: FriBidi 1.0.8 (SIMPLE) HarfBuzz-ng 2.7.4 (COMPLEX)
[Parsed_subtitles_3 @ 0x55bd310db480] Loading font file '/config/cache/attachments/0f61260f1a76e2d52dafda15a48bcf35/fansubBlock.ttf'
[Parsed_subtitles_3 @ 0x55bd310db480] Loading font file '/config/cache/attachments/0f61260f1a76e2d52dafda15a48bcf35/LEXIA__.otf'
[Parsed_subtitles_3 @ 0x55bd310db480] Loading font file '/config/cache/attachments/0f61260f1a76e2d52dafda15a48bcf35/CALJOETRIAL.otf'
[Parsed_subtitles_3 @ 0x55bd310db480] Loading font file '/config/cache/attachments/0f61260f1a76e2d52dafda15a48bcf35/aparaj.ttf'
[Parsed_subtitles_3 @ 0x55bd310db480] Using font provider fontconfig

Since I waited longer this time, I did notice some of the logs are being written to as if a successful transcode is occuring even before I back out of the player.  Once I exit the player, some of them quit on their own while others will transcode the entire length of the film if I don't manually stop them.  This takes up quite a bit of resources since it seems like it is trying to transcode the same file multiple times at once.

For my Jellyfin library I have a single 14TB Seagate Ironwolf.  I use a Samsung Evo 850 500GB SSD for Ubuntu and all of my Docker related data sources.  Only media lives on the 14TB drive.  Recent S.M.A.R.T. tests don't show anything wrong with the two drives.

When I have the time, I can try to look into replacing fonts for this particular piece of media and see if that alleviates anything.  I do not know the ffmpeg syntax well enough at the moment.

[TheDreadPirate]

As a sanity check, can you spin up another Jellyfin container? But use the official jellyfin/jellyfin image instead of the LSIO image?

Keep the config and data directory separate since the LSIO and official images aren't 1-to-1, IIRC. But add the same library(s).

[cheeselord]

I spun up the official jellyfin/jellyfin image and experienced the same results.  Perhaps not as many transcode attempts.  However, the logs and behavior are exactly the same.

Here is my compose for reference:

Code:

version: "3.8"
services:
  jf-test:
    image: jellyfin/jellyfin
    user: 998:998
    container_name: jf-test
    runtime: nvidia
    networks:
      - jellyfin
    volumes:
      - /opt/docker/jellyfin/test_config:/config
      - /opt/docker/jellyfin/test_cache:/cache
      - /mnt/mergerfs/media:/media:ro
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]
networks:
  jellyfin:
    name: jellyfin

Other media can transcode just fine on this container and nvidia-smi is reporting that the GPU has been passed through.  Disabling the "Allow encoding in HEVC format" option did not help in this container either.

[cheeselord]

Just wanted to provide a small update.  I wasn't able to effectively "replace" fonts for the media.  I tried to pull known good fonts and attach them to the media container using the same file names, but was met with this on all of my attempts:

Code:

[matroska,webm @ 0x563cff8b1480] Could not find codec parameters for stream 4 (Attachment: none): unknown codec
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
[matroska,webm @ 0x563cff8b1480] Could not find codec parameters for stream 5 (Attachment: none): unknown codec
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
[matroska,webm @ 0x563cff8b1480] Could not find codec parameters for stream 6 (Attachment: none): unknown codec
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
[matroska,webm @ 0x563cff8b1480] Could not find codec parameters for stream 7 (Attachment: none): unknown codec
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options

This still gave me the same playback results as before.  Therefore, I attempted to just remove the font attachments entirely to see what would happen...same results.  Even when I removed the font attachments, I could still see burned in subtitles on other players like my browser, so I assume the server is using some type of fallback font.  It did take awhile to load in the browser, so I wonder if ExoPlayer is just giving up too early and that is the 137 code I'm seeing?

Another thing I tried was using Intel QuickSync instead of my GPU since I was having issues with it dropping out from the container already.  I'm using the i5-7600 and have transcode parity with my GPU from my tests.  The same playback behavior also happens with QuickSync, so I'm inclined to believe it's some limitation of the Android-TV client.

Here are the logs after removing the font attachments.  It does the same behavior where after waiting it will successfully start transcoding and writing to one of the logs, but I do not see anything on the screen:

  jf-server-log-fonts-removed.txt (Size: 12.71 KB / Downloads: 14)
  exo-removing-font-attachments-137.txt (Size: 11.8 KB / Downloads: 19)
  exo-removing-font-attachments.txt (Size: 23.25 KB / Downloads: 37)

Here's a summary of everything thus far.  I may transition this to an issue on Github when I have the time, since it seems to be related to the Android-TV client.

1. Some media with ASS subtitles will transcode properly in ExoPlayer after a wait of about 15 seconds, others are sometimes instant.  The same media plays without delay on LibVLC, but the subtitles are never shown even though subtitles are set to "Burn in" on the server.
   
2. Some media with ASS subtitles refuse to play in ExoPlayer and will generate many transcode logs that stop at the line "Using font provider fontconfig".  Eventually, the transcode starts but a black screen still shows in ExoPlayer which gives me playback errors no matter how long I wait.  With LibVLC, the media plays without delay, but the subtitles are never shown similar to above.
   
3. My server can successfully transcode the same media to other players like the browser without generating multiple transcode logs and quitting.  It is just the Firestick that has these issues.
   

[TheDreadPirate]

After helping some other users with their LSIO docker setups, where it was determined that the LSIO image behaves differently from the official image, I decided to spin up a LSIO Jellyfin container to attempt to replicate your problem.  H264, ASS subs, exo player, transcoded.  Unfortunately, everything functioned as expected on my CCwGTV.

So I agree with your conclusion that it is something to do with the Firestick/FireOS.  There have been quite a few Firestick users here and in the matrix/discord with similar weird problems.  A few had luck explicitly selecting libVLC, but not all.