is there an option to add more logs to client/server to know more about buffering root cause on the next release ?
BTW disable DLNA did not help.
Thanks
did experiment on Mac Plex player NO buffering - the issue is only on Plex LG WebOS clients.
why there is no effort to solve this issue ?
I am still looking. I’m unable to recreate the issue and there’s nothing in your log to indicate why you are seeing the problem.
Hi
I am suggesting to add more logs to the client on the next release or as a special version.
I don’t have the source code to review the possible conditions for “buffering detected”.
the issue exist on all my LG devices not only 4.1 version.
I am sure it is related to the client since on other none LG client there is NO issue.
Thanks
is there a possibility the problem started when I changed my ISP therefor there was a need to change the router.
not sure who it is related if any since I did an experiment to turn the router off after the LG clients was up and running, did not help 
I am only using Plex on my home network - cisco switch - 1G ports.
Extra logging doesn’t help with buffering issues. There’s no way to know why it’s buffering.
Could be a slow server, slow network, slow client, bad network card on your TV, or even a bad file. The client only knows it’s not getting the data fast enough.
Since this happens with subtitles, I originally thought it was your server not transcoding fast enough, but your server logs showed it working fine.
Hi
as written above buffering only when SRT subtitles are enabled, on all LG devices different versions of WebOS, if using MAC mini Plex player NO issues same network.
can it be a client/server network communications issues for example some sort of starvation live lock ext … on the client side.
if the client detect the buffering by itself we can log the algorithm variables counters used to detect that plus all the network traffic the client gets + server logs on traffic sent.
There is about 1-2 min of buffering on the client almost few seconds after first play, I wander what the client is doing at that time of 1-2 min, even the worst network will not delay for 1-2 min of buffering.
after 1-2 minutes of buffering the movies is played OK without issues until if fast forward or pause is preformed.
I sent by Email an set pf new logs include a record of all network traffic.
the gray network packets shots the client changes the TCP ports from 44982 to 44994 during buffering while client is busy on TCP traffic related to UPNP.
Jun 12, 2020 18:41:45.366 [11080] DEBUG - Request: [192.168.0.30:44982 (Subnet)] GET /library/parts/1294/1507657892/file.mkv (8 live) TLS Signed-in Token (xxxxxxxx) (range: bytes=0-)
Jun 12, 2020 18:41:45.371 [11080] DEBUG - Content-Length of D:\plex\other\movie0000.mkv is 2696256597 (of total: 2696256597).
Jun 12, 2020 18:42:05.331 [7884] DEBUG - Failed to stream media, client probably disconnected after 6602752 bytes: 10054 - An existing connection was forcibly closed by the remote host
Jun 12, 2020 18:42:05.331 [7884] DEBUG - Completed after connection close: [192.168.0.30:44982] 206 GET /library/parts/1294/1507657892/file.mkv (6 live) TLS 19964ms 6602752 bytes (range: bytes=0-)
Jun 12, 2020 18:43:46.583 [11080] DEBUG - Request: [192.168.0.30:44994 (Subnet)] GET /library/parts/1294/1507657892/file.mkv (5 live) TLS Signed-in Token (xxxxxxxx) (range: bytes=6569984-)
Jun 12, 2020 18:43:46.587 [11080] DEBUG - Content-Length of D:\plex\other\movie0000.mkv is 2689686613 (of total: 2696256597).
change of ports TCP streaming ports from : 192.168.0.30:44982 to 192.168.0.30:44994 when SRT subtitle are enabled.
it takes the client 2 min to close the OLD TCP port connection and open the NEW one.
when SRT subtitles is disabled no change of TCP streaming ports.
log12.zip (44.7 KB)
That’s normal. If the app is direct playing the subtitles and not needing to burn them in, they will request the file from PMS through a different port. This way it doesn’t affect the transfer of the video file.
I do see something odd in your new log I didn’t see before. during your test with subttiles.
Jun 12, 2020 18:40:37.902 [9096] DEBUG - NetworkInterface: ignoring adapter ‘Ethernet 2’ (10.8.1.26) because it has no gateway
Jun 12, 2020 18:40:37.906 [9096] DEBUG - Detected primary interface: 10.8.1.26
Jun 12, 2020 18:40:37.906 [9096] DEBUG - Network interfaces:
Jun 12, 2020 18:40:37.906 [9096] DEBUG - * 7 Ethernet {3842ECC1-A16A-4440-AC24-3CDBA3D663E8} (192.168.0.5) (loopback: 0)
During your test without subtitle.
Jun 13, 2020 10:34:46.303 [2488] DEBUG - NetworkInterface: ignoring adapter ‘Ethernet 2’ (10.8.3.4) because it has no gateway
Jun 13, 2020 10:34:46.307 [2488] DEBUG - Detected primary interface: 10.8.3.4
Jun 13, 2020 10:34:46.307 [2488] DEBUG - Network interfaces:
Jun 13, 2020 10:34:46.307 [2488] DEBUG - * 7 Ethernet {3842ECC1-A16A-4440-AC24-3CDBA3D663E8} (192.168.0.5) (loopback: 0)
I’m not sure what’s going on there, but somehow Plex has chosen a different ethernet connection. Maybe check your PMS setting and make sure it’s selecting the 192 address instead of “Any”.
change the network interface to 192.168.0.5 did not help
I synced the time stamps of the network traffic recorded to the PMS logs around the 2 min buffering gap and it match , buffering end just after the close the **close the OLD TCP port 44982.
I am almost sure it is relayed to the issue.
Jun 12, 2020 18:42:05.331 [7884] DEBUG - Failed to stream media, client probably disconnected
the above massage is the hint that suggest that it is related, on rare case when there is NO buffering this massage do not exist.
btw according to PMS log the opened ports are related to file.mkv and not the SRT which is an external file.
Jun 12, 2020 18:41:45.366 [11080] DEBUG - Request: [192.168.0.30:44982 (Subnet)] GET /library/parts/1294/1507657892/file.mkv
Jun 12, 2020 18:42:05.331 [7884] DEBUG - Completed after connection close: [192.168.0.30:44982] 206 GET /library/parts/1294/1507657892/file.mkv
Jun 12, 2020 18:43:46.583 [11080] DEBUG - Request: [192.168.0.30:44994 (Subnet)] GET /library/parts/1294/1507657892/file.mkv
Jun 12, 2020 18:43:55.324 [7884] DEBUG - Completed after connection close: [192.168.0.30:44994] 206 GET /library/parts/1294/1507657892/file.mkv
Right, that message means that the client didn’t like something with the data it received and it failed to play so it needed to create another connection.
That 206 status indicates the connection did not send/receive all the data it was expecting. This matches with the error above.
Issues like this are hard to diagnose, because as mentioned, there could be lots of things that affect the transmission of the data. Could be a bad router, bad network card in your TV, or interference form a neighbor or other electrical equipment.
Since you don’t have an issue without subtitles, it seems like an issue where having 2 concurrent connections is causing the issue. Or it could be an issue with the subtitle file itself. Can you PM me the subtitle file so I can check that?
sent subtitles file used, any subtitles when selected will get the buffering issue after the first play action , rest of the play will most likely be OK after wait on 2 min buffering, until fast forward is done …
issue exist on all my LG devices - have 3 - different versions.
I used a subtitle files UTF8 format with few lines to minimize transcoding effort.
tried to move the subtitle lines to different display time - as start , end of movie did not change the issue.
is there a chance to solve the issue of buffering on LG clients on upcoming releases ?
Hi there, mind to share what gpu you are using? issit Nvidia?
yes nvidia
ok should be nothing to do with GPU branding, i have “borrow” AMD card and result same. But the said AMD card works completely fine in another plex server. not client issue as of now. will keep you posted
Hi
I am almost sure this is a LG client issue since the buffering issue is on all 3 LG devices I have.
I changed Plex servers same buffering result, I also did an experiment and switched to other Plex Client on a Mac by using the same Plex server and networks all worked fine on none LG client.
it is not clear why I have the issue and why it is hard to reproduce.
