[Solved] No streaming for certain file types on Chrome Android app when server is behind SSL Nginx reverse proxy


Hi there, I can’t seem to find a similar topic so I started this one.

While starting media on Chrome 75.0.3770.101 Android app, I get to the websocket UI but no audio/video streaming occurs.

I see the usual

[INF] Profile: “Unknown Profile”, No direct play profiles found for Path: “/jellyfin/Movies/test1.avi”

lines in the logs.

Everything WORKS just fine when:

  • the client is not a Chrome browser on Android (it’s ok with Chrome on Windows),
  • the video file is, say, AVC1/MP4A-40-2 (it doesn’t work with, say, XVID/AC3 or AVC/A_AC3),
  • the server is not behind Nginx,
  • Nginx has SSL disabled (HTTP only).

I tried several Nginx configurations, with and without subpaths, but it made no difference.

Any ideas? Maybe it has to do with how Chrome Android handles AC3 codec?



Chrome (on any platform) doesn’t handle AC3, so it would have to transcode the audio to get that working. When you stream to Chrome on Windows, open another browser to the dashboard. See if it reports that the stream is being transcoded.


Hey anthony, thank you for your reply.

As you predicted, on Chrome/Windows the AC3 files are labeled as “Transcoding” on the dashboard.

The issue must somehow be SSL related, since everything works fine when I login via HTTP.

On a Chrome/Android, when I log via HTTP I get a “Direct streaming” (and all my media work).

If I log via HTTPS I get instead “Direct playing” and the test file doesn’t really play.

Media that don’t use AC3 seem to work fine with either HTTP or HTTPS.

Maybe Chrome/Android doesn’t like my server self-signed SSL certificates when direct playing? (the Android Jellyfin app also refuses to connect when I provide the HTTPS path in the address field)

How come the same file gets direct streamed when served via HTTP but it gets direct played when served via HTTPS?

Should I look for some event in particular in the logfile?

Thanks again.


For definitions on the direct terms: https://emby.media/community/index.php?/topic/48799-direct-play-vs-direct-streaming-vs-transcoding/

The self-signed certificate is likely the issue though. I’m willing to bet that with it on, something is not making the connection it needs to behind the scenes. This would result in playback capabilities being reported wrong, which means it would just default to direct play (which won’t work).

On Android, IIRC, you have to be rooted to trust a self-signed certificate? So somewhere behind the scenes, it would just be rejecting the connection.

1 Like

In the log files, when you try to play, look for any “500” errors.


Thanks again for your patience, I’ll swicth to Let’s Encrypt certificates and try again.


You won the bet, proper certificates fixed everything.

Thank you!

marks as solved

1 Like