[NOT-PLEX-RELATED] Local heavy direct play buffers slowly on Android TV 11 (armv7a)

I really don’t know what’s wrong with my configuration. Let me explain.

Some time ago I installed PMS on my WD MyCloud EX2 Ultra and it worked really well. Afetr some time I experienced a lot of buffering even on direct play so i decided to setup this new configuration thinking that the poor specs of that NAS were the problem.

Now I have a pi4 which has a container running PMS version 1.30.0.6486 and it has a volume for the media library connected to my WD NAS via CIFS. Everthing is conneceted with 1 gbps ethernet cables (CAT6).

My TV (TCL C715 with Android TV 11) has Plex version 9.13.1.37459 (armeabi-v7a) installed and has a Denon AVR-X1600H connected to HDMI with ARC enabled. Android TV settings for audio are on “auto” and passthrough enabled through HDMI on plex. The TV is connected with a dedicated 5GHz wifi connection at around 2-3mt from the router. My FRITZ!Box 7590 reports around 400/500 mbps of wifi speed on local network.

When playing a movie (MKV 4K HEVC 30 mbps HDR10 AC3 5.1) Tautulli reports direct play, PMS reports direct play and even plex on the TV reports the same thing. But it buffers a lot and inconsistently.
Then i checked all the network activity through the listed devices: TV speedtest is fantastic, pi4 the same. Even the NAS. But when i stream a movie, pi4 “outputs” only 10/15 mbps of data. What? It should AT LEAST buffer for the bitrate of the movie, right?

Direct play to my PC works flawlessy so it’s defitely a problem with the Plex app and NOT with the connection to my TV since using a wifi analyzer shows no internet dropdowns and good stability. So… now I need to understand why the plex app doesn’t work on my TV…

I checked all the logs on verbose level, even network logging on plex on the TV but the only thing that i noticed is this one:

01-05 17:46:29.551 e: [ExoPlayer][EventLogger] audioTrackUnderrun [eventTime=226.80, mediaPos=943.09, window=0, period=0, 86240, 449, 156]

Tell me which logs are useful right now and i will post them immediately.
Thank you all <3.

Is your Pi and TV both using ethernet or WiFi? If WiFi, have you tried using ethernet. If the file is being direct played, this sounds like a networking issue.

pi4 connected to the router via 1 gbps Ethernet cat6 cable
Nas connected to the router via 1 gbps Ethernet cat6 cable
Tv connected to a dedicated wifi 5 (5ghz) wpa2 network at 2/3 Mt from my router.

i think I need to point out that I made a speed test from my TV and is getting A LOT of bandwidth (500 Mbps at worse)

And that’s not a networking issue. Why? Direct play to my PC works really well. The outgoing traffic is stable and doubles the the bitrate of the stream. Using another wifi device doesn’t bother much the pi4: it simply hates that TV.

Speedtest are not very accurate for this situation. When accessing your PMS, the client (TV) makes a bunch of small requests instead of 1 large request like in a speedtest.

I would first suggest it might be the WiFi on the TV. Try to run an ethernet cable, even just to test. I also have a TCL Android TV (not the same model) and it’s WiFi is horrible. I have to use ethernet for streaming to work well with my server.

If you don’t think that’s the case, please provide logs from both the server and the client so I can check if either reports an issue.

Well, i will try to use an ethernet cable but i only have 100 mbps on that port.

I’ve tried streaming the same movie with another app (MX Player network stream) and that worked.
I created a simple node program that sends the bitrate of the movie doubled per request from MX Player.

Logs with no verbose, right? (I think that would help for this type of problem)

// Update 1 - 11/01/2023

With an Ethernet cable is even worse. Checking the transfer rates on the NAS show less transferring rate than with wifi.
I think that is definitely a problem with the app at this point.
Providing logs.

Here’s the logs. I got everything from the moment I were on the movie page, then I returned to that page after another buffer after the message “the server connection is too slow”.

Android TV.log (82.7 KB)
Plex Media Server.log (136.6 KB)

Hope that helps.

You gave me verbose server logs. :face_with_spiral_eyes:

Luckily I was able to pick out something.

So the server is responding to the Android TV at 192.168.178.20, but just before the buffering starts there is a request from Tautulli at 172.18.0.4 that is being treated as the local subnet. Did something on your network change? Or do you have 2 subnets running at the same time?

My bad for the big server logs. Sorry.

Since Docker on the pi4, which runs PMS and Tautulli, creates a subnet for my services, Tautulli sends request as part of that subnet.

The PMS container is on the host network so it works as if it has been installed on the pi4 and not in a container.
I don’t think is related: the IP of the PMS container is the same as the pi4. Tautulli instead has an IP from that subnet you mentioned.

Ok, I’ll need new logs. Also don’t cut stuff out. Just provide me the entire files.

Okay, sending the entire files and removing verbose things.

Heres the logs:

logging.txt (1.5 MB)
Plex Media Server.log (908.9 KB)

Looks like the video has an average bitrate of 30 Mbps, but the app is measuring the max speed to the server at 28.2 Mbps. This will be fine at first since the app will build a little buffer before starting playback. It will also be fine if the actual stream is not that high but since that is an average, there can be times when the actual stream is higher. During these times, the network may not be fast enough to keep up and you will get buffering.

Network buffering under-run detected.

This is in your log and what is expected when the stream can’t keep up in real time. This is the expected behavior. If the speed of 28.2 Mbps doesn’t sound right to you, that is where you should look. The app doesn’t have any limitation in it so it might be something with PMS

I’m not familiar with docker or how a Pi works so I can’t provide specific help. PMS does see a bunch of network connections so it’s possible something isn’t working right due to that.

Or we did find a network bug with PMS recently. The potential fix is in 1.30.2 beta, but since you don’t have a Plex Pass, you won’t have access to that release to test.

Thanks for help.

I’ll check on the Docker image support page for something that is wrong with that. Meanwhile I’ll wait for the public release of that version to check it out.

Besides that and completely off topic.
DTS and DTS-HD codecs are not streamed on direct play since are transcoded to AC3/EAC3 meaning that Plex on Android TV doesn’t recognize support for DTS and DTS-HD content. I can play DTS content trough a TCL app on my TV so I know that the audio codec is indeed supported and played correctly through my amplifier. Plex doesn’t like that codec but I learned of something about XML profiles on the server.

When streaming, PMS selects a profile based on the client and evaluates if something must be transcoded since the player doesn’t support that particular codec, subtitle etc.
When I start playing a movie from my Android TV, PMS selects the Android profile which I have been able to read. That file does not mention DTS content playable as direct play.

Can I modify it in any way? There is a particular structure or something?

Thanks again for help

Not the same. That is likely decoding the audio through software and is then passing through using some other low level method that isn’t available to installed apps.

The Plex for Android app checks with the TV on what codecs are supported. If DTS support is not identified, then your TV is not providing that info.

The XML profiles are no longer used. They are used for other reasons but not for the Plex app.

That’s unfortunate… Well, i checked the new PMS version that shoud have fixed an hypothetical bug.
I wasn’t fortunate enough to fix the problem. I think i need to check if my TV has some problems with the TCL firmware or somthing like that (maybe the CPU isn’t good enough to handle the stream? I don’t know…)

Anyway, thanks for help.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.