Remote direct playback works for about 10mins, then closes app

[smidley]

When I try am using VLC as an external player (have to use VLC in order to get direct play to work with no transcoding), I am able to play a file for a few mins and then the program exits.

This is happening with remote (over internet) play only. Not happening locally. Server is on gigabit internet, and client is on 500mbit.

Logs: https://pastebin.com/LHAqc7fz

[smidley]

Update - I tested this with a new fresh install on a linux server running JF server via Docker, and have the same issue. Wanted to make sure it wasn't specifically an issue with an OS version of JF server. Also tested this without using external player (direct play), and the issue also still exists. This only happens with HTTPS remote playback - Local playback is fine.

Both the local and the remote clients are Nvidia Shield TVs.

[Artiume]

when you use local play, are you using the reverse proxy still?

[smidley]

when you use local play, are you using the reverse proxy still?

No, when I use local play, my client (shield TV) is connecting to an IP address locally on my LAN. Like this:
Client (192.168.1.10) connects to server (192.168.1.50).

[Artiume]

what proxy and are you using our default config for it

[smidley]

what proxy and are you using our default config for it

Locally I don't have any proxy just local LAN direct connect.
For remote clients, my reverse proxy is Nginx proxy manager.

[Artiume]

are you using our config

[smidley]

are you using our config

I guess I’m not sure what you mean. Am I using your config for what?

[Artiume]

are you using everything listed here

https://jellyfin.org/docs/general/networking/nginx.html

[smidley]

@Artiume I’m using nginx proxy manager, so it’s not the same as just vanilla nginx. So I’m not exactly following that. Is there any specific thing in that config that’s mandatory to resolve the issue?

[Artiume]

I'm not familiar with proxy manager but i believe its the "socket" that youre missing

[smidley]

I'm not familiar with proxy manager but i believe its the "socket" that youre missing

Here's how my current configuration looks for Jellyfin with my reverse proxy:

There's also an advanced section where I could put more nginx configuration variables:

[nielsvanvelzen]

I don't think your issue is related to your reverse proxy (although you might want to enable the WebSocket support option). This issue is probably related to #606, #643 and more similar issues.

[Artiume]

when he bypasses the proxy, it works fine, it doesn't feel like a crashing issue

[smidley]

when he bypasses the proxy, it works fine, it doesn't feel like a crashing issue

No I still had the issue even when I wasn’t using a proxy and was connecting over the internet with https and port 8920.

[Artiume]

what proxy and are you using our default config for it

Locally I don't have any proxy just local LAN direct connect.
For remote clients, my reverse proxy is Nginx proxy manager.

ah, that's more knowledge than provided here.

[smidley]

what proxy and are you using our default config for it

Locally I don't have any proxy just local LAN direct connect.
For remote clients, my reverse proxy is Nginx proxy manager.

ah, that's more knowledge than provided here.

My apologies, I thought that I had mentioned it before but I was mistaken. Here are the ways I've tested this:

Server running Windows server 2019 with no proxy
Local LAN playback works fine. Direct plays.
Remote playback fails after a few mins. (tested with auto player and VLC external player).
Remote playback works if I enable transcoding.

Server running Unraid. Jellyfin docker. Nginx reverse proxy (only for remote connections).
Local LAN playback works fine. Direct plays
Remote playback fails after a few mins. (tested with auto player and VLC external player).

[Artiume]

while i dont like the thought of doing http over remote, did you try both http and https? i cant think of anything that'd impact remote addresses only

[smidley]

while i dont like the thought of doing http over remote, did you try both http and https? i cant think of anything that'd impact remote addresses only

Haven’t tried http yet, but I’ll try to give that a go tomorrow.

[smidley]

while i dont like the thought of doing http over remote, did you try both http and https? i cant think of anything that'd impact remote addresses only

I was able to test this out, and using HTTP made no difference.

One other thing I noticed - This remote issue seems to only impact larger media such as 4k content. I was able to play 1080p files without interruption, but any time a 4k file is tested, the exact issue happens.

[christovic]

I'm having the same issue on 4K files, they play fine when I stream over DLNA from my minidlna server

[douglasg14b]

This happens with 4k files within 5-10 mins and 1080p ones within ~20 mins. Regardless of transcoding/native playback, and only on Jellyfin Android TV. Playback is fine on phones, computers, and even a roku.

All over the local network.

Pmuch it's not possible to watch anything on the Android TV app on my shield.

[krutburken]

Same problem when connecting remotely with nginx reverse proxy. Both v11.5(from play store) and the current Debug stops playback after 5-10 minutes which makes using the app rather difficult.

720p media seems to be mostly fine but 1080p usually doesn't work for very long. I have one particular file that consistently breaks in 15-20m. Let me know if you need/want a logcat.

[douglasg14b]

I noticed that if I use an external player instead of say LibVLC, this does not occur.

[smidley]

Confirmed that this is still an issue with server version 10.7.6.

This happens on both internal players, and external VLC. With remote playback.

[krutburken]

Not entirely sure what's causing it though. I just watched through an entire 1080p movie without issues (hevc direct play with exoplayer). The only difference I can see between one file that works and one that doesn't is that the non-working one has a 30% higher bitrate and uses DTS instead of AC3 for the audio track.

Maybe I'll try re-encoding the audio with AC3 instead and see if the problem disappears

edit: nope, problem persists

[krutburken]

After some further testing I managed to get the problem to go away by manually creating a downmixed ac3 stereo track and setting the app to "Direct" instead of itself downmixing the audio. Seems like this feature is the culprit, at least on this particular file

[nielsvanvelzen]

Closing this issue as duplicate of #1061. See my comment (#1061 (comment)) for some additional information.

Let me know if this issue is different (not a crash during/before/after playback) so I can re-open it.